How do you design a product when requirements are unclear?

Unclear requirements are an invitation to begin. Early-stage product design thrives on ambiguity, turning rough ideas into tangible concepts through collaboration, rapid iteration, and hypothesis testing, not a perfect brief.

Many assume they need to show up to a design engagement with a clear brief: a list of features, a defined user, and a product requirements document. Without it, they worry they’re wasting a designer’s time.

But the opposite is true. Unclear requirements aren’t a problem to solve before design starts; they’re exactly the conditions that good product design is built for.

Do you have a problem?

You don’t need requirements. You need a problem.

Requirements are an output of design thinking, not an input. Early-stage product design is about taking a rough idea (a scenario, a pain point, a business opportunity) and turning it into something concrete enough to react to, test, and build from.

What you need to start isn’t a spec; it’s a clear enough problem statement: who is struggling with what, and why does it matter?

Everything else gets figured out through the work itself.

Start with a conversation, not a document.

The most effective path from unclear to clear isn’t more documentation. It’s getting together, physically or virtually, and thinking out loud as a team.

A good designer comes prepared with a simple framework and probing questions (not to interrogate, but to draw out what you already know and surface hidden assumptions). They’ll sketch as the conversation evolves: rough shapes on a whiteboard that make abstract ideas visible and debatable in real time.

This process moves quickly. Sometimes a vague idea becomes a clear, shared product concept in just an afternoon. The real speed comes from working ideas out in the open; putting thoughts on paper brings clarity much faster than conversation alone.

If you’re remote, the same dynamic applies with the right tools: a shared FigJam or Miro board, a video call, and a designer skilled at facilitating, not just executing.

Design to hypotheses, not requirements

Here’s a way to unlock early-stage product work: design around hypotheses, not fixed requirements.

Every early-stage product decision is an educated guess. We think users will want to do X. We assume they’ll navigate this way. We believe this is the problem worth solving first. The designer’s job is to make hypotheses visible, testable, and cheap to invalidate.

This is why the order of steps matters. Moving from rough sketches to simple wireframes isn’t just about ticking boxes. Each level of detail prompts new decisions and helps the team focus on what matters most at that stage. Sketches answer “is this the right idea?” Wireframes answer “does this flow make sense?” Prototypes answer “do real people actually use it this way?”

You only move up in fidelity when the lower-fidelity questions are settled. This keeps the work fast, the feedback useful, and the rework minimal.

The whiteboard is doing more than you think.

When a designer sketches in front of a founder, something important happens beyond the drawing itself.

The founder reacts: “Yes, but,” or “actually, no,” or “I hadn’t thought about that.” These reactions are the most valuable data in early product design. They reveal assumptions, surface constraints, and align the team faster than any written brief could.

The best early-stage product work doesn’t start with a designer retreating to think and returning with a solution. It starts with shared thinking: messy, iterative, sometimes frustrating, that produces a product direction everyone believes in.