Product frameworks
Two frameworks · One arc
Two frameworks · One arc
Worth building.
Built right.
Two frameworks for the two halves of the product job — deciding what’s worth doing, and making sure it gets done right.
My role — Creator
The Problem
The Problem
Product work breaks in two distinct places — at the front, teams build the wrong things; at the back, they hand the right things over badly.
Most frameworks pick a side. Prioritization models tell you what to build but say nothing about whether it’ll survive the handoff. Process models tighten delivery but can’t tell you whether the thing was worth delivering.
Failure A — At the front
Teams build the wrong things
Teams build the wrong things
No shared, defensible way to judge what’s actually worth the effort — prioritization defaults to whoever argues hardest.
No shared, defensible way to judge what’s actually worth the effort — prioritization defaults to whoever argues hardest.
Failure B — At the back
Teams hand the right things over badly
Teams hand the right things over badly
No shared way to guarantee a handover is complete and correct — quality leaks between design, product, and engineering.
No shared way to guarantee a handover is complete and correct — quality leaks between design, product, and engineering.
The premise
“I built one for each end — a way to decide what’s worth building, and a way to make sure it’s built and handed over right.”
“I built one for each end — a way to decide what’s worth building, and a way to make sure it’s built and handed over right.”
Prioritization
The decision layer
The 6-Signal Product Scorecard
The 6-Signal Product Scorecard
What to build, what it’s worth, what to kill.
What to build, what it’s worth, what to kill.
The Scorecard scores any feature against six benefit signals — the distinct ways work creates value — instead of collapsing everything into one gut-feel “priority”. Each function in the room scores what it sees, so Sales heat and UX love both carry real weight, rather than losing to whoever argues hardest.
The Scorecard scores any feature against six benefit signals — the distinct ways work creates value — instead of collapsing everything into one gut-feel “priority”. Each function in the room scores what it sees, so Sales heat and UX love both carry real weight, rather than losing to whoever argues hardest.
Six benefit signals
S·01
Customer pull
Customer pull
Requests and heat coming straight from accounts.
Requests and heat coming straight from accounts.
S·02
User sentiment
User sentiment
How the people using it actually feel about it.
How the people using it actually feel about it.
S·03
Revenue influence
Revenue influence
The line it moves, directly or indirectly.
The line it moves, directly or indirectly.
S·04
Strategic alignment
Strategic alignment
Whether it pushes where the company is going.
Whether it pushes where the company is going.
S·05
Competitive differentiation
Competitive differentiation
What it lets us do that others can’t.
What it lets us do that others can’t.
S·06
Usage
Usage
What the numbers say people actually touch.
What the numbers say people actually touch.
Fig. 01 — The six benefit signals, scored by every function in the room
It then applies a different risk lens depending on whether the work is existing or new — because “is this worth improving?” isn’t the same question as “is this worth starting?”. Existing features get weighed against tech-debt burden, compliance risk, and feature maturity; new bets add time criticality and effort size, so speed-to-value stays honest.
It then applies a different risk lens depending on whether the work is existing or new — because “is this worth improving?” isn’t the same question as “is this worth starting?”. Existing features get weighed against tech-debt burden, compliance risk, and feature maturity; new bets add time criticality and effort size, so speed-to-value stays honest.
The resolving formula
The signals resolve into one comparable number, so competing bets rank on the same scale instead of in the abstract.
The signals resolve into one comparable number, so competing bets rank on the same scale instead of in the abstract.
Priority Score =
Opportunity × Time Criticality
Opportunity × Time Criticality
Opportunity × Time Criticality
Effort Size
Effort Size
Effort Size
The upside —
— the cost
Fig. 02 — Priority score: every bet ranked on one scale
The action playbook
The score then routes each item into a four-tier action playbook, so the output is a decision, not just a number.
The score then routes each item into a four-tier action playbook, so the output is a decision, not just a number.
Nº
Action
When to apply
T·01
Double Down
Double Down
High value, worth more investment.
High value, worth more investment.
T·02
Fix or Polish
Fix or Polish
Valuable but underperforming; repair it.
Valuable but underperforming; repair it.
T·03
Monitor / Market
Monitor / Market
Fine as-is; the gap is awareness, not the product.
Fine as-is; the gap is awareness, not the product.
T·04
Sunset
Sunset
Costs more than it returns; retire it.
Costs more than it returns; retire it.
The benefit
Prioritization becomes defensible and repeatable. Teams stop relitigating the roadmap — there’s a shared, transparent basis for why something sits above or below the line, and an unsentimental case for killing what isn’t earning its place. Every item leaves the session with an owner and a next step.
Prioritization becomes defensible and repeatable. Teams stop relitigating the roadmap — there’s a shared, transparent basis for why something sits above or below the line, and an unsentimental case for killing what isn’t earning its place. Every item leaves the session with an owner and a next step.
Execution
The execution layer
The Spine–Branch–Responsibility Model
The Spine–Branch–Responsibility Model
Who owns each decision — human or AI — and how it resolves.
Who owns each decision — human or AI — and how it resolves.
Where the Scorecard decides what, the Spine–Branch Model governs how a workflow holds together — so what one step hands to the next is complete and correct, regardless of who designed it. It reframes the wrong question (“what are all the possible flows?”) into the right one: who should handle each moment in the flow?
Where the Scorecard decides what, the Spine–Branch Model governs how a workflow holds together — so what one step hands to the next is complete and correct, regardless of who designed it. It reframes the wrong question (“what are all the possible flows?”) into the right one: who should handle each moment in the flow?
Workflow anatomy
It breaks any workflow into four parts — a spine, its branches, the responsibility at each branch point, and how everything converges back to stability.
It breaks any workflow into four parts — a spine, its branches, the responsibility at each branch point, and how everything converges back to stability.
Fig. 03 — Every branch off the spine: errors, edge cases, role-based journeys, exceptions, other pathways
P·01
Spine
Spine
The ideal, frictionless path to the outcome.
The ideal, frictionless path to the outcome.
P·02
Branches
Branches
Where the flow breaks or expands — errors, edge cases, ambiguity, roles.
Where the flow breaks or expands — errors, edge cases, ambiguity, roles.
P·03
Responsibility
Responsibility
Who owns each decision at each branch point.
Who owns each decision at each branch point.
P·04
Convergence
Convergence
How the system returns to stability — back, forward, or into a clear next state.
How the system returns to stability — back, forward, or into a clear next state.
The ownership spectrum
Underneath sits the call that matters most now: a Human Agency ↔ AI Automation spectrum. Every branch gets placed on it using four dimensions — ambiguity, risk, frequency, and user value — which resolve into a clear ownership rule.
Underneath sits the call that matters most now: a Human Agency ↔ AI Automation spectrum. Every branch gets placed on it using four dimensions — ambiguity, risk, frequency, and user value — which resolve into a clear ownership rule.
Fig. 04 — The ownership spectrum: who owns each decision, placed by ambiguity, risk, frequency and user value
Proof the workflow is holding
And it carries five metrics to prove the workflow is holding — so consistency stops depending on who’s in the room.
And it carries five metrics to prove the workflow is holding — so consistency stops depending on who’s in the room.
M·01
Convergence speed
Convergence speed
How fast the flow returns to the spine.
How fast the flow returns to the spine.
M·02
Responsibility accuracy
Responsibility accuracy
Decisions landing with the right owner.
Decisions landing with the right owner.
M·03
Branch drop-off
Branch drop-off
Completion lost at each divergence.
Completion lost at each divergence.
M·04
Automation adoption
Automation adoption
Whether people accept what the system takes on.
Whether people accept what the system takes on.
M·05
Time to task
Time to task
End-to-end speed to the outcome.
End-to-end speed to the outcome.
The benefit
Handover stops being lossy. Because the spine is fixed, the branches are mapped, and ownership is explicit, the same workflow produces the same complete, correct output whether a junior or a lead designed it — and the human-vs-AI line is a deliberate decision, not an accident.
Handover stops being lossy. Because the spine is fixed, the branches are mapped, and ownership is explicit, the same workflow produces the same complete, correct output whether a junior or a lead designed it — and the human-vs-AI line is a deliberate decision, not an accident.
Why they belong together
These aren’t two unrelated models that happen to sit in the same portfolio. They’re the two ends of a single arc: the Scorecard makes sure effort goes to the right things; the Spine–Branch Model makes sure the right things survive the journey from idea to shipped. Run one without the other and you either build the wrong thing well, or the right thing badly.
These aren’t two unrelated models that happen to sit in the same portfolio. They’re the two ends of a single arc: the Scorecard makes sure effort goes to the right things; the Spine–Branch Model makes sure the right things survive the journey from idea to shipped. Run one without the other and you either build the wrong thing well, or the right thing badly.
“Replace judgment-that-lives-in-one-person’s-head with a system anyone can apply and get the same answer.”
“Replace judgment-that-lives-in-one-person’s-head with a system anyone can apply and get the same answer.”
What it reveals
I build the mechanism, not just the decision.
I build the mechanism, not just the decision.
I’d rather leave behind a model the team can run without me than a verdict they have to come back to me for. It’s the same principle that drives my Design Ops work — where these frameworks stop being documents and become running systems.
I’d rather leave behind a model the team can run without me than a verdict they have to come back to me for. It’s the same principle that drives my Design Ops work — where these frameworks stop being documents and become running systems.