Field Notes
These notes are undated and unattributed on purpose: everything comes from products I actually shipped and teams I actually led, told at a level that respects the buildings I worked in. Where an idea came from someone else, I say so.
The tools
Every tool on this site, in alphabetical order: what it is, how to use it, when to reach for it, and where it bites. They are a subset of the same useful tactics I use in my own product functions. The fillable versions of all twenty-one templates arrive by email, once, verified. Get the fillable templates.
What it is. Nine questions from the product chair before an AI feature ships: wrong-answer cost, the moment after, kill criteria.
How to use it. Run it as a team, out loud, before the demo. Any “no” becomes the next piece of work, not a reason to stop.
When to reach for it. Any time a roadmap line contains the letters AI and a launch date.
Gotchas. The temptation is to run it after the demo, when everyone is already in love. Before the demo, or it’s theatre.
What it is. Everything needed to run customer interviews that change decisions instead of confirming them.
How to use it. Print it, take it into the room, and debrief within 24 hours, while the surprise is still surprising.
When to reach for it. When someone has been told to “do discovery” and handed nothing.
Gotchas. Behaviour beats testimony. If your notes are all quotes and no observed workarounds, you interviewed a witness, not a user.
What it is. Ten checks that reveal whether your board is telling the truth. Companion to the kanban field note below.
How to use it. Fifteen minutes with the whole team, scoring honestly. Arguments encouraged; they are the output.
When to reach for it. When delivery feels slower than the board says it has any right to be.
Gotchas. A board that never embarrasses anyone isn’t mature; it’s decorative. Expect discomfort. That is the finding.
What it is. One page an opportunity must survive before it becomes a project. Nine boxes.
How to use it. Fill it in with the people who have to live with the answer. If a box can’t be filled honestly, the opportunity isn’t understood yet.
When to reach for it. Before anyone writes a roadmap line or asks for funding.
Gotchas. Filling it in alone at a desk defeats the point. The arguing is the value; the filled-in page is just the receipt.
What it is. Thirty statements about how your product organisation actually runs, as opposed to how the operating model slides say it runs.
How to use it. Leadership team scores independently, then compares. The disagreements are the findings.
When to reach for it. Post-acquisition, mid-restructure, or when a digital strategy has stalled and nobody will say so.
Gotchas. Score what happened last quarter, not what the operating model promises. Nostalgia and ambition both corrupt the data.
What it is. If your strategy can’t survive one page, it isn’t a strategy yet; it’s a wish list with formatting.
How to use it. One author drafts. Then the leadership team fights over boxes 4 to 6, which is where the strategy actually lives.
When to reach for it. Planning season, a new remit, or any meeting with “strategy” in the title and no document attached.
Gotchas. The “what we are saying no to” box must contain real options someone senior wanted, declined in writing. If it’s empty, start again.
What it is. A manager-as-coach conversation for capable people: they bring the problem, you bring questions, they leave taller.
How to use it. Monthly, alongside — never instead of — the ordinary 1:1s.
When to reach for it. When someone capable has gone quiet, comfortable, or both.
Gotchas. If you can’t name their current stretch, that is the finding, not a reason to cancel the meeting.
Meta invented the product sense interview and the rest of the industry photocopied it. Most candidates prepare for it as a framework recital, and most companies run it without knowing what the original was designed to detect.
Frequently asked questions and working methods for Head of Product, VP Product, and CPO loops, written from both chairs: the candidate side and the hiring leader's.
First of three short pieces on ways of working, drawn from running these methods inside real organisations, where the slides meet the sprint board.
Second of three short pieces on ways of working. Kanban is the method I reach for most, partly because it starts without a fight.
Third of three short pieces on ways of working. Flow is the physics underneath Scrum and Kanban, and the reason busy organisations are so often slow ones.
Years before there was a chatbot to demo, there was an unglamorous customer problem: a physical product with thousands of tiny components, and a miserable process for identifying the one that had gone missing. The answer we built was a computer-vision product, point your camera at the part, and the model identifies it, links it to the catalogue, and turns a support moment into a commercial one. I was accountable for it from discovery through launch and growth, with a data-science team doing brilliant work; it scaled to millions of users and held satisfaction scores most products never see.
Nothing about that era was hype-assisted. Nobody adopted your product because AI was exciting; it worked or it didn't. That constraint taught lessons the current gold rush actively obscures.
The hard part wasn't the vision model. It was everything around it: what happens on a failed identification, how confident is confident enough to show a match, what the user does next. Today I watch teams demo a model and call it a product. The model is an ingredient. The product is the failure states, the confidence thresholds, and the moment after.
Nobody wanted "AI." They wanted their missing part. The technology's only job was to collapse a painful process into a photograph. My test hasn't changed: describe the customer's outcome without mentioning the technology. If you can't, you have a demo.
Scaling to millions came from deeply untrendy work with marketing on conversion. The teams shipping real AI value now still spend most of their time there; the ones that aren't are publishing screenshots.
A wrong identification is charming once and fatal twice. We treated accuracy-as-experienced, not accuracy-on-the-eval, as a first-class product metric. That discipline is precisely what most generative features still lack, and why so many get switched off within a year.
The uncomfortable summary: building machine learning before it was fashionable forced product discipline that fashion now lets teams skip. If your AI initiative would not survive being unfashionable, it will not survive being fashionable either.
Companion piece: the AI Vocabulary field guide, the terms behind every mistake above.
I once ran a lab of three full-stack teams whose board was, by every visible measure, healthy. Columns flowed. Standups were brisk. WIP limits were respected, on the board. And our delivery was still slower than the board said it had any right to be.
The board wasn't measuring the work. It was measuring the tickets, and the gap between those two things is where kanban quietly fails in most organisations that adopt it.
Waiting disguised as working. A ticket sitting in "In progress" while its owner waits on another team's API isn't in progress; it's queued with better PR. We only saw it when we started tagging wait-states explicitly, and discovered the majority of our cycle time was waiting, not working. Flow efficiency, not velocity, became the number we managed.
The work that never boards. Production support, the favour for the sales team, the "quick look" at an incident, none of it on the board, all of it consuming the same people. The board showed capacity that didn't exist. Everything went on the board, however small, or the board was fiction.
Columns describing hand-offs, not value. When your columns are "Dev → Code review → QA → Deploy," you've drawn your org chart, not your customer's journey, and every column boundary is a queue you've institutionalised. We redrew columns around outcomes and watched two hand-off queues simply vanish, because they'd only existed to serve the board's shape.
Nothing clever: we measured flow instead of motion, boarded everything, and put the waiting where everyone could see it. Within a quarter the board and reality agreed, and once they agreed, the board finally did its real job, which is not tracking work but starting the right arguments. A board that never embarrasses anyone isn't mature; it's decorative.
The test for your own board: pick any ticket in "In progress" and ask its owner what they did on it yesterday. If the honest answer is "waited," your board is lying too, and now you know where to look.
Companion tool: the flow-health checks live in the Flow Health Check template and the Product Toolkit.
