Prototypes are awesome. I want to start here and emphasize it again — good prototypes are awesome because they turn abstract ideas into something tangible. Instead of debating an idea endlessly in a conference room, you can put something in front of people, watch what happens, learn from it, and improve it. Done well, prototyping can help teams learn in days what might otherwise take months… and avoid investing significant time and money in something that ultimately doesn’t work.
But there’s a catch: a prototype can only test the thinking you put into it.
A prototypes’ purpose isn’t to make your idea look real enough that everyone gets excited about it. Its purpose is to expose what you don’t know while changing direction is still relatively cheap.
Too often, teams treat prototyping as the beginning of experimentation when, in reality, some of the most consequential decisions have already been made.
Think of this scenario: The team has decided what the problem is and someone has decided what users need. A solution has started to take shape. Technology choices are floating around and someone is inevitably looking into what AI solutions can be tested. Then everyone gathers for the exciting part: It’s time to prototype.
That’s why some prototypes fail before anyone builds a single screen. Too often, by the time a team starts prototyping, some of the most important decisions have already been made… or worse, assumed.
Doomed vs. Successful Prototype
Here are five reasons why a prototype might be doomed before the first screen is ever designed:
1. Your team isn’t aligned on the problem you’re actually solving.
One of my favorite exercises with a team is also one of the simplest: ask everyone in the room to independently (and without visibility into others’ answers) finish the sentence, “The problem we are trying to solve is…” Then compare the answers.
It is amazing how quickly you can discover that a group of smart, capable people who have been working on the same project for months are actually trying to solve several different problems. The product leader may describe a customer problem while engineering may describe a systems problem. In the next room over, sales may be responding to something prospects keep requesting, and leadership may see a new revenue or market opportunity. Every one of those perspectives may be valid, but they aren’t necessarily pointing toward the same problem.
The danger is that once you create a prototype, it can give those unvalidated assumptions a sense of legitimacy. Instead of continuing to ask whether this is the right problem to solve, everyone starts debating workflows, features, buttons, and functionality. You have moved into solution mode without ever reaching real agreement about what the solution is supposed to accomplish.
That distinction matters. McKinsey’s extensive research into the business value of design found that high-performing organizations don’t treat design as an isolated creative exercise. They combine analytical leadership, cross-functional collaboration, user insight, and continuous testing throughout development. In fact, their research found that the strongest design performers significantly outpaced industry peers in both revenue growth and shareholder returns.
Before you prototype anything, your team should be able to clearly articulate the problem you are solving, who experiences that problem, why it matters, and what would be meaningfully different if you solved it.
2. You think you know your users — but you don’t know them well enough.
Most teams aren’t ignoring their users. The problem is that they often substitute proximity to customers for actual understanding of them.
I bet this sounds something like what you’re hearing: Sales talks to customers every day. Customer success is listening to every customer complaint. Leadership has worked in the industry for twenty years and knows what customers need best. Someone on the product team personally fits the target customer demographic, so they know what’s best. Those perspectives are useful, but none of them eliminates the need to spend time with the people who will actually use what you’re building.
Good user research goes beyond asking people whether they like an idea. You want to understand what they’re trying to accomplish today, how they’re currently doing it, what frustrates them, what workarounds they’ve invented, what constraints influence their behavior, and where what people say they need differs from what you can observe them actually doing.
This is one place where the business research is particularly striking. McKinsey found that only approximately half of the companies it studied conducted user research before generating their first design ideas or specifications, while more than 40% weren’t talking to end users during development at all. (This is shocking!) The higher-performing design organizations took a different approach, continually bringing user insight into the process and combining qualitative research with quantitative data.
The goal isn’t to ask users to design your product for you. It’s to understand their world well enough that the thing you eventually prototype is rooted in an actual problem rather than your team’s best guess about one. They may not be able to hand you your next great idea, but they sure can tell you the friction you need to solve that will lead to it.
3. You haven’t done enough discovery before falling in love with a solution.
This may be the easiest trap of all because jumping to a solution feels productive. Someone has an idea, everyone gets excited about it, and suddenly the conversation moves from “What exactly is happening here?” to “How quickly can we build this?”
The problem is that solutions are comfortable. Problems are messy.
Discovery requires you to stay in that messy space a little longer and separate what you actually know from what you believe to be true. It means asking what evidence supports your assumptions, what might contradict them, whether there are other explanations for what you’re seeing, and whether you’re treating a symptom as the underlying problem.
That does not mean every project needs six months of discovery, 100 user interviews, and a 200-slide research deck before anyone is allowed to make something. In fact, I would argue the opposite. Good discovery should help you move faster because it focuses your next investment on the things you most need to learn and the risks you most need to overcome.
McKinsey’s research also supports this iterative approach. Its analysis of 300 publicly listed companies found that stronger design organizations continually listened, tested, and iterated with users rather than treating research and prototyping as discrete stages. Nearly 60% of the companies it studied were still using prototypes primarily for internal production testing late in development, while the more successful organizations deliberately exposed early concepts to outsiders and learned from them sooner.
The fastest route to a prototype isn’t necessarily the fastest route to the right prototype. Sometimes a few days of focused discovery can prevent months of beautiful execution of the wrong idea.
4. You’re testing the interface, but you’re not testing the thing most likely to break.
I love a good clickable prototype, but a beautiful Figma experience can create a dangerous illusion: everything works perfectly when all of the data is imaginary.
In many real-life projects, a concept might depend on integrating information from multiple existing systems. Perhaps an existing or new API needs to return information in real time. Maybe you need to reconcile messy data from multiple sources, accommodate complex role permissions, work within an organization’s legacy infrastructure, or prove that an AI model can perform a particular task reliably enough to make the experience useful and trustworthy.
If one of those things determines whether your solution is viable, it belongs in your prototyping strategy.
To be clear, a design prototype may not be enough and engineering should sit at the strategic planning table from the beginning for this reason (amongst others).
To be clear, we are looking to build what I call a “Band-aid Prototype.” You don’tneed to prematurely build the entire technical architecture and all of the product features. It means asking a slightly different question: What is the riskiest assumption we’re making about whether this can actually work, whether the technology we are choosing to use will work as we intend, and what is the smallest thing we could build or test to learn whether we’re right?
Often the answer is an experience prototype that helps you determine whether users understand and value the concept. Sometimes it’s a technical proof of concept or engineering spike that has almost no interface at all. Often, you need both.
McKinsey’s research into design practice specifically calls out the importance of integrating user, business, competitor, and technological research rather than allowing development functions to work in isolation. It also found that organizations emphasizing early, frequent prototyping can avoid expensive mistakes later in development.
A prototype shouldn’t just test what is easiest to show. Prototype the risk, not just the screen.
5. You haven’t invited enough different minds into the ideation process.
This may be the most underestimated problem because when organizations assemble teams to solve difficult problems, the instinct is often to find the people with the most expertise. Bring in the best product person, the strongest engineer, the experienced designer, and the executive who knows the industry inside and out. Those are all valuable people to have in the room, but expertise and perspective aren’t the same thing.
One of the most interesting studies on problem-solving diversity comes from researchers Lu Hong and Scott Page, who modeled teams of problem solvers and found that, under the conditions they studied, groups with greater functional diversity could outperform groups composed exclusively of the individually highest-performing problem solvers. Their explanation is especially relevant to innovation: when you select only the highest performers, you can inadvertently select people who approach problems in similar ways. Different problem solvers bring different representations of the problem and different methods for searching for solutions.
Research discussed in Harvard Business Review points in the same direction. Alison Reynolds and David Lewis found that cognitively diverse teams (people who differ in how they process information, approach uncertainty, and work through problems) tended to solve complex problems faster. Their subsequent analysis of senior teams similarly found cognitive diversity to be an important characteristic of faster problem-solving groups.
That’s why your ideation team shouldn’t simply be a collection of people with different job titles. Bring in the engineer who will challenge whether the premise makes sense. Bring in the customer-facing employee who has watched users invent bizarre workarounds for years. Bring in your new product manager from outside the industry and organization who hasn’t yet learned which questions they’re “not supposed” to ask. Include different disciplines, backgrounds, lived experiences, levels of expertise, and ways of approaching uncertainty.
You don’t need five smart people looking at the problem in the same way. You need smart people capable of seeing five different versions of the problem.
And 5 Things You Can Do About It
The good news is that none of these problems requires you to introduce a giant new product-development process. In fact, the point is to do just enough work before and during prototyping to expose the assumptions that could otherwise become expensive mistakes.
1. Write the problem down before anyone starts designing the solution.
Get the people who matter into a room and have everyone independently define the problem. Compare the answers and talk through the differences until you can create a shared problem statement that identifies who is experiencing the problem, what is happening, why it matters, and what evidence you have that the problem exists. There are additional problem-solving workshops you can add to this to really explore the problem — don’t forget to ask 5 why’s and always peel back that problem onion ;)
Don’t worry about making the language perfect at this stage. You’re not writing website copy. You’re trying to expose disagreement.
Then go one step further and define what success would actually look like. If you can’t agree on what would change if you solved the problem, you’re probably not ready to start evaluating solutions yet. Ask yourselves the question, “If nothing changes, what would be the consequence?”
2. Spend time with actual users before you decide what to prototype.
You don’t need a massive formal research study to learn something useful. Talk to five people a week. Share it with your neighbor who works in the industry for commentary. Observe someone completing the existing process and ask them why they make the decisions they do. Ask users to walk you through the last time they experienced the problem instead of asking what features they’d like in a hypothetical solution. And, hey, conduct user research too, because the best insights can come from these interactive engagements with users.
What’s most important is that you pay attention to the gaps between the official process and what people actually do. Workarounds are incredibly valuable clues because they show you where a system, product, or process isn’t meeting someone’s real needs.
McKinsey’s findings make the business case for this particularly well: successful design organizations continually combine qualitative and quantitative customer insight rather than treating user research as a one-time validation exercise.
Your job isn’t to collect enough quotes to prove your idea is good. Your job is to learn something that could change your idea.
3. Make your assumptions visible (and rank them by risk).
Before building anything, get the team’s assumptions and hypotheses out of everyone’s heads and onto the wall.
“We believe users have this problem.” “We believe this problem matters enough for them to change their behavior.” “We believe this workflow will make their lives easier.” “We believe this data exists.” “We believe these systems can integrate.” “We believe people will trust this recommendation.” “We believe the organization will pay for this.”
Then ask two questions about every assumption: How important is this assumption to the success of the idea, and how much evidence do we actually have that it’s true?
The assumptions that are both critical and poorly supported should become your testing priorities. This changes prototyping from “Let’s make our idea real” to “Let’s figure out where our idea could be wrong.”
That’s a much more useful reason to prototype.
4. Build the smallest prototype that tests the biggest risk.
Once you know your riskiest assumptions, don’t automatically jump to a polished end-to-end prototype. Match the prototype to the question you’re trying to answer.
If you’re unsure whether users understand a workflow, a clickable prototype may be perfect. If you’re unsure whether an API can return the data quickly enough, build a technical proof of concept. If you’re unsure whether customers care enough about the problem to pay for a solution, a landing page, concept test, or even a sales conversation may tell you more than a functioning application ever could.
The goal isn’t fidelity. The goal is learning per dollar and learning per hour.
Prototyping cheaply and early can help organizations avoid much larger, more expensive mistakes downstream. The best prototype isn’t the most impressive one. It’s the cheapest thing that gives you credible evidence about your biggest uncertainty.
5. Deliberately invite people who will see the problem differently.
Don’t wait until you’ve created the prototype to ask a broader group for feedback. Diversity is most valuable when it influences how you frame the problem and generate possibilities, not simply when people are invited to react to a solution someone else has already created.
Think deliberately about who is missing from the room. Who interacts with this problem differently? Who is most affected by the problem? Who understands the technology but not the industry? Who understands the customer but isn’t part of product development? Who is new to the organization? Who has historically disagreed with this team? Who approaches problems differently from you?
The research on cognitive diversity is especially relevant here because the advantage doesn’t come simply from assembling more smart people. It comes from increasing the number of ways the group can represent, explore, and attack the problem.
And don’t just invite those people after the idea has been decided. Give them permission to challenge the problem statement itself.
Because sometimes the person who contributes the most valuable thing to your prototype is the person who asks, “Wait. Why are we building this at all?”
The Prototype Isn’t the Beginning
We tend to treat prototyping as the beginning of experimentation, but by the time you build a prototype, you should already have been experimenting with your understanding of the problem, your assumptions about users, your technical constraints, and the different ways the problem might be solved.
That’s also why I don’t think the lesson here is “prototype more.”
It’s “learn earlier.”
McKinsey’s research into 300 companies found that the strongest design performers weren’t simply better at making things. They put users at the center, worked across functional boundaries, measured what mattered, and continually tested and iterated from the earliest ideas through launch. Those top-quartile design performers substantially outperformed their industry peers financially.
A prototype is simply one tool in that learning process. Its purpose isn’t to make your idea look real enough that everyone gets excited about it. Its purpose is to expose what you don’t know while changing direction is still relatively cheap.
Because sometimes a successful prototype confirms that you’re onto something.
Sometimes it tells you to change the solution.
And sometimes the most valuable outcome is realizing that you were solving the wrong problem in the first place.