Customer Discovery in Early Product Work

A team that has an idea for a product often feels pressure to get the design right before showing it to anyone. This article describes a different approach: build something concrete quickly, put it in front of potential customers, and let their reactions shape what gets built next. It also examines a trap that appears once early customers begin to adopt that first version. Understanding both the approach and the trap matters for anyone who builds products, including embedded systems teams whose hardware and firmware choices depend heavily on how real users work.

The central idea of rapid prototyping is to replace guessing with a tangible object. A survey asks people to imagine how they would use something. A demo lets them react to a specific thing they can see and handle. The difference matters because people asked abstract questions often answer in general terms, while people shown a working example tend to describe their real work in detail: the kind of data they handle, the constraints they face, and the decisions they must make.

The contrast is not only about the quantity of feedback. It is about what the team learns. A survey tends to confirm general impressions. A demo tends to surface the specific details of a workflow, including the steps, constraints, and decisions that a product has to support. Those details are the material a team needs in order to decide what to build.

A prototype does not need to be complete or polished. Its purpose is to be real enough that the customer's first question concerns the work itself. A rough, working demo that a customer can click through or handle gives them something to correct. A polished presentation with no working behavior gives them little to react to.

Rapid prototyping is one step in a repeating cycle. The team builds a version, shows it to customers, listens to what they say, and rebuilds based on that feedback. Each of the four steps feeds the next. Building produces something a customer can react to. Showing puts that thing in front of the customer. Listening turns the customer's reactions into specific observations. Rebuilding converts those observations into a concrete list of edits, and the list becomes the next version to build.

The cycle does not stop after one pass. Each pass produces a new list of edits, and each list produces a new version. The loop continues until the product and the team's understanding of the customer begin to converge. Convergence means that fewer and fewer changes are needed to make the product match the customer's work. The source ties the end of the cycle to that shrinking list of changes, not to a fixed number of rounds.

Once a first group of customers finds value in a product, it is tempting to assume the product is nearly finished. The reasoning goes like this: the early users needed a certain set of features, so the next users will need roughly the same features, and the team only has to extend the same product outward. This belief is attractive because it turns a hard problem into a simple one. Each new customer becomes a copy of the last.

A common response to early success is to follow a plan that deepens the product with the first customer segment, generalizes across that segment, and only then moves on to the next one. The plan is sensible in its order, but it rests on the assumption that the first segment's needs represent the rest. When customers work in different segments, that assumption can fail.