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 is faster than it sounds. It’s not uncommon to go from a vague idea to a shared, tangible product concept in an afternoon—not because the designer has all the answers, but because externalizing thinking forces clarity in a way that conversation alone can’t.

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 the reframe that unlocks early-stage product work: you’re not designing to requirements; you’re designing to hypotheses.

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 sequence matters. You move from rough sketches to lightweight wireframes, not because wireframes are a box to check, but because each stage of fidelity forces a different kind of decision. 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.