Reference
Product Frameworks
A practical reference for the frameworks I actually use when working with early-stage teams. Each one includes when to use it, how to apply it, and what to watch out for.
RICE Scoring
Prioritize with a defensible number, not a gut feeling
When to use
Use when stakeholders are pulling the roadmap in different directions and you need an objective basis for decisions.
Formula
RICE = (Reach × Impact × Confidence) / Effort
How to apply it
Reach
How many users or accounts are affected per quarter? Use real data from your analytics, not estimates.
Impact
How much does this move the needle? Rate 0.25 (minimal), 0.5 (low), 1 (medium), 2 (high), or 3 (massive).
Confidence
How confident are you in the reach and impact estimates? Express as a percentage: 100%, 80%, or 50%.
Effort
How many person-weeks will this take across the entire team? Include design, engineering, and QA.
Watch out for
RICE gets gamed when teams inflate reach or confidence to win prioritization debates. Require evidence for every estimate.
North Star Metric Framework
Find the one metric that actually predicts revenue
When to use
Use when your team is tracking too many metrics and there is no shared definition of what success looks like.
Formula
North Star = the metric that captures value delivered and predicts long-term revenue
How to apply it
Define value delivered
What is the moment a customer actually gets value from your product? Not sign-up, not login. The moment of real value.
Test revenue correlation
Does improvement in this metric reliably predict revenue? If not, it is an activity metric, not a North Star.
Test team control
Can your product team directly influence this metric? If it is entirely driven by sales or marketing, it is not a product metric.
Set a one-year target
Commit to a specific number. A North Star without a target is just a metric. The target creates accountability.
Watch out for
DAU and MAU are activity metrics. They tell you people showed up, not that they got value. Do not use them as a North Star unless you have strong evidence they predict retention.
PMF Signal Tracker
Measure product-market fit with actual data
When to use
Use at the 3-6 month mark after launch to objectively assess whether you have PMF or are facing a retention problem.
Formula
PMF = high retention + NRR near 100% + organic inbound growth + strong disappointment score
How to apply it
Day-30 retention
What percentage of new users are still active 30 days after sign-up? Below 15% for B2B is a red flag. Above 40% is strong.
Net Revenue Retention
Are existing customers expanding? NRR above 100% means your base grows without new customers. Below 90% is leaky.
Organic inbound share
What percentage of new pipeline is inbound? PMF shows up as inbound increasing without proportional marketing spend.
Disappointment score
Ask existing users: how disappointed would you be if the product disappeared? Over 40% 'very disappointed' is the Sean Ellis threshold for PMF.
Watch out for
PMF is not a moment. It is a range. You can have PMF with one ICP and not have it with another. Segment your signals before drawing conclusions.
ICP Definition Canvas
Get specific about who you are actually building for
When to use
Use when churn is high, sales cycles are unpredictable, or you are building features that do not seem to resonate with anyone.
Formula
ICP = company profile + buying trigger + value outcome + retention predictor
How to apply it
Company profile
Size, industry, tech stack, team structure, and growth stage. Be specific enough that you could build a list of 50 companies that fit.
Buying trigger
What specific event causes this company to start looking for a solution? Funding, a new hire, a compliance change, or a competitor move?
Value outcome
What specific outcome does this customer measure success by? Not 'efficiency' — the actual KPI they track.
Retention predictor
Look at your best-retained customers. What do they have in common that your churned customers do not? That is your ICP signal.
Watch out for
ICP is not a persona. A persona is the individual user. ICP is the account. In B2B, you need both, but the ICP comes first because you sell to companies before you onboard individuals.
User Story Framework
Write requirements that engineering can actually ship
When to use
Use when engineering teams are shipping features that do not match what customers need, or when scope creep is a recurring problem.
Formula
As a [user type], I want to [action] so that [outcome]
How to apply it
Name the user type
Be specific. Not 'the user' but 'a sales manager at a 50-person B2B SaaS company who manages a team of 5 reps.'
State the action
Describe what they want to be able to do. This should be observable behavior, not a system implementation.
Define the outcome
Why do they want to do this? What business or personal outcome does it serve? The outcome is the acceptance criterion.
Add constraints
What must be true for this story to be done? Include edge cases, error states, and performance requirements.
Watch out for
A user story without an acceptance criterion is a wish, not a requirement. Never hand a story to engineering without a testable definition of done.
Five Whys for Root Cause
Find the real problem before you build the solution
When to use
Use when a customer requests a feature, files a bug report, or churns, and you need to understand the underlying cause before responding.
Formula
Ask 'why?' five times in sequence — each answer becomes the next question
How to apply it
State the symptom
Start with the observable problem as the customer described it. Do not interpret or assume cause yet.
Ask why it happened
What is the direct cause of the symptom? Write the answer as a statement, not a hypothesis.
Ask why that happened
What caused the cause? Continue down the chain without stopping at the first plausible explanation.
Repeat to the fifth why
By the fourth or fifth why, you typically arrive at a process, system, or incentive problem rather than a surface symptom.
Watch out for
Five Whys can stop too early. If the answer at why 3 is 'because we did not build it,' that is not a root cause. Keep going until you find the organizational or process reason it was not built.
Have a framework you use differently?
The real value of frameworks is in how practitioners adapt them to specific contexts. The Expert Perspectives publication is where practitioners share those adaptations. Contributions welcome.