The Live Whiteboard Method

In a live product exercise, the answer matters less than whether the people across the table can watch you think. That is the whole game. A great whiteboard is not a finished artifact you reveal at the end. It is a legible argument that builds in real time, so anyone watching can follow your reasoning, see where you would go next, and trust that you would get a real team somewhere good.

I learned this the hard way across a stack of PM interviews and client working sessions: defense modernization, grocery retention, accessible ride-hailing, engineering velocity, a new product vision for Slack. Wildly different prompts, and yet the same handful of moves kept working. This is that method.

The spine: six moves, in order

These scale to the time you have. Thirty-minute exercise: a few minutes per move. Take-home: go deep on each.

1. Translate the prompt

Before you solve anything, take the prompt apart and restate the goal in the asker's own words. The decomposition I reach for every time is Audience, Technology, Problem-to-solve: who is this for, what capability or tech is in play, and what is actually broken. Pull the load-bearing phrases straight out of the prompt and pin them up word for word.

When a product studio asked me to design for Slack's "next generation of users," I put their exact phrases on the board: "the next generation of users," "too enterprise," "missing the magic." Then I wrote the one-line vision they added up to, and immediately asked the question most people skip: "how might we measure this?"

2. Define the opportunity

Open the problem into a small opportunity tree. One framing question at the top, three to five children under it, then a layer of sharper sub-questions. Convert the sharpest ones into How-Might-We reframes, because a How-Might-We turns a constraint into an opening. On the defense modernization prompt, "operators have to be physically local to use the system" became "how might we meet operators where they are actually working?" Same fact, completely different energy.

This is the go-wide step. Resist narrowing yet.

3. Ground in reality

Anchor the abstraction in real users, segments, or numbers so the work is not floating. The grounding changes with the prompt:

• A user-segment spectrum when the prompt is about a population. For an accessibility prompt I drew the spectrum from color-blindness to low vision to full blindness, and asked what breaks at each point. Accessibility is not one user.
• A research snapshot when you need to know who the user actually is. For the Slack prompt that meant a real read on Gen Z and Gen Alpha: how they communicate, what they value, and a child-safety and COPPA reality check most people would have skipped.
• A live read of the data when you are handed metrics. More on that below.

Reason with concrete numbers even when they are illustrative. Note the assumptions you are making out loud.

4. Prioritize visibly

Make the tradeoff legible on the board, not in your head. Three tools, pick the one that fits:

• A 2x2 with axes you have named in plain, memorable language. In an Instacart prioritization round I labeled the pain axis from "Mild annoyance" at the bottom up to "Murder" at the top, annotated with "number of people, lost dollars, actual pain." The second axis was not effort, it was "Readiness: can we start tomorrow?" Renaming the axes did more for alignment than any score could have.
• A heat map when you are handed a grid of numbers. In a Code Climate velocity session I turned a five-metric by three-team table into a colored heat map. Fifteen numbers became a diagnosis a stakeholder could see before I said a word.
• Action tiers when numeric scoring would be slower than the decision needs. "Do now, prepare next, get ready" beats a spreadsheet when the room needs to move.

Pair every prioritized item with a How-Might-We so a problem reads as an opportunity, not a complaint.

5. Sequence

Turn the prioritized set into a plan with a shape. The spine I keep returning to is Outcome, then Focus Areas, then Features, then Next Steps, often paired with a Now / Next / Later roadmap and a falsifiable hypothesis: "we believe doing some of the below leads to faster releases with higher quality." Keep one sticky visibly traveling from the 2x2 into the roadmap, so the thread of your reasoning is never cut.

6. Close the loop

Never leave a solution un-instrumented. End every board with success metrics, a validation plan, and observability: how you would know it worked, what you would test before committing, what you would watch after shipping. Mark assumptions as validated or invalidated as you go. Then close like a human. On more than one board I literally ended with "Celebrate. Keep going."

The craft: what makes the argument legible

The spine is the argument. The craft is what lets someone follow it while you build.

• Color as a legend for type of thinking. One color for context, one for users, one for solutions, one for metrics, one for open questions. A viewer decodes the kind of move at a glance.
• Visible cognition. Put your real-time reactions on the board as small margin stickies: "why is this taking so long?", "surprising", "talk to the team." Hidden reasoning reads as a magic trick. Visible reasoning reads as judgment.
• Memorable renaming. "Murder." "Avoid Approval Pong." "Bring the magic back." Memorable beats precise when the job is to align a room.
• Spatial structure equals argument structure. Build left to right as a narrative: context, then users and problem, then solution, then prioritization, then metrics. Size stickies by hierarchy. Use arrows to show real relationships.
• Triage what exists, do not just tear down. When you inherit a system, mark what works with a check and what is broken with an x. It shows you read for what to keep, not only what to replace.
• Frame the big decision out loud. When there is a fork, name it on the board. On the legacy modernization prompt I put the real tradeoff up: build a separate new app, or surgically adjust the live one without disrupting day-to-day operations. Naming the tradeoff is higher-altitude than picking a feature.

Anti-patterns to watch for

• Solving before translating. You answer a question they did not ask. Pin their words up first.
• Narrowing before you have gone wide. The opportunity tree exists so you do not commit to the first idea.
• A scatter of stickies with no reading order. If the board does not read left to right, no one can follow you.
• Scores with no story. A 2x2 without named axes and rationale is a random scatter plot.
• A solution with no measurement frame. A board that ends without "how would I know this worked" is a wish, not a plan.

Try this today

Take any product question you are sitting with and give yourself ten minutes and one frame per move. Translate it, tree it, ground it, prioritize it, sequence it, instrument it. Do it in a shared doc or on a whiteboard where someone else could read it. If a colleague could follow your reasoning without you narrating, you have the method. The Whiteboard Prompt Translator will scaffold the six frames for you from a prompt.