When handed a specific solution to build, don't just execute. Reverse-engineer the intended customer behavior and outcome. This creates an opportunity to define better success metrics, pressure-test the underlying problem, and potentially propose more effective solutions in the future.
Related Insights
Building delightful products isn't guesswork. A four-step process involves: 1) identifying functional and emotional user motivators, 2) turning them into opportunities, 3) ideating solutions and classifying them, and 4) validating them against a checklist for things like inclusivity and business impact.
To discover high-value AI use cases, reframe the problem. Instead of thinking about features, ask, "If my user had a human assistant for this workflow, what tasks would they delegate?" This simple question uncovers powerful opportunities where agents can perform valuable jobs, shifting focus from technology to user value.
Engineering often defaults to a 'project mindset,' focusing on churning out features and measuring velocity. True alignment with product requires a 'product mindset,' which prioritizes understanding the customer and tracking the value being delivered, not just the output.
People are unreliable at predicting their future behavior. Instead of asking if they *would* use a new feature, ask for a specific instance in the last month where it *would have been* useful. If they can't recall one, it's a major red flag for adoption.
Avoid the trap of building features for a single customer, which grinds products to a halt. When a high-stakes customer makes a specific request, the goal is to reframe and build it in a way that benefits the entire customer base, turning a one-off demand into a strategic win-win.
Shift your team's language from tracking output (e.g., 'deployed XYZ API') to tracking outcomes. Reframe milestones to focus on the business capability you have 'unlocked' for other teams. This small linguistic change reorients the team toward business impact and clarifies your contribution to metrics like NPS.
To cut through MVP debates, apply a simple test: What is the problem? What is its cause? What solution addresses it? If you can remove a feature component and the core problem is still solved, it is not part of the MVP. If not, it is essential.
The misconception that discovery slows down delivery is dangerous. Like stretching before a race prevents injury, proper, time-boxed discovery prevents building the wrong thing. This avoids costly code rewrites and iterative launches that miss the mark, ultimately speeding up the delivery of a successful product.
To create transformational enterprise solutions, focus on the core problems of the key buyers, not just the feature requests of technical users. For healthcare payers, this meant solving strategic issues like care management and risk management, which led to stickier, higher-value products than simply delivering another tool.