--- title: 'Toast: the 2-minute test that reveals how you think about building products' teaser: Give a team one prompt. Watch them completely diverge. The differences reveal something most product teams never talk about. tags: design thinking,product management,teams,mentoring author: Bethan Ashley published_on: 2026-06-10 --- Stop. Right now, stop reading and take 2 minutes. Draw how to make toast. That's it. No further instruction. No clarification. Just those words on repeat. **"Draw how to make toast."** The moment you say it, something interesting happens. Everyone stops. Instantly engaged. Then the questions start. _"What do you mean?" "Can I use a pencil?" "Do you want steps?"_ And that ambiguity is the point. You don't answer any of it. You just repeat the instruction and watch what happens next. People either lean in or freeze. And both reactions tell you something. ## No two drawings are the same Once people get going, the room completely diverges. Some draw only the outcome. A slice of toast on a plate. Done. Some turn it into logic. Step diagrams. Flow charts. Almost mathematical. _X + Y = toast_. Some focus entirely on actions. Open cupboard. Take bread. Put in toaster. Press button. Some go deeper into detail. Which cupboard? Which bread? Where does the knife come from? What happens if the toaster breaks? Some include emotion. Smiling faces. Breakfast scenes. Warm kitchens. Morning light. And then there are my personal favourites. The _"jam people"_. They always add something extra. Butter, jam, toppings. A bit of joy. A small delighter that wasn't asked for but somehow feels essential. You can often tell when they've drawn it. There's usually a smile when they explain it back. No two drawings are ever the same. ![Collection of hand-drawn images from different people illustrating 'how to make toast' with images of bread, toasters, smiley faces and instructional arrows.](https://images.thoughtbot.com/e903279a4aj0m32eltvk8nm8ezyi_Toast%20Collage.png) ## What you're actually seeing This isn't a creativity test. It's a bias test. And once you've run it enough times, patterns start to show. ### The outcome-first people They draw the end result and move on. They're not overly concerned with the steps. In product work, these are often the people who want the Figma file and assume the rest will follow. They care about getting to “done”, sometimes at the expense of understanding how. ### The systems thinkers Often more technical profiles. They translate everything into structure and logic. They get precision, but sometimes miss the human layer. ### The action-oriented people They naturally think in steps and journeys. These are often strong product thinkers because they instinctively move towards user flow and behaviour. ### The emotional thinkers These people don't just describe the process, they describe how it feels. This is where good UX often starts. ### The deep detail thinkers Architectural minds. They want completeness. Nothing is left unresolved. The challenge is they often never finish the full flow in a time-boxed exercise, because they're building it properly from the start. ### And then the jam people. The ones who look for delight, not just function. They think about experience, not just output. Every one of these is useful. The problem is not the bias itself. It's when you don’t know you have it. ## Why this matters in product This is where it becomes more than an exercise. In product teams, these biases show up everywhere. In how you write user stories. In how you design flows. In what you consider _"done"_. In what gets prioritised on a roadmap. And often, they clash. One person thinks the job is complete when the system works. Another doesn’t think it's complete until it feels right for the user. Neither is wrong. But without awareness, teams talk past each other. This is also why some teams struggle with things like job stories or user-centred framing. It's not always a skill gap. Sometimes it's just a different default lens on the world. Good products come from teams that can see beyond their own bias. ## The moment it lands At some point in the exercise, something shifts. People look at their own drawing and then at others'. There's usually a pause. Then a quiet moment of recognition. _"Oh… I didn’t think about that."_ That’s the point where it becomes useful. Not because the drawing was right or wrong, but because it reveals something that was previously invisible. How you naturally think about problems. ## Why I use this with teams I care about this exercise because it makes something abstract very real. Product work is full of hidden assumptions. About users. About priorities. About what matters. Most teams don't realise they're not starting from the same place. They assume alignment that isn't actually there. This is a fast way of surfacing that. And once you see it, you can't unsee it. ## What changes after this The goal isn't to change how people think. It's to make them aware of how they think. Once that awareness is there, something shifts: - You write better user stories - You ask better questions - You spot gaps in thinking earlier - You stop assuming everyone shares your perspective. It also makes cross-functional teams work better. Because suddenly, different perspectives are visible instead of hidden. ## Final thought Good product teams aren't made of people who think the same way. They're made of people who understand how differently they think. And sometimes, all it takes is a simple prompt: _Draw how to make toast._