Give me an example of when you were able to anticipate a customer need with a solution/product they didn't know they needed/wanted yet.
Asked at:
Amazon
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
This question tests whether you can spot unmet needs before they are explicitly requested and turn fuzzy signals into a useful solution. Interviewers are usually assessing product sense, comfort with ambiguity, and whether you actually validated that the need was real rather than building something clever in search of a problem. At higher levels, they also want to see whether you influenced priorities and created value beyond your own immediate task list.
“Tell me about a time you spotted a customer problem before the customer clearly named it.”
“Describe a situation where you built or proposed something customers ended up valuing even though they weren't directly asking for it yet.”
“Have you ever recognized an unmet user need from patterns in behavior or feedback and acted on it? What happened?”
“What's an example of a feature or product direction you championed because you saw where customer pain was heading before it became an explicit request?”
Key Insights
- You should not frame this as "the customer asked for X and I built X faster." The heart of the question is whether you recognized a deeper need before it was fully articulated.
- You need to show how you inferred the need from incomplete signals and how you reduced the risk of being wrong. A veteran interviewer will listen for evidence, validation, and iteration—not just intuition.
- Don't stop at shipping. Explain whether the solution actually changed customer behavior, reduced pain, or opened new value; otherwise it can sound like an unproven idea.
What interviewers probe atlevel
Top Priority
You do not need perfect data, but you should show that you tested your idea somehow instead of assuming your first interpretation was right.
Good examples
🟢"Before building it fully, I mocked up the new flow and asked my mentor to help me get feedback from two customer-facing teammates. Their reactions helped us simplify the first version."
🟢"I pulled a small sample of failed user sessions and compared them to successful ones to make sure the issue was real. Then I added the smallest possible change behind a flag to see if completion improved."
Bad examples
🔴"I was pretty sure users would want inline tips, so I added them and waited to see if anyone complained."
🔴"I didn't have direct access to customers, but I could tell from the code path that the feature would help, so I just implemented it."
Weak answers substitute confidence for validation; strong answers show some practical effort to test the hypothesis before or during implementation.
Your story is stronger if you show you built or contributed to something appropriately sized, then checked whether it actually helped users.
Good examples
🟢"I suggested a small first version that gave new users an example to start from, and I implemented that part with my teammate. After release, setup completion improved and support questions on that step dropped."
🟢"Rather than redesign the whole page, I added one batch action in the area where users were repeating work. We checked usage after launch and saw that teams who used it finished the task much faster."
Bad examples
🔴"I had the idea, handed it to my lead, and assumed it would make the experience better. I didn't really track what happened after that."
🔴"I built a very complete version because I wanted to cover every future scenario from the start."
Weak answers stop at ideation or overbuild; strong answers turn insight into a focused solution and verify that it mattered.
Valuable
A strong junior story usually shows initiative within your lane, good collaboration, and a meaningful but bounded contribution.
Good examples
🟢"I noticed the issue while working on onboarding, brought evidence to my mentor and designer, and helped build the first improvement in my area of ownership."
🟢"I didn't own the roadmap, but I connected the repeated user pain to a small change our team could make and followed it through with support from my lead."
Bad examples
🔴"I independently decided the product needed a new personalization strategy and drove the company to change direction."
🔴"I completely redesigned the customer journey myself because I saw what users needed before anyone else did."
Weak answers sound inflated or implausibly broad for a junior engineer; strong answers show credible initiative within assisted scope.
Example answers atlevel
Great answers
In my first year, I was working on our user onboarding flow and noticed that a lot of trial users were creating accounts but stopping before finishing setup. Nobody had explicitly asked for a new feature there, but when I looked through a few support notes and some session recordings with my mentor, I saw that people were getting stuck because they didn't know what a good first configuration looked like. I suggested adding a pre-filled sample setup so users could get to a working state faster instead of starting from a blank screen. I built the first version with another engineer and we released it to new trials only. After that, completion of the setup flow improved, and support questions about that step went down, which gave me confidence we had solved a need users felt but hadn't clearly asked for.
In my second role I was a junior engineer at a small ed‑tech nonprofit and, because I used to be a teacher, I paid attention when support showed me how teachers were exporting student progress PDFs and then emailing each family one at a time. They hadn't asked for a product change, but watching them do that repetitive work made me realize we could save significant time with a small automation. I sketched a simple “Send report to class” option, implemented the front end and a lightweight backend job with a mentor's review, and ran a short pilot with two teachers to validate assumptions. After launch the new option was used for about 30% of weekly reports within a month, teachers reported much less prep time, and support tickets about sending reports dropped noticeably—confirming we had anticipated a real, practical need.
Poor answers
At my last job, customers didn't specifically ask for it, but I thought the product would feel more modern with a dashboard on the home page. I built most of that work because I figured users always want more visibility. People on the team liked the look of it, and it made the app seem more complete. To me that was a good example of anticipating what customers wanted before they requested it.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Early September, 2024
Amazon
Mid-level
Hello Interview Premium
Your account is free and you can post anonymously if you choose.