How to Make a Product People Want: Iterate, Test, Build to Last

How do you make a product people want? "Make something people want" is Y Combinator's motto, and it is hard to follow, because the team that builds the product is badly placed to judge whether anyone wants it. For hardware it is harder still: changes get expensive the moment you commit to tooling.

The way through is two phases in order. First iterate cheaply with real people until you have found the product worth building. Then engineer that product to last. Skip the first and you build something nobody wants; skip the second and you build something nobody keeps. This guide covers both, with practical steps for hardware teams.

Start with the question you need answered

Every prototype should answer a question. "Does it work?" is rarely the right one. Better ones are: Will people understand it without being told? Will they use it more than once? Would they pay, or switch from what they use today? Write down the three assumptions that would sink the product if they were wrong, and build the cheapest thing that can test each of them.

This is what iterative design means in practice. The Interaction Design Foundation describes a cycle of creating a design or prototype, testing it, gathering feedback and refining it, repeated until the product suits its users, and advises aiming for "good enough to learn from" rather than perfect. Y Combinator gives the same advice for startups: launching a mediocre product early and then talking to customers beats waiting for the perfect one.

Prototype in rising fidelity

Matching the prototype to the question keeps cost low. Nielsen Norman Group notes that low-fidelity prototypes take less time to prepare, put less pressure on users, and designers feel less wedded to them; its point is that ripping up a prototype is cheap, while ripping up finished code is not. The same holds for tooling. A ladder that works for hardware:

• Foam or cardboard: size, grip, weight, where it sits on a desk or a body. Hours of work.
• 3D-printed shell: button placement, display visibility, how it feels in a hand, assembly order.
• Development board with the real sensors: does the sensing or radio work in the real situation? No custom PCB yet.
• Clickable app mock-up: whether people understand the flow, before any app code exists.
• Functional prototype: custom board, printed or machined housing, real firmware. Only when the earlier steps have answered what they can.

Test with real people, and watch

Nielsen Norman Group reports that five users find about 85 percent of the usability problems in a design, an average that assumes one group of users doing similar tasks. It recommends several small rounds with fixes in between rather than one large study: three studies of five beat one study of fifteen. That is about usability, not demand. It tells you whether people can use the thing, not whether they want it, so test both.

How to run a session

1. Pick people who have the problem, not colleagues and friends.
2. Give them a task, not a tour: "set it up and log today's reading". Say nothing else.
3. Watch where they hesitate, pick it up the wrong way or reach for something that is not there. Write it down, do not fix it live.
4. Ask afterwards what they expected, and what they would do next. Do not ask whether they like it.
5. Look for patterns across people. One person's oddity is a note; the same stumble three times is a design change.
6. Fix the biggest problems, rebuild, and run the next round.

Testing demand

Opinions are cheap. Commitments are a better signal: a signed pilot, a deposit, a waiting-list that people join with real details, a customer who lends you their site for a month. Ask for something that costs the person a little, and treat compliments as noise.

For connected products, test in the real place: the barn, the kitchen, the pocket. Range, noise, light and habits do not show up on the bench. Our guide to the five gates from prototype to shipping sets out the stages of fidelity and the decision you make at each one.

Iterative product development: know when to stop

Iteration has to end somewhere, or you never ship. A rule that works: stop when the last round of testing no longer changes the design in ways that matter, and the open risks are about manufacturing, not about the idea. At that point you freeze the things that are expensive to change, and only then commit to tooling.

• The enclosure outline, mounting points and button positions, before mould tools.
• The board outline, connector positions and radio placement, before the production PCB run.
• The interface between device and app, before either is polished.

The cost of a change rises at every step: a conversation in the concept phase, a new board revision during layout, new tooling after the mould is cut. We do not quote figures because they vary by product, but a change nearly always costs more the later it comes. The board side is in our guide to PCB design mistakes.

Then build it to last

The European Commission says that much of a product's environmental impact is determined at the design stage. That is the best argument for treating longevity as a design requirement, not an afterthought: you cannot add repairability to a glued shell.

Materials and finish

Choose materials by how they age, not only how they look on day one. Ask your supplier for samples and age them: leave them in sun, rub them, wipe them with the cleaners real users use. A finish that looks right in the render can change with sun, wear and cleaners, which is why you test aged samples.

Modular and serviceable

• Put wear parts, such as the battery, the cable and the buttons, where they can be reached.
• Prefer screws and connectors to adhesive and solder where the part may need replacing.
• Use a bootloader and over-the-air updates, so firmware can improve after sale.
• Document the interfaces between modules so a later version can reuse them.

The rules now behind this

This is no longer only good practice; EU law now requires parts of it, and more is coming:

• Right to repair, Directive (EU) 2024/1799. Member states had to bring it into national law by 31 July 2026. For goods that have repairability requirements under other EU law (listed in its Annex II), the manufacturer must repair on a consumer's request unless repair is impossible, free of charge or at a reasonable price and within a reasonable time, and must offer spare parts at a reasonable price.
• Removable batteries, Regulation (EU) 2023/1542, Article 11. For appliances placed on the EU market from 18 February 2027, portable batteries must be readily removable and replaceable by the end user with commercially available tools. There are exceptions, including appliances regularly exposed to water, where independent professionals may replace the battery instead.
• Ecodesign for Sustainable Products, Regulation (EU) 2024/1781. In force since July 2024. It lets the EU set durability, repairability and recyclability requirements by product group, and introduces a digital product passport, a scannable tag with product sustainability information.

How we work on this in projects

We run the first phase as a short, cheap loop and the second as engineering. For an idea we have not yet proven, a two-week Concept Sprint establishes whether it is buildable and what it would take, and an MVP Sprint can follow with a proof of concept from off-the-shelf parts. The same team designs the product, the electronics, the firmware and the app, so a finding from a test reaches the right place quickly.

Some examples from our own work, with the status each has today. Pebble, a wireless environment sensor with no screen that reports through a slow, shifting glow, is in development. Tally Keys, a Bluetooth keypad that logs one thing a day into a year-grid in an app, is a concept, and the images are design sketches. ARCIVE, a memory companion, is in development; we have built its apps, its back end and the firmware for a wireless capture device. Hoviv, a cattle wearable, has a delivered system design, and the build awaits funding.

Frequently asked questions

How do you make a product people want?

Find the assumptions that would sink the product, test each cheaply with real people, fix what they stumble on, and only then commit to tooling. Y Combinator's advice is to launch something early and talk to users rather than wait for a perfect product.

What is iterative product development?

A repeated cycle of building a prototype, testing it with users, collecting feedback and refining the design, until the product suits the people it is for.

What is rapid prototyping?

Building quick, cheap versions of a product, such as foam mock-ups, 3D prints, development boards and clickable apps, to test one question at a time before investing in the final design.

How do you get user feedback on a hardware prototype?

Give people with the problem a task, watch them do it in a realistic setting without helping, and note where they hesitate. Several small rounds with fixes in between work better than one large one.

What is sustainable product design?

Designing for long life, repair and recycling from the start, because much of a product's environmental impact is decided in design. In the EU that now includes repair obligations, user-replaceable batteries from 2027 and a coming digital product passport.

Have an idea you want to test?

See how our consulting and Concept Sprint work, or book a short call and tell us what you are making. We will help you work out what to test first.

Sources

Checked on 2 October 2026:

1. Y Combinator: YC's essential startup advice
2. Interaction Design Foundation: iterative design
3. Nielsen Norman Group: low-fidelity vs high-fidelity prototypes
4. Nielsen Norman Group: why you only need to test with 5 users
5. EUR-Lex: Directive (EU) 2024/1799, common rules promoting the repair of goods
6. EUR-Lex: Regulation (EU) 2023/1542, batteries and waste batteries
7. EUR-Lex: Regulation (EU) 2024/1781, ecodesign for sustainable products
8. European Commission: sustainable products to be the norm
9. EFTA: EEA-Lex factsheet, Directive (EU) 2024/1799
10. EFTA: EEA-Lex factsheet, Regulation (EU) 2023/1542
11. Haavind: right to repair, expected implementation in Norway