The Decision Log
Build product sense by logging decisions you'd make, the reasoning, and later the actual outcome.
- Difficulty
- Easy
- Time to result
- ~months to results
- Steps
- 5
- Confidence
- 95%
Product sense is not mystical — it is the ability to make good decisions with insufficient data. Since you only get a handful of real decisions inside your own job, Kevin Yien deliberately manufactures reps by predicting decisions other teams and other companies are making, writing down the rationale, and scheduling a future date to check the outcome. The loop of decision → documented rationale → observed outcome is what actually compounds judgement, the way scales compound for a pianist.
Origin
Kevin Yien's own practice, developed over his PM career at Square, Mutiny, and Stripe. The daily-log substrate he uses is adapted from the 'big ass text file' (BATF) note-taking pattern described in an early-2000s blog post — one long bolded list per day, searchable with cmd-F, hashtagged for later retrieval.
Core principles
- 01Product sense = making good decisions with insufficient data; the atomic unit is the decision.
- 02Rationale is the payload, not the verdict — a logged decision without a written 'why' teaches nothing.
- 03You must close the loop by returning to see the outcome, otherwise you are just guessing confidently.
- 04You can borrow reps: any team or company making a public decision is free training data.
- 05Start absurdly small — the habit is built by lowering the activation cost, not by resolving to do it perfectly.
How to run it
- 1
Create one daily log, not a system
Spin up a single Google Doc or Notion page called 'daily log'. Bullet the date, then dump the day into it as it happens — meeting names, takeaways, observations. One long file, searchable, with hashtags rather than folders.
Pro tip Use a #decision hashtag inline so you can comb back through only the decision entries on a review cadence.
Watch out Do not stall on picking the perfect note-taking tool — the tooling rabbit hole is a substitute for the practice.
- 2
Log the decisions inside your own job
Every decision you make as a PM gets documented with its rationale, inside the PRD or the log, so the whole team can see why the call was made.
Pro tip Write the rationale as if a future stranger will read it without the meeting context — that is exactly what your future self is.
- 3
Manufacture extra reps from other people's decisions
Look around at other teams and other companies shipping things. Ask: what would I do if I were responsible for that roadmap, with the information available? Write down the call and the reasoning.
Pro tip A weekly 10-minute pass — scroll news or Twitter, pick one thing, place one bet — is enough to start.
- 4
Set the outcome check before you close the doc
For each logged bet, immediately set a calendar invite for weeks or months out to come back and compare what happened against what you predicted.
Pro tip Kevin's Shopify Shop app prediction — that package tracking was the wedge into a consumer buying flywheel — was later confirmed directly by the team who built it, sharpening his model of their strategy.
Watch out Without the scheduled check, the log becomes a diary of opinions rather than a feedback loop.
- 5
Keep it complementary to real building
Continue shipping product. The decision log sharpens judgement on top of hands-on building; it never substitutes for it.
Watch out Reading Hacker News and making armchair calls will not make you a better product leader if you are not simultaneously hands-on with a product.
In the wild
When Shopify launched the Shop consumer app as a package-tracking utility, Kevin drew a diagram of the flywheel he believed Amazon owned and showed how Shopify was quietly planting a seed to take it over. He wrote the rationale down and broadcast it on Twitter, where around 60 Shopify employees followed him.
→ He later spoke to people who had worked on it: the outcome he predicted was right, though their internal reasons differed slightly — which is exactly the correction the log exists to surface.
Interviewers assume their questions produce signal but rarely go back and check. Applying the log means recording the questions asked, the decision made, and the reasoning — then reviewing 6, 12, or 18 months later against the hire's actual performance versus the level they were hired at.
→ Reveals the holes in your interview process and which questions were leading indicators of nothing.
Common mistakes
Logging the decision but not the rationale
Only the reasoning can be graded against the outcome. A bare verdict gives you nothing to learn from when reality arrives.
Never scheduling the look-back
The learning lives entirely in the comparison between prediction and result. Skipping it means you keep your confidence and lose the calibration.
Treating the log as a replacement for building
Yien is explicit that armchair decision-making without shipping product does not improve you. It is a supplement, not a shortcut.
Is it for you?
Best for
Product managers, founders, and operators who want to deliberately develop 'product sense' but get too few high-stakes decisions per quarter to learn from experience alone.
Not ideal for
People not currently building anything — the log only compounds when paired with hands-on product work.
From the transcript
“we all talk about product sense to me it's just a fancy way of saying you can make good decisions with insufficient data”
“PMS need as many reps as possible in making decisions documenting the rationale behind those decisions and then crucially seeing the outcome of them”
“a decision log is not a replacement for building products like it's a additional complimentary thing that you can be doing on your own”
From the episode
Unorthodox PM wisdom: Automating user insights, unselling job candidates, logging every decision, more
Kevin Yien (Stripe, Square, Mutiny)