The workflow · Seven screens
One question per screen, Typeform-style. You can go back at any point and nothing is committed until you approve. What follows is the whole thing, in order, with the exact copy the product uses.
You always know how much is left. Back moves you a screen without losing anything you've entered.
Validation is described to the control that failed, not dumped in a banner at the top of the page.
Progress mirrors to session storage as you go, so a closed tab isn't a lost afternoon.
Everything before Screen 6 is a draft. The database sees a decision only after a person signs off on it.
Describe the problem you're solving in 1–3 sentences. Be specific about who is affected and what's not working today.
Free text, 20 to 1000 characters, with a live counter. The floor isn't arbitrary: under twenty characters you've written a topic, not a problem, and every downstream artifact inherits that vagueness.
What it refuses: anything shorter. “Add at least 20 characters so the problem is specific enough to act on.”
For each dimension, choose how much this decision will demand of the team.
This is the screen everything else hangs off. Those three answers derive the approval tier, and the approval tier gates Screen 6. Most tools collect a cost estimate and print it on a record nobody reads. Here the number has a consumer.
Leave all three blank and you get a nudge rather than a wall: “You haven't estimated what this costs. You can continue, but you won't be able to approve this decision until you do.” Nothing blocks mid-flow. Everything is enforced at the gate.
What it refuses: to score a blank as a zero. A partially estimated decision is scored as undetermined, never as cheap.
Select all areas that will be affected by this decision.
“None of the above” is exclusive: pick it and the others clear. But at least one box has to be checked. A screen where every answer is optional and a “none” option exists is a screen where blank means “didn't read it.”
This screen is also the source of the training gaps on the record. Check Required behaviors and Screen 7 will tell you that behavior change needs reinforcement rather than a single announcement, and that somebody has to plan the follow-up.
What it refuses: an empty answer. You can say nothing changes, but you have to say it on purpose.
Review the list below. For each item, confirm whether it is affected by this decision. You must explicitly rule out each one.
Eight rows, each Affected or Not affected, each answered by hand. A running count sits above the list from your first interaction, and the screen names what's left: “Answer all 8 rows before continuing. 3 remaining.”
The safeguard exists because teams systematically default to the stakeholders they already know. The ones they forget are the ones who find out in the release notes.
What it refuses: a bulk action, forever. There is no “select all,” no default, and no way past with a row blank. A shortcut here would restore exactly the reflex the screen exists to break.
Provide the key information that this decision is based on. You can edit anything later.
All five are optional, and Suggest from my inputs will draft a first pass from everything you've already entered. What it writes is marked as drafted and is yours to rewrite: “Drafted from your inputs. Edit anything. Nothing is saved until you approve.”
Leave all five blank and you get a nudge, not a block: “You haven't added any context yet. Adding at least assumptions and risks will make the decision stronger.”
What it refuses: to overwrite you. A suggestion never lands on top of a field you typed in. This is also the only screen allowed to fail out loud, because it's the only place you asked for help rather than depended on it.
Review the proposed decision(s) and the reasoning behind them. You must explicitly approve before this decision is logged.
Five editable sections: the decision, the rationale, an impact recap assembled from Screens 2 through 4, key context from Screen 5, and the decision owner.
Above them sits a banner stating what level of sign-off the recorded cost demands. Below the Approve button sits a live line naming every condition you haven't met yet:
That last one only appears above the team-lead tier, and when it appears it is required. The gate stops asking “did you tick a box” and starts asking “does the right person know.”
What it refuses: to stay approved. Edit any field on this screen after approving and the approval is invalidated. “You've changed the decision. Re-confirm and approve to log it.” The product's whole claim is that a decision isn't a decision until someone owns it, so the gate can't be softer than that.
This is your durable decision record and input to the PRD process. Edit anything before saving.
Save it and you get the toast that ends the flow: “Decision logged. You can now share this record and use the PRD input in your separate PRD process.” Note the wording. The PRD process is still yours; this is input to it.
What it refuses: to let a model write the record. Every other artifact here is drafted; the record is assembled deterministically from fields you already reviewed and approved. A model outage costs you polish, never the record.
If the model is unavailable
Every AI-drafted field has a deterministic fallback that produces real, usable content rather than a placeholder or an error. The rationale fallback, for example, states the recorded cost, the approval tier it demands, and the counts of affected change areas and teams, which is most of what a rationale needs to say anyway.
Next
Screen 2 is the one that changes the shape of the product. Drag the three values and watch the required sign-off move.