The gap between product management books and real-world execution is wider than most people admit. Books preach empowered teams while many companies still operate as feature factories. Frameworks promise clarity but often create new forms of rigidity.
Here are 8 things about popular product frameworks that deserve a more nuanced take:
Jobs to be Done as a Mental Model
Problem: Teams build requested features without understanding actual needs, leading to high failure rates.
The Book Answer: Apply the formal JTBD framework with job executors, detailed job steps, and outcome-driven segmentation to systematically uncover critical customer needs.
Reality: Most teams quoting "Jobs to be Done" never use the formal framework. They simply ask better questions: What job is the customer hiring this product for? What are the sequential steps? Which steps create the most friction? How does the customer measure success? What emotional and social outcomes matter? Are other personas (IT, Legal, Procurement) involved?
The formal JTBD approach demands extensive interviews and surveys that rarely fit into continuous product discovery rhythms. For most teams, the real value is the mental model, not the methodology.
The Rhythm of Continuous Product Discovery
Problem: Teams treat discovery as a one-time phase before development—a waterfall pattern in disguise.
The Book Answer: Conduct product discovery continuously. Interview customers and explore problems and solutions every single week without exception.
Reality: Discovery moves in rhythms, not metronomic beats. Some weeks require synthesis over interviews. Some periods emphasize problem space exploration; others focus on solution validation or pure delivery execution.
This is especially true in B2B contexts where customer access is limited. Effective discovery fluidly shifts between refining current work and exploring future opportunities. The key isn't weekly consistency—it's ensuring discovery never becomes a separate, upfront phase.
The Value of Feature Requests
Problem: Customers aren't technology experts. They don't know what's technically possible or optimal.
The Book Answer: Ignore feature requests entirely. Conduct interviews to uncover root pain points and design proper solutions yourself.
Reality: Feature requests are valuable signals of unmet needs, not distractions to dismiss. Some requests are obvious wins—if customers need a Stripe integration for financial data, they probably need exactly that.
The skill lies in knowing when to accept requests verbatim versus when to dig deeper. Standard integrations, common tool compatibility, and obvious UX fixes? Build them. Changes to core workflows or value propositions? Investigate further. Feature requests provide concrete starting points for conversations that uncover needs customers can't articulate.
Leveraging Stakeholders’ Insights
Problem: Stakeholders dictate features instead of empowering teams to solve problems—classic feature factory behavior.
The Book Answer: Teams should receive problems and outcomes, completely insulated from stakeholder inputs.
Reality: Customer success, sales, and founders spend hundreds of hours with customers. Ignoring their accumulated knowledge to "discover from scratch" wastes time and destroys trust.
The goal isn't blind obedience to stakeholder requests—it's partnership. Use their insights, observations, and ideas as inputs to inform discovery, not as outputs to implement. Treat stakeholders as intelligence sources, not product managers.
Relying Solely on Customer Interviews
Problem: Some organizations severely restrict customer access, making empathy-building nearly impossible.
The Book Answer: The Product Trio should interview customers weekly—this alone drives Continuous Product Discovery.
Reality: Customer interviews are necessary but insufficient. Complete understanding requires:
Product analytics revealing actual behavior patterns
In-app feedback mechanisms
Support ticket analysis
Sales call recordings
Competitive intelligence
Feature request patterns
The best insights emerge from synthesizing multiple data sources. Analytics show what; interviews explain why. Sometimes customer success must pre-align outreach to key accounts—valid governance, not unnecessary bureaucracy.
A Flexible Product Trio
Problem: Traditional models silo discovery to PMs, designers to aesthetics, and engineers to implementation.
The Book Answer: The Product Trio (PM, Designer, Engineer) should conduct all discovery activities together in lockstep.
Reality: Different discovery activities require different skill sets. Sometimes a PM interviews customers alone. Sometimes a designer leads generative research. Sometimes an engineer spots a technical opportunity that sparks exploration.
The trio isn't a closed elite group—it expands (Content Designers, Data Analysts) or contracts based on context. Engineers should comment on usability; designers should discuss business value. The principle is cross-functional collaboration, not rigid structural conformity.
Eliminating Risks Upfront
Problem: Most new product ideas fail.
The Book Answer: Test high-risk assumptions before building anything. Discovery should produce a fully validated product backlog.
Reality: No experiment perfectly predicts real-world usage. The ultimate validation is customers using your actual product with real data. Instead of aiming for certainty:
Ship quickly and take calculated risks
Use experiments to reduce uncertainty, not eliminate it
Build feedback loops to learn from failures
"100% predictability = 0% innovation." The goal isn't perfect validation—it's enough confidence to make smart bets while maintaining momentum, because speed matters more than certainty in competitive markets.
Voice of the Business & Customers
Problem: Customer perspectives get ignored or minimized in product decisions.
The Book Answer: PMs must be the "voice of the customer" above all else, embracing North Star metrics that prioritize customer value.
Reality: The job is creating business value. Customer value is the means, not the end. Increasing CSAT for its own sake misses the point. Even brilliant customer-focused ideas must connect to retention, revenue, or activation metrics.
An ideal North Star Metric represents customer value while predicting sustainable business growth—but this isn't always achievable. Use frameworks like the Extended Opportunity Solution Tree that incorporate both business and customer opportunities simultaneously.
Conclusion
The real evolution isn't mastering frameworks—it's learning when to adapt them. The best product leaders don't follow best practices; they understand principles and adjust them to context.
Customers and businesses don't care about "the right way to do product." They care whether your way drives impact.
Every rule has exceptions. Use frameworks not as recipes to follow, but as inspiration to draw from.
Go Back
