Discovery - How to Set Your Product Development Up for Success

How to run a discovery phase for a hardware product: gather what exists, define functional requirements, map constraints and plan before you design.

By Nathan Ruttley, CEO and Co-Founder·1 December 2025·4 min read

Every successful product begins long before sketches turn into prototypes.

We make early design decisions based on the information we have at the start of a project. These design decisions often set the trajectory for the entire project, so it's best to base those decisions on good information. This is why we ask questions and challenge assumptions to gain clarity before pen hits paper (or the mouse hits the CAD?).

Discovery is the name of this early exploration stage. If you like TRLs, discovery covers TRL 0-2.

Why the discovery phase matters

What is the product? Why does it exist? What constraints shape it? What does it do?

Answering these questions ensures that there is a shared understanding across the team. Only once there is an agreed, and shared, understanding of what is being built does it make sense to build it.

Neglecting this step often leads to:

• Misaligned expectations
• Overlooked requirements
• Design dead-ends
• Costly redevelopment
• Regulatory or technical surprises

Discovery doesn't eliminate risk, it reduces the number of "unknown unknowns". These are often what derail a project.

The core goal of discovery: clarity

At its heart, Discovery is about answering three essential questions:

1. What does this product need to do? Not what it might do or what it could do, but what it must do to succeed.
2. What information already exists? Notes, thoughts, early sketches, competitor analysis, customer insights, shower epiphanies.
3. What constraints will shape the solution? Technical, regulatory, commercial, user-driven, logistical, financial.

Answering these questions doesn't make development and engineering easy, but it will allow you to chart a focused and efficient path to success.

How to run an effective discovery phase

Here come the lists and thought prompts! Most teams will benefit from the following activities.

1. Gather and review existing material

Before creating anything new, collect and assess what already exists. This might include:

• Early concepts or sketches
• Notes from previous attempts
• Technical documents
• Market research
• Prototypes or partial builds

What you're looking for: emerging themes, red flags, bias.

2. Speak with key stakeholders early

Stakeholders have retained knowledge across a broad spectrum of areas. Take time to talk with:

• Founders or product owners
• Engineers or technical leads
• Designers
• Manufacturers or suppliers
• Potential end-users

One or more of these people might be you, so dig deep!

3. Define the product's functional requirements

Functional requirements describe exactly what the product must do. They should be written in plain language and agreed upon early.

Think:

• "Must measure X range with Y accuracy"
• "Must operate for at least Z hours on one charge"
• "Must pass A regulatory test"

Clear functional requirements prevent scope creep and guide engineering choices.

4. Map out constraints and risks

Consider anything that could impact how the product is designed or built:

• Regulatory compliance
• Safety considerations
• Production volumes
• Target cost per unit
• Environmental conditions
• Unknowns that need validation

Listing these early reduces surprises later.

5. Outline a development plan

Plans can change, but it's best to start with something rather than winging it. This usually includes:

• Key milestones
• Estimated timelines
• Budget expectations
• Responsibilities
• Technical checkpoints
• Early thoughts on testing and validation

A plan brings structure, and structure creates momentum.

What good discovery produces

At the end of this phase, you should be able to produce a short collection of documents or notes that capture your team's shared understanding. These often include:

• A concise functional specification
• Draft technical direction or assumptions
• A basic test plan
• A rough project timeline and resource estimate
• A compliance or regulatory overview
• An outline of production or manufacturing considerations

These don't need to be perfect, some of these might be "working documents". So long as they are clear, helpful, and agreed upon you're good to go.

When discovery is "done enough"

Discovery doesn't have to be exhaustive. The right stopping point is when:

• Everyone understands the problem being solved
• The team can articulate what the product must do
• The biggest risks or unknowns are identified
• There's enough structure to confidently move into deeper engineering

<insert cheesy image of engineers who are happy they have design clarity>

What comes next: feasibility

Once you know what you're building and why, the next challenge is ensuring that your product is actually viable. That's where the Feasibility phase comes in. Feasibility focuses on validating assumptions, testing critical unknowns, and reducing risk.

Part 2 of this series covers how to approach feasibility work, what kinds of experiments matter most early on, and how to avoid wasting time on the wrong technical pathways.