What is Design Thinking? The Double Diamond for Founders
Most founders have heard of design thinking. Fewer actually understand it, and almost none apply it correctly at the early stage.
That's a problem, because the core idea is one of the most useful mental models you can have when you're trying to figure out whether an idea is worth building.
Design thinking is not a creative brainstorming session. It's not a design process reserved for UX teams. It's a structured method for solving the right problem before you invest in the right solution. In early-stage product development, getting those two things in the correct order matters more than almost anything else.
The Double Diamond: Two Problems Before One Solution
The best visual representation of design thinking is the double diamond model, developed by the Design Council in 2005. It describes the full design process as two consecutive diamonds, each made up of a divergent phase and a convergent phase.
Diamond 1 (Discovery): Find the right problem. Diamond 2 (Delivery): Build the right solution.
Every diamond follows the same logic: you start by expanding your perspective (diverge), then you narrow it into a specific direction (converge). The output of the first diamond is a well-defined problem. The output of the second is a validated solution.
The reason most founders fail is not that they execute badly. It's that they skip the first diamond entirely and jump straight into building. They spend months in the second diamond solving a problem they never properly defined.
Diamond 1: Finding the Right Problem
Diverge: Explore Before You Conclude
The goal of the first half of diamond 1 is to stop assuming and start learning. You're not trying to confirm your hypothesis here. You're trying to understand the space.
User research and interviews
Talk to people who have the problem. Not to pitch them your solution, but to understand their reality. What does their current day look like? What are they trying to get done? What's slowing them down? What have they already tried?
The goal is empathy. You want to understand the problem from the inside, through their language, not your own framing. This research produces user personas, archetypes that represent the people you're designing for. Good personas capture daily frustrations, triggers, workarounds, and aspirations. They keep you honest when you're tempted to add features your users never asked for.
A useful companion to personas is the Jobs to Be Done framework: instead of asking "who is my user?", you ask "what job are they trying to get done?" A founder using a spreadsheet to track customer feedback isn't buying a spreadsheet. They're hiring it to "never lose important input." That shift in framing changes everything about what you build.
Root cause analysis
One of the most common mistakes at this stage is solving a symptom instead of the underlying cause. The 5 Whys technique is simple: take the problem as stated, ask why it exists, then ask why that exists, and repeat five times. At the fifth why, you're usually at the real cause, and it's almost never what you started with.
Market and competitive analysis
Before you commit to a problem, you need to understand the environment around it.
-
TAM / SAM / SOM gives you a bottom-up sense of market size: how large is the total opportunity, how much is realistically addressable, and how much you can actually capture in the near term. This matters not just for investors but for your own sanity, because it tells you whether solving this problem can become a real business.
-
Competitor analysis tells you how the problem is being solved today. Who's already in the market? What's expensive? What's broken? Where are the gaps? A market with no competitors isn't automatically attractive. It might mean no one has found a business model that works.
-
Porter's Five Forces is a more structured lens for competitive analysis. It maps the forces acting on a market: competitive rivalry, threat of new entrants, threat of substitutes, supplier power, and buyer power. Used well, it reveals where your differentiation angle needs to be strongest.
-
A SWOT analysis helps you understand your own position in that market: what advantages you bring, what weaknesses could hurt you, what external threats exist, and where the real opportunity sits.
The goal of this phase is not to build a pitch deck. It's to generate enough context that you can make an honest assessment of whether the problem is worth solving, and whether you're the right person to solve it.
Converge: Define the Problem Precisely
All the research in the world is useless if it doesn't lead somewhere. The convergent half of diamond 1 is about turning exploration into a clear, specific problem statement.
A good problem statement describes who has the problem, what they're experiencing, and why it matters. It does not mention your solution. If you find yourself writing "users need a better way to X using Y technology," you've already converged on a solution before defining the problem. That's a very common mistake, and one that's hard to reverse once you've started building.
From the problem statement, you can start generating solution ideas. But not before.
Diamond 2: Building the Right Solution
Diverge: Generate Options and Build Your MVP
With a well-defined problem, you can think about how to solve it. This phase involves generating multiple solution approaches, not committing to one immediately.
From those options, you'll start shaping an MVP (Minimum Viable Product). The concept is widely misunderstood. An MVP is not a half-built version of your product. It's the smallest version of your product that lets you test a specific hypothesis about whether people will pay to solve this problem.
The emphasis is on learning, not shipping. You're not trying to impress anyone. You're trying to find out if people will change their behavior for your solution, ideally by changing it right now, with money.
One related concept worth separating: a smoke test (like a landing page that collects emails) is not an MVP. It's an experiment. Getting email signups tells you there's curiosity. It doesn't tell you there's demand. Curiosity is not a business. Willingness to pay is.
Converge: Test, Iterate, Ship
Once you have something testable, you put it in front of real users and learn from what happens. Not from what they say. From what they do.
Agile fits here because it's a development philosophy designed for situations where you don't yet know what the right solution looks like. Instead of planning a full product roadmap and executing it, you work in short cycles: build a small increment, measure how users actually behave, learn what to change, and repeat.
The classic formulation comes from The Lean Startup: Build → Measure → Learn.
The hard part is not the mechanics of Agile sprints. It's staying honest about what the feedback is telling you. Founders regularly run the loop but interpret the data in ways that confirm what they already believed. Two useful phrases for this stage:
"If you're proud of your launch, you launched too late." — Reid Hoffman
"Done is better than perfect."
Both are variations of the same idea: shipping imperfect things early is more valuable than shipping perfect things late, because you learn faster and spend less time building things nobody wants.
When to iterate vs. when to pivot: If you're getting engagement but low conversion, iterate — the problem is real, the solution needs work. If you're getting no engagement despite reaching the right people, consider whether you have the right problem at all. A pivot means going back to diamond 1, not just changing a feature.
The Phase Most Founders Skip
The first diamond takes time. Real user interviews take days. Competitive research takes focus. Market sizing is uncomfortable when the numbers don't look as good as you hoped.
So most founders skip it. They jump to diamond 2 with a half-formed problem, build for months, and launch to silence.
The irony is that solid discovery work (running the first diamond properly) is what makes everything in the second diamond faster and cheaper. When you know exactly who you're building for and what they actually need, you waste almost nothing.
This is the problem Scoutr was built to solve. Instead of spending weeks running the first diamond manually, you can run your idea through Scoutr's discovery flow and get a structured analysis covering problem fit, target user, market signals, competitor landscape, and validation plan, all in about 40 seconds.
It doesn't replace the depth of a full design thinking process. But it gives you a real signal, fast, before you commit months to something you haven't validated.
Design Thinking Is a Loop, Not a Line
Design thinking doesn't end when you ship. The double diamond is meant to be repeated. Once you launch your MVP and get real feedback, you go back through both diamonds, with better data, sharper hypotheses, and a clearer understanding of who your user actually is.
The companies that use it well treat discovery as an ongoing practice, not a pre-launch checklist. The ones that stop after launch tend to drift, slowly building things that made sense six months ago but no longer match where their users are today.
If you want a deeper look at how to run the discovery phase systematically, the six-question product discovery framework is where to go next. Or if you want to see all the validation methods available at each stage, 7 product idea validation methods that actually work covers them in depth.