Products the Market Actually Needs

Most product development advice is written for software. The feedback loops are tight, the cost of a wrong turn is mostly engineering time, and a product that misses the market can be pivoted. Hardware-software products work differently. By the time the product is manufactured and in the field, the design decisions made nine months earlier are facts. Getting those decisions right requires a different discipline.

The specific challenge is that hardware lead times mean the business is always betting on what the market will want when the product arrives, not what it wants during design. In a stable market, that is manageable. In a market where the competitive landscape is shifting, that is a substantial bet on a 12 to 18 month forecast. The cost of misreading it is not a refactor. It is an inventory write-off and a respin.

What the market intelligence problem actually is

The companies I have seen get this wrong most consistently are not the ones that did no market research. They are the ones that did market research that told them what their existing customers liked about the product they already had, and then used that to extrapolate the features of a product those customers might buy later.

That approach systematically misses two things. The first is the non-customer: the person who would consider buying but finds something about the current product wrong in a way that a survey of current customers will never surface. The second is the purchase decision, which is not the same as the usage decision. A feature that users value once they have the product does not necessarily drive the decision to buy it.

The discipline I have found useful is to start from the purchase moment, not the usage moment. Who is making the decision, what are the two or three things they are using to compare options, and what is the threshold for each of those things? Getting granular on that question usually produces a very different feature priority list from a user satisfaction survey.

The MVP problem in hardware

Agile product development and minimum viable product thinking originated in software, where shipping an incomplete product and learning from its use is a reasonable strategy. In hardware, the equivalent approach requires more care. A half-finished circuit board cannot be sent to the field and patched remotely. The test needs to happen before manufacturing commits.

What does transfer from software thinking is the underlying principle: test the riskiest assumptions first, with the minimum investment required to get a real signal. In hardware-software products, this often means separating the layers. The software behaviour can be prototyped and user-tested long before the hardware is final. The hardware can be tested with representative users in controlled environments before volume manufacturing is approved.

The interface design can be validated with a simulation. None of that is as clean as deploying a web app and watching usage data. But it is much better than committing a production run on assumptions that have not been tested.

Where the decisions actually get made

The most important design conversations happen early, when everything is still flexible and the engineering team has the most options. The most useful customer input, therefore, needs to arrive early too. The pattern I have seen fail most often is: build the product, then talk to customers. By the time the customer says something important, it is either too late to act on it or the cost of acting on it has become very high.

The companies that handle this well build the customer conversation into the design process from the beginning, not as a checkpoint at the end of development. They treat the design brief as a hypothesis about what the customer needs, not as a specification derived from what the team already knows how to build. The discipline is to keep asking whether the evidence supports the hypothesis, and to do that asking before the point where the answer can no longer change the decision.

The CTO’s specific role in this

The product manager owns the market definition. The CTO owns the question of whether the architecture being built can actually support the market position being claimed. Those two things need to be in conversation, and the CTO is the person who has to initiate it if it is not happening naturally.

The most expensive mismatch I have seen repeatedly is a product being positioned on capabilities that the architecture was never designed to support at scale. A connected device marketed on real-time data and remote configuration, built on an architecture that handles neither reliably. A hardware product marketed on easy integration, built on a stack with no stable API and documentation that was out of date before it shipped. The commercial team was not lying. They were describing what the product was supposed to do. The technical architecture could not deliver it at the volumes and reliability levels the market expected.

That conversation needs to happen before the marketing claims are set, not after the first enterprise customer tries to deploy at scale. The CTO who is not in the room when the positioning is being defined is not protecting the business from that failure. They are just not present when it is being set up.