Step 4 — Design Concepts — The Product Playbook

You have a problem worth solving and a hypothesis to test. Step 4 is where you bring people in, generate concepts, narrow to the best few, and decide how you'll test the one you pick. Not how you'll build the real thing. How you'll learn whether the real thing is worth building at all.

A concept is just one possible solution idea. A rough sketch of one way you might solve the problem.

The trap here is obvious, and almost everyone falls into it. You jump straight to building the actual product. Months of engineering and a polished UI before you have any idea whether a single customer wants it. Step 4 exists to stop you from doing that.

Diverge, then converge

The concepts have to come from somewhere, and that somewhere is not your head alone. Bring a diverse group into the room: engineering, design, support, sales, anyone who sees the problem from an angle you don't. Then generate a lot of ideas. Volume first, judgment later. A bad idea sitting next to a good one isn't waste; it's usually what sparked the good one.

Then converge. Cut the pile down to the few worth testing, and be ruthless about it. Skip the narrowing and you end up half-testing six ideas instead of really testing one. In the Toolbox (Part 06), I'll show you ways you can run this with your team.

Don't design to prove yourself right

Here's the part nobody wants to hear. The point of a prototype is not to prove you were right.

You already believe the idea will work. So do I, about most of mine. That belief is the thing that gets you into trouble, because once you've decided you're right, you'll quietly design the experiment to agree with you. You'll show the demo to friendly customers, ask leading questions, read a soft maybe as a yes, and walk away "validated," having learned nothing.

This type of thinking derails the science of the experiment and turns it into a bureaucratic push, rather than a solution we have confidence in that will solve a customer problem.

So design the test to find the truth, not to win the argument. The best prototype you can run is one that's honestly capable of killing your idea.

The $15 server

Let me show you what that looks like with real money on the line.

One of my previous roles was opening an innovation lab for a large multinational company. The lab had one job: build cheap prototypes to prove out an idea quickly, before anyone spent real money. It wasn't meant to build production level applications or to build fancy tools the whole company used. Nor was it meant to be bug-free. It was meant to purely test out a concept and prove if it was worth investing additional time or money.

A request came in. A team wanted an add-on built for a tool they already used: upload a spreadsheet, run some calculations, and display the results visually so they could make decisions. Outside consultants had estimated that add-on would cost around $100,000. Before we spent a dime of that, I wanted to prototype it and see if the thing was actually worth it.

To prototype it, I needed a server. The company's process to get me one ran five to eight weeks of forms and approvals. So I made a call. I went to AWS, found a low-tier server that ran about $15 a month, and ordered it myself. A $15 expense to a billion dollar revenue company. I'd ask forgiveness later if it ever came to that.

We built the prototype in under a week, and it worked as expected. Then the requesting team got a chance to use it. That's when they realized preparing their data to upload into the tool was much more work than they'd anticipated. We proved that continued development on the tool wouldn't provide the company any financial benefit. The team then decided to continue using their current tool, and we stopped development on the one we built.

That $15 saved a $100,000 build. The experiment didn't confirm what anyone hoped. It told the truth, cheaply, before the money was gone. That's a prototype doing its actual job. Not proving you right.

And nobody ever came back to challenge the $15. People were just happy the idea got killed before the real money went out the door.

Call it whatever you want

You'll hear the prototype called a lot of things. MVP (minimum viable product, the smallest version you can ship and still learn from), MVE, MAP, pick your acronym. The one I use is MVE: Minimum Viable Experience. I get into the full definition later, in Part 05. The short version: the smallest thing you can put in front of a customer to learn whether they want the solution.

But honestly, the label doesn't matter, and people waste real energy on it. The second you release something, it's a product. Customers don't care if it's an MVP/MVE/MAP/WTF. They do not care. Your focus is solving a problem for your target market. That's it. Don't get hung up naming the thing. Build the cheapest honest test of whether you're solving a real problem, and move.

Ugly is okay

The first version is going to be ugly. That's not a problem to fix. That's the point.

This is one I teach by name: ugly is okay. The job of a first prototype is to solicit a response and get you data, not to look good. It will never be about the design as far as how easy it is to use or how good it looks. Because if you're truly solving a problem, people will use that solution. Don't get cute. Focus on getting the data.

Now the caveat, because there's a real one. Aesthetics eventually matter. As you scale, as you put the thing in front of more and more people, polish starts to count, and a bad-looking product loses you customers a good one would have kept. And if style is the requirement, if the whole point is that it looks a certain way, then design matters from the start. But that first iteration? Unless aesthetics stop you from solving the problem, don't worry about them yet. You'll have time to make it pretty once you know it's worth making.

And a prototype that bombs is not a failed prototype. If customers don't like your solution, the problem still exists, but now you know this answer was wrong. A yes and a no are both good information. The only bad outcome is no data at all.

Three questions for engineering

Engineering was already in the room when you generated concepts. Now they switch hats, because feasibility is their call, not yours. The conversation runs on three questions.

Existing. What can we build on top of? What internal or external tech, architecture, or APIs (a ready-made service other software plugs into, so you don't build that piece yourself) already exist that get us most of the way there?

New. What would we have to build from scratch? How complex is it, and roughly how long?

Assumptions. What are we taking on faith? Write them down. "We assume the payment API can generate one-click pay links" is an assumption, and naming it now means you can test the risky ones instead of discovering them halfway through a build.

That conversation is the difference between a fantasy and a plan. It's also where engineering becomes a partner in the bet, not a vendor you toss a spec to later.

Pick the right kind of prototype

Matching the prototype to the question saves you a lot of wasted motion. Marty Cagan, the product-management writer a lot of this playbook leans on, lays out four in INSPIRED and in his Flavors of Prototypes article, and I lean on his breakdown directly.

Feasibility prototypes. An engineer writes just enough code to find out if the thing is even buildable.
User prototypes. A simulation of the product that doesn't actually work underneath, and it runs the whole fidelity range. Low fidelity is an interactive wireframe: boxes and labels, no real design, low polish on purpose. You're testing the flow, not the finish. High fidelity is a realistic, working simulation, polished enough to feel like the real thing. There, the polish is the point: when a user hits a wall or bounces off it, you can trust that rejection as a real signal. A rough sketch can't earn that trust, because the user might just be reacting to how crude it looks.
Live-data prototypes. A very limited build that touches real data and gets sent real traffic, before it's ever been productized (turned into a finished, supported product the company actually sells and maintains).
Hybrid prototypes. A mix of the other three. Cagan's favorite example is the Wizard of Oz: the front looks like a real product, and a human behind the curtain does the work the software doesn't do yet.

You don't run all four. You run the one that answers the question you're actually asking. Feasibility in doubt? Build the feasibility prototype. Worried no one will use it? Put a user prototype in front of real people.

In this step, the old tradeoff is dying. For years, the reason you reached for low fidelity was speed: a high-fidelity prototype took days you didn't have, so you tested with boxes and labels and accepted the weaker signal. That's not as much of a thing anymore. With the advancements in design tools like Figma and in AI over the last year, you can build a high-fidelity prototype that matches your production look and feel in a few hours instead of a few days. So don't pick low fidelity out of habit. Pick it because it answers your question, not because you think real-looking takes too long. It doesn't anymore.

Back to our example

Run the late-paying-customer problem through it. The temptation is to go build a whole billing system. We're not. We're designing the cheapest test of our hypothesis from Step 3: that lateness is friction at pay-time (the act of paying is annoying or clunky enough that people put it off), not unwillingness to pay.

So you and the team put a few concepts on the table and narrow to the ones worth testing: a one-click pay link in the invoice email, smarter reminders before the due date, an option to pay part now and the rest later. (Illustrative, not a real client project.) Then you ask the three questions. The pay link probably leans on an existing payment API, and it's cheap to test before you build anything: send a real reminder email with a pay link that lands on a placeholder page, and count the clicks. The question is whether anyone clicks, not how it looks. You pick the concept that puts your riskiest guess on the line for the least effort, and you build the ugly version of exactly that. Nothing more.

You've got your concept and a way to test it. Next you put it in front of real customers and find out if you were right.