Can you tell me about a time when you made a decision that didn't work out? What did you learn as a result of this?

Question

Anonymous · Accepted Answer

Context: One of the most challenging situations I had to deal with recently was
at freshpaint, a platform that helps health care providers protect their user
data. The situation was deciding whether or not to expand features on a product
we had just launched. The product scans our customers' websites periodically and
reports on trackers and pixels that could jeopardize user PII data. We assumed
that customers would also want the ability to select trackers in the reports and
implement blockers we provide. This feature would require significant
engineering resources and effort, and I wanted to ensure we were building the
right thing.
Decision process: To approach this decision, I consulted with stakeholders,
conducted customer interviews, and collected data for analysis. This involved
engaging with our product team, engineering leads, and a sample of our customers
to gather diverse perspectives and validate our assumptions.
Outcome: Ultimately, I decided to proceed with the feature, but I limited the
scope of the feature to gather more feedback. This decision was difficult
because, while early research showed potential, the evidence was not yet strong.
I had to balance immediate resource allocation with other priorities. 
Learning: This experience underscored the importance of validating customer
interests before committing significant resources. It also highlighted the value
of flexibility in project scope and the necessity of securing stakeholder
buy-in. Moving forward, I plan to allocate more time for preliminary research
and validation phases to ensure we align our efforts with customer needs and
organizational goals. Additionally, I will continue to emphasize the importance
of iterative development and stakeholder communication in future projects.

Anonymous · Answer

That’s a good question. So, in early 2023, I was working with one of the
enterprise clients at Mantel and there was a requirement for a new feature where
I was responsible for rolling out a new feature that allows role based access
control in their data warehouse. The requirement also came with a relatively
tight deadline. I have not previously worked on a similar solution, so I have
reached out and consulted with a handful of SMEs at my firm and based on those
discussions, I have designed and implemented a solution that fits the context.
However, what I missed in this whole process was communicating the design with a
broader engineering team at client side. What that meant was when we were
getting ready to release this into production, one of the senior engineers had
some concerns on a few aspects of the design, which implied at the time some
delay in going to production. This was entirely my fault and in the hindsight, I
should have circulated the design documentation with the team for review prior
to development. To resolve this, leading up to the release of the feature, I
worked closely with the client’s engineering team, addressing any and all
concerns they have had, which thankfully were not significant changes and we
were able to go into production as planned. But the biggest lesson I learned was
the importance of open communication and gathering feedback before diving into
the code.

Anonymous · Answer

We had severals verticals at my current company such as A, B, C and others. We
successfully implemented algorithms on A and B and want to implement on C. C and
A share same infrastructure. So I prepared a plan to release algorithms for C
vertical and quoted time of 3 months. The time lines are based on our knowledge
gained from A also based on assumption that A and C are same except we have
extra features in the listings to track. I held meeting with all stakeholders
and shared the plan.
After that I started working with my team to release algorithms. During our
analysis we detected that even though they appear similar there are at least 5
prerequisites which needs to be cleared before we can run algorithms. They
existed because the changes went into production without notifying our team
which is responsible for making sure everything displayed by the user will be
tracked.
I reached out to stake holders immediately and explained the situation. I also
escalated to concerned team leaders to solve the problem immediately. I got the
ETA’s from the team leads and revised our plans. Our team worked closely with
other teams to resolve the issues. We created new timeline and communicated with
stakeholders.
In future, we will do an audit before coming up with plan especially when
planning for unknown territory.

Anonymous · Answer

During the design of a migration project from DynamoDB to Opensearch, I missed a
detail that DynamoDB had enabled cross-region replication to avoid cross-region
calls. This added significant latency in other regions. I hadnt explicitly
called this out in my design doc so it never occurred to anyone either. We
discovered this during the A/B testing and decided to add cross-region
replication at a later point thereby causing a delay in the launch.
Result: This was a miss on my part for not verifying my assumptions. A good
learning for me from this experience is to verify assumptions and call them out
explicitly so even if I wasnt aware of some detail someone else might be.
Another learning was to perform mult-region load testing instead of sticking to
a single region as that woudl have helped discover this in the earlier stages as
well.

Anonymous · Answer

Often when developing platforms and leading large scale initiatives, it is hard
to find all the relevant stakeholders who need to sign off on the final product
launch.  There was a charting product which i was a technical product manager
for that required sign off from several stakeholders such as product,
technology, database and engineering, architecture, Quality Assurance to name a
few.  We had been interacting with each of the teams right from the start, but
made the assumption that the BI team being part of the architecture and database
team would not need to provide any additional sign off.  It turns out towards
the end, when Quality teams were testing for bugs, they found out an issue with
one of the data points that would impact how the data would display for the BI
team.  Since the issue was caught earlier on during the initial phases of the
project, it helped with going back and involving the BI teams to make sure that
they can allocate time towards the project for sufficient testing and sign off.
 The final result was that the BI team allocated their resources and time and
were satisfied with the final rollout of the product.
Going forward, we decided that if there is a doubt on whether a team requires
sign off or not, to simply include them and ask the question on whether they
think they would need to be involved to provide sign off.  Its best to dedicate
time and resources from more people and teams and get their involvement rather
than leaving them out.

Anonymous · Answer

There was a situation where a decision needed to be made about rolling a certain
feature on a product line which would help with providing reports on
vulnerabilities and trackers on our customers sites that would jeopardize user
PII data.  The product feature included launching trackers on our customers
website that would protect the customers web page from unwanted trackers
tracking activities.  It was a great feature to have but one that required
significant investment of resources upfront.
After careful consideration, we decided to not roll out the specialized feature
to our customers, as rolling out this feature to the customers would require
additional resources from the technical team.
I did not want to proceed with the rollout of the additional feature considering
the amount of resources it would take and realized that i should have allotted
extra time for conducting customer research and surveys to understand whether or
not the customer even wants this additional feature.
We proceeded without launching the feature and after product launch, decided to
go to the customer to gain valuable insights on whether or not they even needed
this additional feature.  The lesson learned here was that its better to carve
out time in advance and gain all the valuable feedback needed from the customer
before making plans for what features to launch.  Its better to be armed with
enough information before hand, rather than having to make assumptions later on.
 While the decision to delay the launch of the product feature was sound, it
would have helped to know in advance.
In the end, we decided to go to the customers and ask whether or not they needed
the feature and if they said yes, we would charge them with an additional upsell
amount that would be billed back to their accounts.  A few of the customers
agreed to have this additional feature for additional precaution while some
customers decided not to pursue the additional expense.

Anonymous · Answer

There was a situation where a decision needed to be made about rolling a certain
feature on a product line which would help with providing reports on
vulnerabilities and trackers on our customers sites that would jeopardize user
PII data.  The product feature included launching trackers on our customers
website that would protect the customers web page from unwanted trackers
tracking activities.  It was a great feature to have but one that required
significant investment of resources upfront.
We finally went with the assumption that the customers would not want this
specialized feature, as rolling out this feature to the customers would require
additional resources from the technical team.
I did not want to proceed with the rollout of the additional feature considering
the amount of resources it would take and realized that i should have allotted
extra time for conducting customer research and surveys to understand whether or
not the customer even wants this additional feature.
We proceeded without launching the feature and after product launch, decided to
go to the customer to gain valuable insights on whether or not they even needed
this additional feature.  The lesson learned here was that its better to carve
out time in advance and gain all the valuable feedback needed from the customer
before making plans for what features to launch.  Its better to be armed with
enough information before hand, rather than having to make assumptions later on.
 While the decision to delay the launch of the product feature was sound, it
would have helped to know in advance.
In the end, we decided to go to the customers and ask whether or not they needed
the feature and if they said yes, we would charge them with an additional upsell
amount that would be billed back to their accounts.  A few of the customers
agreed to have this additional feature for additional precaution while some
customers decided not to pursue the additional expense.

Anonymous · Answer

There was a situation where a decision needed to be made about rolling a certain
feature on a product line which would help with providing reports on
vulnerabilities on our customers sites that would jeopardize user PII data.
We went with the assumption that the customers would want this specialized
feature, however, rolling out this feature to the customers would require
additional resources from the technical team.
I did not want to proceed with the rollout of the additional feature considering
the amount of resources it would take and realized that i should have allotted
extra time for conducting customer research and surveys to understand whether or
not the customer even wants this additional feature.
We proceeded without launching the feature and after product launch, decided to
go to the customer to gain valuable insights on whether or not they even needed
this additional feature.  The lesson learned here was that its better to carve
out time in advance and gain all the valuable feedback needed from the customer
before making plans for what features to launch.  Its better to be armed with
enough information before hand, rather than having to make assumptions later on.
 While the decision to delay the launch of the product feature was sound, it
would have helped to know in advance.

Anonymous · Answer

One of the challenging situations I had to deal with was working at Amazon on an
in vehicle delivery application To support drivers with driver safety features
and improve their productivity by automating tasks like loading daily package
delivery itinerary, routing and navigation, at stop package details and more.
The situation was to devise a solution for in field defect management solution.
The engineering team can remotely monitor software issues and a limited set of
predicted hardware issues. However, the delivery drivers are in the closest
proximity to the hardware setup running this application so it was pragmatic to
have them report any visible issues. This solution required some workarounds as
the automated in-house tools were not going to be ready until end of the year
2025. To approach this solution, I consulted with the fleet program manager on
how drivers report hardware issues for the other Amazon retrofit products in the
van which was using a survey tool. The gap in the entire flow was to automate
importing driver submitted issue to another internal tool that exports daily
defects to the vendor for fixes. I proposed a solution to automate daily survey
reports, parse those reports and build data to map to the existing internal tool
format. Once this is plugged, we will be able to monitor both kinds of defects.
Although, this was a temporary solution till we can leverage the internal tool
planned for EOY 2025. I was able to secure 1 SDE resource to work on this
proposal. However, we later found a gap where integrating with the survey tool
APIs will require Amazon assessment and review since it involves critical
customer data. This added significant scope creep. We had to pull out the
resource and bridge the solution gap using manual survey review. What I learned
from this was the importance of expanding my research work to the third party
API assessment to avoid scope creep as resource allocation is expensive
especially in a thinly operated team Structure.

Anonymous · Answer

One of the challenging situations I had to deal with was working at Amazon on an
in vehicle delivery application To support drivers with driver safety features
and improve their productivity by automating tasks like loading daily package
delivery itinerary, routing and navigation, at stop package details and more.
The situation was to devise a solution for in field defect management solution.
The engineering team can remotely monitor software issues and a limited set of
predicted hardware issues. However, the delivery drivers are in the closest
proximity to the hardware setup running this application so it was pragmatic to
have them report any visible issues. This solution required some workarounds as
the automated in-house tools were not going to be ready until end of the year
2025. To approach this solution, I consulted with the fleet program manager on
how drivers report hardware issues for the other Amazon retrofit products in the
van which was using a survey tool. The gap in the entire flow was to automate
importing driver submitted issue to another internal tool that exports daily
defects to the vendor for fixes. I proposed a solution to automate daily survey
reports, parse those reports and build data to map to the existing internal tool
format. Once this is plugged, we will be able to monitor both kinds of defects.
Although, this was a temporary solution till we can leverage the internal tool
planned for EOY 2025. I was able to secure 1 SDE resource to work on this
proposal. However, we later found a gap where integrating with the survey tool
APIs will require Amazon assessment and review since it involves critical
customer data. This added significant scope creep. We had to pull out the
resource and bridge the solution gap using manual survey review. What I learned
from this was the importance of expanding my research work to the third party
API assessment to avoid scope creep as resource allocation is expensive
especially in a thinly operated team Structure.

Anonymous · Answer

This is a product which we release recently it would check the recent breaches
that happened exploiting certain vulnarability in the recent past and also check
the vulnarabilties in the infrastructure and then provide a score based on
severity. the higher the severity the higher the chance of getting breached.
This was a great hit but two of our customers came back with a specialised
request, the wanted to quantify the severity in terms of revenue loss so it
would help them prioratize fixes on the infrastructure. This not only required
heavy research but also defining the scope as well that where it fits in. The
reason it was important to think about this feature because it was a big
contract and our company wanted close it before the end of Q2. I had a planning
sessions with the stake holders and product team, we defined the scope of the
feature and then communicated with the customer and got all the buy ins, there
had to be some repriorization required to imediatle start working on the
project, I had a chat with my team and transperantly explained why this was such
a high priority for the company and how it aligns with the company goals. This
gave boosted their morale and also they saw the advantages of adding this
feature and the moral was high.

Anonymous · Answer

There was a situation where a decision needed to be made about rolling a certain
feature on a product line which would help with providing reports on
vulnerabilities and trackers on our customers sites that would jeopardize user
PII data.  The product feature included launching trackers on our customers
website that would protect the customers web page from unwanted trackers
tracking activities.  It was a great feature to have but one that required
significant investment of resources upfront.
After careful consideration, we decided to not roll out the specialized feature
to our customers, as rolling out this feature to the customers would require
additional resources from the technical team.
We proceeded without launching the feature and after product launch, decided to
go to the customer to understand  if they would like to have this feature
installed.  The lesson learned here was that its better to carve out time in
advance and gain all the valuable feedback needed from the customer before
making plans for what features to launch.  Its better to be armed with enough
information before hand, rather than having to make assumptions later on.  While
the decision to delay the launch of the product feature was sound, it would have
helped to know in advance.
In the end, we decided to go to the customers and ask whether or not they needed
the feature and if they said yes, we would charge them with an additional upsell
amount that would be billed back to their accounts.  A few of the customers
agreed to have this additional feature for additional precaution while some
customers decided not to pursue the additional expense.

Anonymous · Answer

So i have this decision to upgrade one of the library in our codebase android.
So, i see that this library causing is outdated and might have relation to the
crash that happening for so long. So i did upgrade it, but when it is already on
production then i just knew that because this library upgrade, firebase logs in
firebase dashboard is not working as expected. Because of this, i had to rolled
back the upgrade of library and turns out after production release, it is also
not fixing the bugs.

What i have learnt from this is always checking all edge cases, creating a
documentation on pros/cons of why upgrading the libs, and rolling out carefully.

Anonymous · Answer

In my role as product manager for supply chain risk, i was tasked with
conducting user surveys and market research before developing the new platform.
 As part of a product managers role, user surveys and market research is
critical in understanding the customers needs and to develop a product that
meets the requirements of the customer.
In conducting the surveys, i was required to reach out to a specific set of
personas for the research and per the advice from product managers, was asked to
leave out their customers who were existing customers of similar supply chain
products to avoid confusion.
I reached out to the marketing teams to help me gather the list of customers who
we would target for the survey and it turned out that after removing the
customers for existing supply chain products, i was left with a very small set
of customers to send the survey out to.  Due to the limited outreach and the
reduced customer base, we did not receive enough responses to the survey as we
would have  liked.  At the end i wondered, if it would have been better to
ignore the advice of the product managers who had advised me to leave out their
customers.   We could have sent out the survey to all the existing customers
without any hesitation.  Even if customers came back asking questions, the
product managers could have informed their customers that the survey is being
conducted to simply understand what the customers want and is not intended to
create or cause any confusion.  Most people tend to ignore surveys anyways, so
perhaps taking such a risk would have been reasonable and would have enabled us
to get a larger response rate.  Besides, conducting surveys is a way for the
customer to know that the organization that is conducting the survey is keen on
staying abreast with new trends and market needs.

Anonymous · Answer

In my role as product manager for supply chain risk, i was tasked with
conducting user surveys and market research before developing the new platform.
 In conducting the surveys, i was required to reach out to a specific set of
personas for the research and per the advice from product managers, was asked to
leave out customers who were existing customers of similar supply chain products
to avoid confusion.
I reached out to the marketing teams to help me gather the list of customers who
we would target for the survey and it turned out that after removing the
customers for existing supply chain products, i was left with a very small set
of customers to send the survey out to.  Due to the limited outreach and the
reduced customer base, we did not receive enough responses to the survey as we
would have  liked.  At the end i wondered, if it would have been better to
ignore the advice of the product managers and simply go with sending out the
survey to the existing customers without any hesitation.  Even if customers came
back asking questions, the product managers could have simply informed their
customers that the survey is being conducted to simply understand what the
customers want and is not intended to create or cause any confusion.  Most
people tend to ignore surveys anyways, so perhaps taking such a risk would have
been reasonable and yielded better results.

Anonymous · Answer

I worked on a program that was similar in architecture to a current product.  I
had schedule 4 builds to verify the design.  After the second build, the design
looked good except for an EMC issue that was tested through some rework.  The
program had some testing resource issues, so I called the engineering and
compliance teams together to discuss skipping the third build.  I determined
that it was low risk to skip the build and called together the key team members
and stakeholders to go over the options.  The two options were to continue as is
with a third build and work with other programs to address resource issue or to
go straight to the 4th build and assume the low risk.  I went forward with going
directly to the fourth build and we still had an EMC issue and needed to do
another build.  What I learned form this is that even with low risk, I need to
make sure we have a working system before going to the final build.

Anonymous · Answer

I created a 30 day coaching plan that didn't work out. I learned as the
performance improves, it best to revisit the plan and update as necessary for
continuous improvement

Can you tell me about a time when you made a decision that didn't work out? What did you learn as a result of this?

Practice this question with AI

Go Premium

Practice More Questions

Community Answers

Unlock Community Insights

Unlock Community Insights

Unlock Community Insights

Unlock Community Insights

Unlock Community Insights

Unlock Community Insights

Unlock Community Insights

Unlock Community Insights

Unlock Community Insights

Unlock Community Insights

Unlock Community Insights

Unlock Community Insights

Unlock Community Insights

Unlock Community Insights

Unlock Community Insights

Unlock Community Insights

Unlock Community Insights

Stop Winging It. Start Using Frameworks.