Could you describe a situation where you made a decision that didn't work out as planned? What did you learn from the experience?

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

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

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

Could you describe a situation where you made a decision that didn't work out as planned? What did you learn from the experience?

Did you come across this question in an interview?

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

Try Free AI Interview

Google

Product Manager

Meta

Product Manager

Meta

Engineering Manager

Amazon

Data Scientist

Also asked as