Context
Whiteboarding is one of the most confusing and controversial interview formats in product design. It’s often framed as a way to “see how you think,” but in reality, it tests something else - how you perform under pressure with incomplete information and unclear expectations.
When I started preparing, I wasn’t blocked because I couldn’t solve product problems. I was blocked because there were no clear rules. It felt like there was a “correct” way to approach it that everyone else knew except me.
Over time, I realized that almost any task can be broken down if you understand the principles, not the topic. Whiteboarding isn’t about the “right” solution - it’s about how you move from uncertainty to a structured decision.
What actually feels broken
What frustrated me most is how whiteboarding is framed as a simulation of real work.
Real work is collaborative, data-informed, iterative, and grounded in context. Whiteboarding is the opposite - a solo performance with minimal input, under time pressure, judged in real time.
You’re expected to ask the “right” questions, make the “right” assumptions, and move at the “right” pace - essentially guessing what the interviewer wants.
The core anxiety
The hardest part wasn’t “I don’t know how to solve this.” It was the feeling that I must be missing some structure everyone else understands.
I didn’t know what to put on the board, what a “good” process looks like, or where questioning ends and solutioning begins. It felt like chaos disguised as evaluation.
Why I built a template
I went through articles, videos, and frameworks. Everyone had a “method,” but almost none explained why steps exist, when to move forward, or how to manage time.
I still didn’t know where to ask questions, where to generate ideas, or how to reach a conclusion without drifting.
At some point, it became clear: I didn’t need another framework - I needed something that removes ambiguity.
The template
I started with structure, not questions: defined stages, their purpose, and what I need before moving on. Only then added questions that actually move things forward. It resulted in a simple four-block structure:
1. Discovery (20–30 min)
Understand the problem, not solve it. I clarify context, goals, constraints, users, and data. If I assume something, I say it. If data is missing, I state assumptions and move on.
2. Ideation (~10 min)
Explore options briefly. Not about perfect ideas - about choosing direction. I generate a few approaches and quickly evaluate them.
3. Flows & Framing (30–40 min)
Core part. I show structure, link decisions to goals, and explain trade-offs. No polished UI - just clear reasoning.
4. Results & Wrap-Up
I cover metrics, risks, assumptions, validation, and how this would continue in a real team.
Why it works?
This structure removes ambiguity and naturally controls time. In discovery, questions run out - forcing you forward.
Before, I got stuck, lost focus, or over-invested in the wrong parts. With this, I can break down almost any task calmly and consistently.
Results and reflection
I still think whiteboarding is flawed.
In real work, complex problems aren’t solved alone, without data, or under strict time pressure. Whiteboarding often becomes a performance and a guessing game.
But it’s not going away.
This template doesn’t fix the format - but it makes it manageable. It reduces anxiety, adds structure, and turns chaos into something you can navigate.
Gothenburg, Sweden