← Back to companies
[ OK ] Loaded —
[ INFO ]
$ cd
$ ls -lt
01
02
03
04
05
$ ls -lt
01
02
03
04
05
user@intervues:~/$
How did you validate that this was a real need worth solving?
What specific steps did you take to design and implement the solution?
Who did you collaborate with, and how did you build buy-in?
How did you decide on the timing and approach for delivery?
Sample Answer (Junior / New Grad) Situation: During my internship on a mobile banking app team, I was conducting routine user testing sessions to validate a new feature. While watching five different users complete transactions, I noticed they all manually typed the same note "rent" or "utilities" in the memo field for recurring payments. Nobody complained about it, but I saw the repetitive behavior pattern across multiple sessions.
Task: As a product intern, my primary responsibility was to document usability issues, but I felt this repetitive behavior represented friction we could eliminate. I wanted to explore whether we could save users time by remembering their previous memo entries, even though this wasn't part of our current roadmap or something users had explicitly requested.
Action: I compiled video clips showing the pattern and calculated that users spent an average of 8-12 seconds typing these memos for recurring payments. I created a simple prototype using our design system that offered autocomplete suggestions based on previous memos for the same recipient. I presented this to my manager during our weekly sync with the data and prototype, suggesting we could A/B test it in our next release cycle. They approved adding it to the sprint, and I worked with an engineer to implement a basic version.
Result: After launching to 10% of users, we saw a 35% reduction in time spent on the payment flow and received unsolicited positive feedback from seven users within the first week who said they "loved the new feature." My manager shared the success in our monthly product review, and the feature was rolled out to all users. I learned that observing what users do repeatedly, rather than just what they complain about, can reveal powerful opportunities for improvement.
Sample Answer (Mid-Level) Situation: As a product manager for an analytics dashboard used by marketing teams, I regularly reviewed support tickets and user behavior data. I noticed that 40% of our customers were exporting raw data to Excel every Monday morning, and from session recordings, I could see they were manually creating pivot tables to calculate week-over-week changes. Our Net Promoter Score surveys never mentioned this as a pain point—customers seemed to accept it as "just how analytics works."
Task: I owned the core analytics experience and felt responsible for making our product powerful enough that customers wouldn't need to export data. My goal was to reduce friction in the weekly reporting workflow and increase the value customers derived from staying within our platform. I had a quarter to ship meaningful improvements before our next product planning cycle.
Action: I interviewed eight customers who frequently exported data, asking them to walk me through their Monday routine without mentioning I'd noticed the pattern. Every single one mentioned spending 30-45 minutes in Excel creating comparison reports. I then designed an in-product "Week-over-Week Comparison" widget that automatically calculated changes and highlighted significant trends. I worked with engineering to prioritize this over other planned features, arguing that reducing time-to-insight was more valuable than adding new metrics. We instrumented the feature carefully to measure adoption and created a subtle in-app notification for users who had exported data in the past.
Result: Within six weeks of launch, 62% of the customers who previously exported weekly had adopted the new comparison widget, and our average Monday data exports dropped by 48%. Three customers proactively reached out to thank us, with one saying "It's like you read my mind—I didn't even know to ask for this." Our customer success team reported using this feature as a selling point in renewal conversations. I learned that analyzing behavior patterns in aggregate can reveal needs that individual customers don't articulate because they've accepted workarounds as normal.
Sample Answer (Senior) Situation: As a senior engineering manager for a cloud infrastructure platform, I led a team supporting developer tools used by hundreds of internal engineering teams. Through on-call metrics and deployment data, I discovered that teams were frequently rolling back deployments between 6-8 PM on Fridays—a 4x higher rollback rate than other days. When I dug deeper into the incident reports, these weren't critical bugs but rather configuration mismatches that weren't caught in staging. No team had filed tickets requesting better tooling; they just accepted Friday deployment anxiety as normal.
Task: I owned the developer experience and reliability for our deployment pipeline, and this pattern represented both a productivity and morale issue. My responsibility was to identify systemic improvements that would prevent this class of problems, even though no stakeholder was actively pushing for a solution. I needed to balance this proactive work against committed roadmap items while building confidence that the investment would pay off.
Action: I conducted a retrospective analysis of 50 Friday rollback incidents and found that 80% involved environment-specific configuration drift between staging and production. I proposed a "configuration validation service" that would automatically detect drift before deployment and present a visual diff to developers. To build buy-in, I created a business case showing we could eliminate 3-4 hours per team per quarter in incident response time. I allocated 30% of my team's capacity for one quarter to build an MVP, partnering with three pilot teams to refine requirements. I also established success metrics around deployment confidence scores and Friday deployment rates.
Result: After rolling out to all teams over two quarters, Friday rollback rates decreased by 71%, and our developer satisfaction scores for deployment tooling increased from 6.2 to 8.4 out of 10. Five engineering directors specifically mentioned the feature in quarterly feedback as "something I didn't know I desperately needed." The tool caught an average of 12 potential production issues per week across the organization. Most importantly, teams started deploying more confidently on Fridays, leading to a 23% increase in weekly deployment velocity. This experience taught me that the best product insights often come from analyzing behavioral patterns and asking "why do smart people keep doing this inefficient thing?" rather than waiting for explicit feature requests.
Sample Answer (Staff+) Situation: As a Staff Product Manager at a B2B SaaS company serving enterprise customers, I analyzed three years of customer churn data and discovered a concerning pattern: companies that reached 500+ employees had a 34% higher churn rate than smaller customers, despite paying 3-5x more. Exit interviews cited "lack of scalability," but when pressed, customers couldn't articulate specific missing features. Our executive team viewed this as a sales qualification issue, not a product gap. I suspected we were missing something fundamental about how enterprises needed to use our product differently at scale.
Task: I recognized this as a strategic threat to our ability to move upmarket, which was critical to our next funding round and long-term revenue goals. As the most senior IC product leader, I took ownership of diagnosing the root cause and proposing a solution, even though I didn't directly own the enterprise segment. I needed to shift organizational thinking from "we have an enterprise sales problem" to "we have an enterprise product problem" and secure investment to address it.
Action: I initiated a comprehensive research program, conducting 25 in-depth sessions with power users at large customers, including 12 at-risk accounts. I discovered that enterprises weren't frustrated by missing features—they were drowning in governance complexity. At scale, they needed role-based access control, audit logging, and approval workflows that we'd never built because smaller customers never asked for them. I created a strategic brief showing that 60% of our revenue growth plan depended on expanding existing large accounts, and our current product architecture couldn't support it. I secured executive sponsorship to form a cross-functional team focused on "enterprise foundations," allocating $1.2M in engineering resources. I personally drove the product strategy, working with our lead architect to design a new permissions system and with our head of sales to validate the approach with customers before we built anything.
Result: Over 18 months, we launched an enterprise governance suite that none of our customers had explicitly requested but immediately recognized as essential. Our churn rate for 500+ employee customers dropped from 34% to 9%, retention revenue from large accounts increased by $4.3M annually, and we successfully closed deals with three Fortune 500 companies that previously would have churned or never bought. Our CEO credited this work in our Series C pitch as evidence of product-market fit in the enterprise segment. The most validating moment came when our largest customer said, "We were planning to build this ourselves or switch to a competitor—you solved a problem we hadn't figured out how to articulate yet." This experience reinforced that at the strategic level, anticipating customer needs requires connecting behavioral data, market trends, and business model evolution to identify unstated requirements that will become critical as customers grow.
Common Mistakes
- Confusing feature requests with anticipation -- The question asks about needs customers didn't express, not needs they asked for directly
- Lack of validation -- Failing to explain how you confirmed the latent need existed before building the solution
- No customer behavior evidence -- Not grounding your insight in actual observation of user patterns or data analysis
- Missing the "why" -- Not explaining why customers hadn't asked for this solution themselves or why it wasn't obvious
- Weak impact metrics -- Providing only qualitative feedback without quantifiable business or customer outcomes
- Taking credit for others' insights -- Make sure you clearly owned the identification of the need and drove the solution
Result: Over 18 months, we launched an enterprise governance suite that none of our customers had explicitly requested but immediately recognized as essential. Our churn rate for 500+ employee customers dropped from 34% to 9%, retention revenue from large accounts increased by $4.3M annually, and we successfully closed deals with three Fortune 500 companies that previously would have churned or never bought. Our CEO credited this work in our Series C pitch as evidence of product-market fit in the enterprise segment. The most validating moment came when our largest customer said, "We were planning to build this ourselves or switch to a competitor—you solved a problem we hadn't figured out how to articulate yet." This experience reinforced that at the strategic level, anticipating customer needs requires connecting behavioral data, market trends, and business model evolution to identify unstated requirements that will become critical as customers grow.