On a recent episode of Aakash Gupta’s podcast, Oji Udezue ran a product idea through a viability gate he had built as a Claude Code skill. The idea was a tool called Standup Zero that reads Slack comments and assembles a daily standup digest. The gate scored it on six dimensions and returned three moderates. Problem clarity and urgency, moderate, because workflow convenience is not a deep problem. Target user definition, not strong. Differentiation, not strong. Competitive landscape, strong, which on this scorecard counts against you, because it means everyone can build what you are building.
That is a capability worth pausing on. Ask a chat model whether your idea is any good and it will tell you it is. Udezue built the gate specifically because models rarely say no, and he wanted something with a structural obligation to. Score three dimensions weak and it refuses the project outright.
Standup Zero did not score three weak. It scored three moderate, and the verdict was to proceed with eyes open. The idea died anyway, because a product leader with twenty-five years of experience read the hedge, decided the market was too crowded to be worth his time, and moved on to the other project.
That call is the most valuable thing that happened in the run. It is the one part of it a machine could not have produced. It exists in an audio file and it is written nowhere in the repository.
The Case the Episode Makes
Before the criticism, the agreement, because the episode is the strongest external evidence I have seen for an argument I have been making for a year.
Udezue calls it the three-speed problem. Development is being compressed by a factor of ten, and maybe twenty within five years. The two ends around it, working out what is worth building and getting it into the market, stay bound to the speed of talking to actual customers. He watched developers accelerate across client engagements and watched everyone else become the constraint, and named the specific failure as product managers not speeding up their judgment and orchestration to match. That is a former CPO of Typeform and Calendly arriving at cheap execution and scarce judgment from consulting work rather than from theory.
So the tooling layer is being built by serious people, and it works. What sits underneath it is missing.
The Asymmetry
Every skill run leaves an artifact. The viability gate writes its assessment, dimension by dimension. The market research skill writes its package. The scaffolding skill writes a product brief with target customers and success criteria. Open the repository afterwards and you can reconstruct what the machine concluded and why.
Nothing in that repository records what the human decided in response.
Udezue is explicit that you have to review the output. He calls it a first draft, warns against treating it as gospel, and frames the review as a PRD session in a room full of product managers, asking what it missed and which persona it skipped. He then demonstrates exactly that. Reading the generated brief, he approves of its choice of a non-technical founder as the primary user, then notes it never qualified that by company size, since a founder at a larger company has more resources and more tools. He accepts its decision to scope corporate developers out, and explains that the output’s own research supports it, because the value proposition there is weaker.
That is product judgment, exercised in real time, on camera, and none of it survives the session.
He tells you to review the output. He does not tell you to record the review.
Three Additions
None of this needs new tooling. It needs three fields and one habit.
Record the response next to the verdict. When the gate returns a score, the reaction gets an entry beside it: what the skill concluded, what you decided, what you rejected and why, and how confident you were. The last field is the one teams drop first and the one that matters most a year later. A decision with no rejected alternative is usually a default nobody examined. A decision with no confidence marker gives a future reader no way to separate a considered call from something settled at seven in the evening. Udezue has already built this instrument on the code side. His Vibe Memo skill captures why a code decision was made and keeps the reasoning in the log alongside it. The same instrument, pointed one layer up at the product decisions the gate produces, closes most of the gap.
Keep the overrides somewhere you can count them. A gate that scores six dimensions is a theory about what makes a product worth building, and theories need calibration. If nobody records the times a team proceeded past a hedge or overruled a weak score, two things never happen. The gate never learns where it was wrong, and the person who overruled it never learns whether their instinct was any good. Annie Duke calls the underlying error resulting: judging the quality of a decision by the quality of its outcome. A written record made before the outcome arrives is the only defense against it, and there is currently no such record on either side of the gate. An oracle with no logged misses accumulates authority it has not earned, and a skill distributed to a hundred people accumulates it quickly.
Say which steps the skill owns. The scaffolding skill runs an eleven-step workflow and settles architecture, testing, continuous integration, folder structure, and the project’s own context file. Write down which of those it may decide alone, which need a named human, and which need two. Review everything is an instruction rather than a boundary, and instructions are the first thing to go when the sprint compresses. A boundary written down survives a bad week. A good intention does not.
What To Do Now
Add one file beside your gate output. Four lines: what it concluded, what you decided, what you rejected, how sure you were. Write it the same day, before you know how the thing turns out, because memory tidies and the alternative that nearly won is always the first detail to go.
Then wait for the run where the gate is wrong. It will happen, and it will be the most valuable entry in the file.
The skills are the right idea; adding Judgment on tap, in Udezue’s phrase, is a real capability and the people building it are ahead of most organizations. But a skill preserves the reasoning of the party that did not make the call, and discards the reasoning of the party that did. That inversion is small enough to fix this week, and expensive enough to be worth it.