wait who approved the scope change?
The decision workflow
Cognitivv PM is a seven-step workflow that forces root cause, cost, and explicit approval before anything reaches delivery. What comes out is a decision record with a name on it.
wait who approved the scope change?
Decision sync #4 · 32 min · no notes
decision_final_v7_FINAL2.docx
RE: RE: RE: timeline slip, thoughts?
ask Sarah? she was in the room
ATL-482 · blocked · waiting on decision
Weekly sync · 58:12 · never watched
“we said we'd revisit this in Q3”
The gap
Teams start delivery before they've found the root cause, agreed on the problem, weighed the evidence, or gotten anyone to actually sign off. The call gets made at feature level. Nobody checks what it costs, whose job it changes, or who owns it when it goes sideways.
Scope, cost, and the teams downstream never entered the conversation. The decision was about a feature, so the thinking was too.
Assumptions, precedent, and the risks people privately worried about never got written down. Six weeks later the whole thing gets re-litigated from memory.
When it needs defending there's a thread, not a name. That's the moment teams discover the decision was never really made.
PMs are seen as schedulers and communicators, not critical thinkers. Head of engineering, discovery conversation
That's not a talent problem. It's a missing step. Cognitivv PM is the step.
The workflow
One question at a time. Nothing here is a form you can tab through, every screen has a thing it won't let you skip, and those refusals are the product.
Step 1 of 7 · Human
A blank field and a hard floor: twenty characters, and it has to say who's affected and what isn't working today. No template, no picklist. If you can't write the problem down, you don't have one yet.
Refuses: anything under 20 characters. A problem statement that short isn't specific enough to act on.
Step 2 of 7 · Human
Three questions. Roughly what share of the team's capacity does this consume, how long before it delivers value, and what will it cost to deliver. Answer them and the product tells you who's allowed to approve it. This is the screen everything else hangs off.
Refuses: to treat blanks as zeroes. Skip this screen and the required approval level is undetermined, which means nobody can approve it at all.
Step 3 of 7 · Human
Which areas actually change for the people who have to live with this: processes, systems and tools, job roles, required behaviors, reporting structure. This is also where the training gaps at the end come from.
Refuses: an empty answer. “None of the above” is available and exclusive, but you have to pick it on purpose.
Step 4 of 7 · Human
Eight rows. Adjacent product teams, support, sales, legal, security, data, external partners, downstream customer-facing. You rule each one in or out by hand, and you can't move until all eight have an answer.
Refuses: a bulk action. Teams default to the stakeholders they already know, a “select all” button would hand that reflex right back.
Step 5 of 7 · AI + human
The five things the next person will need and won't have: assumptions, systems involved, precedent, key risks, target state. Claude can draft a first pass from what you've already entered, and every word of it is yours to edit.
Refuses: to overwrite you. A suggestion never lands on top of something you typed, and this is the one screen allowed to fail out loud, because here you asked for help rather than depending on it.
Step 6 of 7 · Human
Five conditions before Approve does anything: the confirmation is checked, an owner is named, the decision reads like a decision, the cost is estimated, and above team-lead level someone confirms that the named owner actually has authority to commit that capacity. The button tells you which ones are still missing.
Refuses: to stay approved. Edit anything on this screen afterward and the approval is invalidated. You re-confirm, or it isn't approved.
Step 7 of 7 · AI + human
Four artifacts on approval: the record itself, a kickoff summary, preliminary PRD input, and the training gaps your change impact just created. Editable until you save. Then it's logged, timestamped, and attached to a name.
Refuses: to let a model write the record. It's assembled from fields you already reviewed and approved, so an AI outage can't degrade the one artifact this product exists to produce.
Step 1 of 7
Hey there! Burning the midnight oil, are we?
Describe the problem you're solving in 1–3 sentences. Be specific about who is affected and what's not working today.
0 / 1000
Step 2 of 7
For each dimension, choose how much this decision will demand of the team.
Step 3 of 7
Select all areas that will be affected by this decision.
Step 4 of 7
Review the list below. For each item, confirm whether it is affected. You must explicitly rule out each one.
Step 5 of 7
Provide the key information that this decision is based on. You can edit anything later.
Step 6 of 7
You must explicitly approve before this decision is logged.
Step 7 of 7
This is your durable decision record and input to the PRD process. Edit anything before saving.
Problem, decision, rationale, impact, owner, timestamp.
What the delivery team needs on day one.
Goals, scope, high-level requirements, open questions.
2 areas flagged from your recorded change impact.
Three safeguards
Any tool can hold a form. These are the three places Cognitivv PM stops being a form and starts being a gate.
Safeguard 01
Eight teams. Every one gets ruled in or out by a person, one row at a time. There is no “select all,” no default, and no way past the screen with a row left blank.
This is deliberate friction. Teams systematically default to the stakeholders they already know, and the ones they forget are the ones who find out in the release notes. A bulk action would restore exactly the reflex this screen exists to break.
Teams and partners to consider · 6 of 8 answered
Safeguard 02
Most tools collect a cost estimate and print it on a record nobody reads. Here the number has a consumer. Delivery effort, time to land, and budget derive an approval tier, and that tier gates the approve screen.
Leave a field blank and the tier is undetermined, which means the decision cannot be approved by anyone. Blanks are never scored as zeroes, because the cheapest way to reach the team-lead tier would otherwise be to skip the screen entirely.
Try it · approval tier, derived live
| Tier | When |
|---|---|
| Cannot be determined | Any of the three fields is blank. Checked first, so blanks are never scored as zeroes. |
| Executive | Effort is 40% or more, or time to land is 180 days or more, or the budget band is over $100k. |
| Team lead | Effort under 15%, and under 30 days, and under $10k. |
| Capacity owner | Everything else. |
Approval required
Capacity owner
Safeguard 03
The approve button reads five conditions, and it names the ones you haven't met instead of just sitting there greyed out. Check the box, name an owner, write a real decision, estimate the cost, and above team-lead level, confirm the owner can commit that capacity.
Change any of it after approving and the approval is gone. Not flagged, not stale, gone. You re-confirm and approve again, or the decision isn't approved. The whole claim of the product is that a decision isn't a decision until someone owns it, so the gate can't be softer than that.
Review and approve
On approval
Everything downstream is generated from what you already approved, and all of it is editable before you save.
Problem, decision, rationale, impact, owner, approval timestamp. Never model-generated, assembled from fields you reviewed and approved, so an AI outage can't degrade it.
What the delivery team needs on day one, written from the record rather than from a meeting nobody took notes in.
Goals, scope, high-level requirements, open questions. Input to your PRD process, not a replacement for it. We're clear about that on purpose.
Mapped straight from your recorded change impact. Change what people are required to do and you've created work nobody has scheduled. This is where it stops being invisible.
The decision record is the durable artifact the whole product exists to produce. If a model wrote it, then a bad day at the API is a bad day for your audit trail. So it isn't written by a model at all. It's assembled from fields you've already read and signed off on.
The same logic runs through the rest of the flow. Every AI-drafted field has a deterministic fallback that produces real, usable content, which means the entire workflow runs with no API key configured. The one place that's allowed to visibly fail is the optional Suggest from my inputs button, because that's the one place you asked for help rather than depending on it.
Scope, stated plainly
The decision workflow is one stage. The fuller PRD and spec process happens after it, separately, and we'd rather say so here than let you find out in month two.
Where the AI sits
A model is useful for the first pass at prose nobody wants to write. It is not useful as the thing that decides your quarter.
Ever. Every AI or combined output is human-editable before it's final, and the approve gate is a person doing a person's job.
If you typed it, the draft goes somewhere else. Your words are the ones that survive a conflict.
Every drafted field has a deterministic fallback that writes real content, not a placeholder and not an error.
The durable artifact is assembled from approved fields. A model outage costs you polish, never the record.
Where this goes
We'd rather show you the roadmap than imply everything already exists.
Manual entry, the hard approval gate, the derived approval tier, and the decision log. This is what exists today.
Assign an approver, request a response, track its status, without defaulting to a meeting. Stakeholders often finalize things before the PM is deeply involved, and a calendar invite is a poor substitute for a request that can be tracked.
Integrations get built when usage shows they're the constraint, not because a competitor's feature grid has a row for them.
A decision that changes what people are required to do creates work nobody scheduled. Cognitivv's AI-native training platform is the other half of that sentence, and it's live today, including a compliance build for dental practices.
The ask
We want to run Cognitivv PM with a small number of teams and watch one thing: whether a structured decision gate actually reduces the decisions that get quietly reversed. If that's a problem you recognize, we'd like to talk to you.
Backed by Georgia Institute of Technology's CREATE-X.