Map solution spaces and two personas before you build anything

The most expensive mistake in hard tech is building the first clever idea for the wrong person. Two habits prevent it. First, before committing to a product, map several solution spaces, the different families of fixes for the same problem. Second, separate the person who feels the pain from the person who pays for the fix. Done together, they turn a qualified problem into an investable plan.

What is a solution space?

A solution space is a broad category of approaches that share the same core business model and defining traits. It is not one product. It is the bucket a set of similar products lives in.

The business model is what separates one space from another. A disposable product and a reusable one aimed at the same problem live in different spaces. So do a one-time hardware sale, a subscription service and pay-per-use. That single difference changes pricing, the customer relationship, the channel and even how the product is designed.

Founders who are engineers tend to jump straight to a new device. The strongest solutions often mix perspectives instead: a new business model for existing products, an off-the-shelf component that solves most of the problem, an understanding of what customers will actually do, or a newly available technology such as a cheaper sensor or a new material. Studying how people already solve the problem today, often with improvised, low-tech fixes, is the fastest way to see which spaces are real.

How should founders compare solution spaces?

Describe at least three. For each, write down the core concept and business model, the traits that define it, one or two example solutions and the customer segments it would serve best. Then rank them and pick one to develop.

Here is a hypothetical example. Say the qualified problem is unplanned failures of pumps and motors at mid-sized industrial plants.

A retrofit sensor kit is a one-time hardware sale. A monitoring service is a subscription with recurring revenue and an ongoing relationship. Inspection as a service is pay-per-use, with a field team and very different costs. All three address the same pain. Each implies a different company.

Exploring broadly does three things. It stops the team from committing too early to its first exciting idea. It raises the odds of finding a space that matches both the team’s strengths and the market’s needs. And it gives investors evidence of discipline: a founder who can explain why one space beat two others is far more convincing than one who never looked.

Who feels the pain, and who pays?

Qualifying a problem means knowing exactly who experiences it and who makes the buying decision. They are often different people.

The user persona lives with the problem. In our example, that is the maintenance technician who gets called in at night when a pump fails. The buyer persona controls the budget. That might be the plant manager, a reliability lead or a corporate procurement team. They may never touch the equipment.

Sometimes buyer and user are the same person, as in many consumer purchases. In most industrial, energy and government markets they are not, and a product that delights the user but does not answer the buyer’s concerns will stall. The reverse is also true: a product the buyer approves but the user avoids will not be used, and will not be renewed.

What is inter-persona pain?

When buyer and user differ, a second layer of pain appears between them. The pain is shared and passed back and forth. The technician’s overtime and frustration become the plant manager’s labor cost and morale problem. The manager’s pressure on uptime becomes the technician’s stress. Pain here takes several forms: physical discomfort, opportunity cost, social and emotional strain, health and safety risk, and legal or regulatory exposure. Each persona weighs them differently. The user may care most about safety and dignity at work. The buyer may care most about cost, liability and ease of maintenance.

Products that relieve both sides, and the friction between them, are the ones that get bought and used. That is also why we map the full set of people around a purchase in the buying table, and why pain and urgency come before pricing power.

How we see it

Our rule of thumb is simple: a team is not ready to build until it can name three solution spaces, explain why it chose one and describe both personas and the tension between them. It sounds slow. In practice it is the fastest way to avoid a year spent building a product the buyer will not fund or the user will not adopt. Hard tech is expensive to iterate. The cheapest iterations happen on paper, with customers, before the first part is ordered.

Frequently asked questions

What is the difference between a buyer persona and a user persona?

The user persona is the person who experiences the problem directly, day to day or in the moment. The buyer persona is the person or role who makes or approves the purchase decision. Sometimes they are the same person, as in many consumer purchases. In most industrial and government sales they are different, and a product has to satisfy both.

What is a solution space in startup ideation?

A solution space is a broad category of solutions that share the same core business model and defining traits. A disposable product and a reusable product aimed at the same problem sit in different solution spaces, because their pricing, customer relationship, distribution and design all differ.

How many solution spaces should a founder explore?

We suggest describing at least three distinct solution spaces, each with its business model, defining traits, example solutions and likely customer segments, then ranking them before choosing one to develop into a venture thesis.