8 Things About Product Frameworks I Wish I Knew Earlier
Your customers and business couldn't care less about “the right way to do product.” The only thing that matters is whether your work drives impact.
Hey, Paweł here. Welcome to the free edition of The Product Compass Newsletter.
Every week, I share actionable tips, templates, resources, and insights for PMs.
Here’s what you might have recently missed:
MCP for PMs: How To Automate Figma → Jira (Epics, Stories) in 10 Min.
A Proven AI PRD Template by Miqdad Jaffer (Product Lead @ OpenAI)
Consider subscribing or upgrading your account for the full experience:
When I started learning about product management, I was shocked by how different books were from my company's reality. Books talked about empowered teams while we just pushed features through a waterfall.
I developed strong opinions about how product companies should work. Later, I realized that taking frameworks at face value is just another extreme.
So here are 8 things about frameworks I wish someone had told me before I had to learn them the hard way:
Jobs to be Done as a Mental Model
The Rhythm of Continuous Product Discovery
The Value of Feature Requests
Leveraging Stakeholders’ Insights
Relying Solely on Customer Interviews
A Flexible Product Trio
Eliminating Risks Upfront
Voice of the Business & Customers
Let’s dive in.
1. Jobs to be Done as a Mental Model
Problem: Many teams focus on features customers request without understanding their needs. Most of those features are not going to work.
The Book Answer: Use the formal JTBD (Jobs-to-be-Done) framework with job executors, job steps, and outcome-driven segmentation to uncover customer needs that matter the most.
Reality:
Most teams that quote “Jobs to be Done” don't actually use the formal JTBD framework. Instead, they ask simple questions:
What job is the customer trying to do?
What are the steps?
Which of them should we tackle?
How does the customer measure success?
What emotional and social outcomes matter?
Are other personas involved (IT, Legal, Procurement, etc.)?
The formal JTBD approach requires significant work (interviews, surveys) and is unlikely to fit into your Continuous Product Discovery. For most teams, the value is in JTBD inspiring the right questions.
2. The Rhythm of Continuous Product Discovery
Problem: Many teams treat discovery as a one-time phase before development starts. This is no different than working in waterfall. A great video:
The Book Answer: Product discovery should be continuous. Talk to customers, explore the problem and solution space every single week.
Reality:
Discovery has different rhythms:
Some weeks you might skip customer interviews to synthesize findings.
Sometimes you're exploring the problem space, other times the solution space.
Occasionally you're focused on delivery.
This is especially true in B2B, where finding customers for weekly interviews can be hard.
It’s perfectly fine that your discovery efforts move between:
Ongoing research that refines what you're currently building.
Mid-term research that might inform your next quarter or year.
The key isn't perfect consistency but ensuring discovery never completely stops and doesn't become a separate phase in which you "discover everything upfront."
3. The Value of Feature Requests
Problem: Customers are not technology experts. They don't know what is possible and how to solve their problems best.
The Book Answer: Ignore feature requests. Interview customers to understand the underlying pain points and come up with solutions.
Reality:
In my experience, feature requests provide tremendous value and can inform your discovery. Each request signals an unmet need.
And, frankly, some are no-brainers. If a customer needs a Stripe integration to get financial data, they need the Stripe integration.
The trick is knowing when to take requests at face value and when to dig deeper, for example:
Take at face value: Standard integrations, compatibility with common tools, obvious UX/UI adjustments.
Dig deeper: UX/UI changes, workflow changes, anything affecting your core value proposition.
Many feature requests give you a starting point for conversations that might uncover deeper needs your customers struggle to articulate.
4. Leveraging Stakeholders’ Insights
Problem: In many organizations, stakeholders dictate features to build rather than empowering teams to find solutions - a feature factory.
The Book Answer: The team is always given problems and key desired outcomes and doesn't need stakeholder insights.
Reality:
Stakeholders like customer success, sales teams, and founders spend hundreds of hours with customers. Ignoring their knowledge and discovering everything from scratch is a mistake many new Product Managers make.
Instead of blocking your stakeholders, partner with them. Leverage their knowledge, insights, and ideas (yes, features!) to inform your discovery.
The goal isn't to follow their requests blindly, but to include their valuable insights.
5. Relying Solely on Customer Interviews
Problem: In some organizations, product teams are not allowed to talk to customers at all, which makes building customer empathy virtually impossible.
The Book Answer: The Product Trio should talk to customers every week. This is everything they need to perform Continuous Product Discovery.
Reality:
Customer interviews are essential, but far from enough. You need feedback from:
Product analytics to understand actual behavior
In-app feedback mechanisms
Support tickets
Sales call recordings
Feature requests
Competitive analysis (yes, sometimes copying competitors is valid).
The best insights often come from combining multiple data sources. For example, product analytics might help you identify specific behavior, and customer interviews help you understand the Why.
Also, you might need to align with Customer Success before reaching out to key accounts. There might be valid reasons for that. Try to understand that rather than obsessing over an “unrestricted access.”
6. A Flexible Product Trio
Problem: In the classic setup, the PM is the only one who performs discovery, then hands off requirements to Designers who make things prettier (like lipsticking a pig). And Engineers are just there to implement it (the “doers”).
The Book Answer: The Product Trio (usually PM, Designer, Engineer) should do all discovery together. Designers focus on usability while Engineers contribute to what's feasible.
Reality:
Each discovery activity needs different levels of engagement from different product team members.
Sometimes a PM needs to interview a customer alone, sometimes your Designer needs to lead research, and sometimes you start with an Engineer who spots the technical opportunity.
Don't think of the trio as an elite closed group. It can expand (e.g., Content Designer, Data Analyst) or contract (no Designer) based on context.
Bring in team members according to their skills and interests. For example:
You might discuss opportunities and ideate with the entire team during a refinement session.
Engineers should feel free to comment on usability issues.
Designers can provide tremendous value when discussing value for the customers and the business.
The key is cross-functional collaboration and including different perspectives, not fixating on a rigid structure and responsibilities.
7. Eliminating Risks Upfront
Problem: Most new product ideas fail.
The Book Answer: Test high-risk assumptions before building anything. Product discovery results in a validated product backlog.
Reality:
No experiment is 100% conclusive. The ultimate test is customers using your product in the real world with their real data.
Rather than trying to succeed every time:
Release quickly and take calculated risks.
Perform experiments to reduce uncertainty, not eliminate it.
Build feedback loops to learn from your failures.
Remember that “100% predictability = 0% innovation.” (1) The goal isn't perfect validation, but enough confidence to make calculated bets while maintaining momentum. Because “speed matters in business.” (2)
(1) "100% predictability = 0% innovation." - Henrik Kniberg
(2) "Speed matters in business." - Jeff Bezos
8. Voice of the Business & Customers
Problem: In many organizations, the customer perspective is ignored or minimized in product decisions.
The Book Answer: Product Managers should be the "voice of the customer" above all else. Embrace the North Star and focus on customer value while making sure it just works for the business.
Reality:
Your actual job is creating value for the business. Creating value for customers is the means, not the goal. Though, both are often aligned (see “the value stick”).
Key points:
Increasing CSAT (Customer Satisfaction) just for its own sake misses the point.
Even the best customer-focused ideas should connect to business goals and metrics like retention, revenue, or activation.
North Star Metric that represents the value for the customers and is a leading indicator of a sustainable business growth is ideal, but not always possible.
I recommend the Extended Opportunity Solution Tree that includes both business and customer opportunities.
Conclusion
Looking back, I realize the biggest shift wasn't learning frameworks but knowing when to apply and adapt them.
The best product leaders don't blindly follow best practices. They understand the principles behind them and adjust to their specific context.
Your customers and business couldn't care less about "the right way to do product." The only thing that matters is whether the way you work drives impact.
This list isn't complete. We could talk about teams not ready to be empowered or compromising strategy so a startup can survive.
I've learned that every rule has an exception.
So use frameworks and “best practices” not as recipes, but as inspiration.
P.S. You can start with 30+ free Product Management templates ;)
Thanks for Reading The Product Compass Newsletter
It’s great to explore, learn, and grow together.
Next:
On Tuesday we’ll have a live session to explore using Claude and MCP servers. More information and invitations: see the premium resources section.
I’m researching hosting n8n agents for free with MCP and browser use. It’s anything but obvious to go beyond a working demo. I'll publish the recommended approach and step-by-step instructions within 2 weeks.
Have an awesome weekend and a fantastic week ahead!
Paweł
Probably your best article to this date…
Great article, Pawel! It’s such a relief to read practical insights—feels like it’s almost impossible to stick to the books and frameworks in B2B. Your point #4 about stakeholder insights is especially spot on, particularly in a sales-heavy B2B environment.