A common concerns I hear from founders is, "I've explained the product several times, but the design team still doesn't get it." Their assumption is usually that the designers lack domain knowledge or aren't asking the right questions. While that does happen occasionally, the real problem is something else entirely.
The reality is much simpler. By the time a founder begins working with a design team, they have often spent months, or even years, thinking about the product. They have refined the business model, spoken to customers, debated priorities with co-founders, and mentally simulated countless scenarios. The product has become so familiar that it feels obvious. The design team, on the other hand, is seeing it for the first time. Their understanding begins at zero.
This gap isn't caused by poor communication, poor design, or lack of empathy. It's a inevitable consequence of trying to transfer a complex mental model from one person's mind into another's. Until that shared understanding exists, designers make assumptions, and assumptions are where misunderstandings begin.
1. You know your product better than anyone else
You don't consciously leave out important information. You simply stop noticing what needs to be explained because you've lived with the product for so long. Customer pain points, business terminology, workflows, and relationships between different parts of the system all feel obvious to you. Unfortunately, what feels obvious to you is often completely invisible to someone seeing the product for the first time. Imagine trying to explain how to drive a car to someone who has never seen one before. You'd probably say, "Start the engine, put it in first gear, and slowly release the clutch." But you've already skipped dozens of assumptions. Which pedal is the clutch? How do you start the engine? What does "first gear" mean? Where's the ignition? These things have become so automatic that you no longer notice they're knowledge at all.
Designers aren't looking for a quick feature overview. They're trying to build an accurate mental model of the product itself. That means understanding who the users are, what problems they're trying to solve, how they think, and why each part of the product exists. Without that context, even experienced designers are left filling in the gaps themselves.
2. It's difficult to explain everything that's in your head
You don't see your idea as a collection of screens or features. You think about customers, their pain points, business goals, workflows, edge cases, and years of accumulated decisions. Translating that rich mental model into something a design team can fully understand takes time, and it's far more difficult than most founders expect.
As a result, explanations often jump between the business problem, individual features, future ideas, implementation details, and customer stories. Since everything has a reason behind it, everything feels important. Designers then face the challenge of identifying what the primary workflow is, what belongs in the first release, and what can wait until later. Those questions aren't slowing the project down—they're helping establish structure where, until then, there was only knowledge.
3. Some of the most important details never get said
Every product has business rules that determine how it behaves. Users may require approvals before they can continue. Different roles may have different permissions. Certain actions may only be available under specific conditions. Some customers qualify for features that others never see. These rules shape the user experience far more than colours, layouts, or components.
The challenge is that founders often don't think to explain these rules because they've become second nature. They don't feel like product features—they simply feel like "the way the business works." Experienced designers are trained to look beyond what's explicitly stated. They ask questions, look for implicit requirements, challenge assumptions, and try to uncover the underlying business logic. But no designer can infer everything. Some rules are simply impossible to discover unless they're explained. When those rules remain unspoken, designers inevitably end up designing around assumptions instead of reality.
4. Designers think differently from founders
Founders naturally think about solutions. It's common to say, "Let's have a dashboard here," or "This should work like WhatsApp," because those are easy ways to communicate an idea. Designers, however, are listening for something different. They want to understand what the user is trying to accomplish before deciding how that experience should work.
One way to think about this is that founders often describe products as nouns, while designers solve them more effectively when they're expressed as verbs. A founder might say, "We need a chat application." That's a noun—it describes a solution. A designer hears something more useful when it's framed as, "Our teams need to communicate and collaborate more effectively." That's a verb—it describes the outcome you're trying to achieve. Once the underlying goal is clear, a chat application might be the right answer—but it might not be. It could turn out that comments on tasks, shared workspaces, or better notifications solve the problem more effectively.
This is why designers often respond with questions instead of mock-ups. They aren't challenging your ideas or trying to make the process more complicated. They're trying to understand the outcome you're aiming for so they can explore the best way to achieve it. Sometimes the interface you've imagined is the right answer. Sometimes there's a better one. That possibility only becomes visible when the conversation starts with the user's goal rather than a predefined solution.
5. The conversation makes the product stronger
Many founders are surprised that some of the best product discussions happen while explaining the product rather than after the designs are produced. A seemingly simple question from a designer can uncover an edge case, reveal an assumption that was never articulated, or expose a workflow that only existed implicitly. These aren't signs that the product wasn't well thought through. They're signs that complex ideas become clearer when they're shared and challenged from another perspective.
This is why early design conversations are so valuable. They're not simply about collecting requirements for screens. They're about building a shared understanding of the product before anyone begins deciding what the interface should look like. Once that shared understanding exists, design becomes faster, feedback becomes more meaningful, and both founder and designer are working towards the same vision.
If you've ever wondered why your design team doesn't immediately "get" your product, the answer is probably not that they're incapable of understanding it. It's more likely that they're trying to understand months of thinking that currently exists only in your head. The earlier that knowledge becomes shared, the easier every design decision becomes afterwards.
