Short answer

A product idea should not move directly into supplier sourcing. First define the customer problem, current alternatives, proposed benefit, critical assumptions, technical risks and target economics. Then test the riskiest assumption with the least expensive credible method. The goal is not to prove the original idea correct; it is to learn whether the opportunity deserves further investment.

To me, few things are more rewarding than creating something from zero to one—whether it is a company, a business model, a brand, or a product.

The dangerous moment in product development is often the moment when everyone likes the idea. The team gets excited. People start discussing features, materials, names, packaging, and launch plans. A supplier says it can be made. A few potential customers say they would buy it. It feels like progress.

But none of this proves that the product should exist. Getting from zero to one is really about answering a series of uncomfortable questions before the answers become expensive.

  • Is the problem real?
  • Does it matter enough?
  • Why would anyone switch from what they use today?
  • Can we build the product reliably?
  • And can the business actually afford to sell it?

1. Start with One Clear Sentence

Before opening a design tool or writing a product requirements document, try to complete this sentence:

A [specific product] that helps [specific group of people] achieve [specific outcome].

For example: A portable desktop device that helps frequent business travelers create a consistent workspace anywhere.

This sounds simple. It rarely is. Teams often struggle because they want the product to serve several audiences, solve several problems, and support several use cases from day one. The result is usually a vague proposition and an overloaded first version. The sentence does not need to be perfect. It needs to be specific enough to guide decisions.

2. Look for a Problem That Already Has Evidence

A promising customer is not simply someone who likes the concept. It is someone who already experiences the problem and is doing something about it. That “something” may be a competing product, a spreadsheet, a manual process, a collection of tools, or an awkward workaround invented out of necessity.

Avoid asking “Would you buy this?” Instead, ask people to describe the last time the problem occurred. What happened? What triggered it? What did they do? How long did it take? What was frustrating? Specific memories are more useful than hypothetical opinions.

3. Understand What Customers Use Today

Every new product has competition, even when no similar product exists. The competition may be another product, a service, a manual process, or simply the decision to live with the problem.

What would make someone stop using their current solution and switch?

The answer cannot simply be “more features.” It might be faster setup, better reliability, easier portability, lower total cost, or one frustrating step that has disappeared completely. A new product must overcome the cost of changing behavior, not just outperform a competitor on paper.

4. Build the Smallest Complete Experience

People often describe an early product as the smallest possible set of features. I prefer to think of it as the smallest complete customer experience. Imagine the customer’s journey from the moment the problem appears to the moment they receive value. The first version needs to support that entire journey, even if it does only one thing.

Every additional feature creates another design decision, test case, failure point, support question, and maintenance obligation. Ask whether it directly improves the main outcome, is required for safety or reliable use, and whether there is evidence customers need it now. If leaving it out changes nothing important, leave it out for now.

5. Test the Hard Parts First

Teams naturally gravitate toward the visible and enjoyable parts of development while a difficult technical or operational question remains unresolved. That is backwards. Start with the part most likely to make the product impossible.

For a physical product, that might be a custom mechanism, battery life, heat management, material performance, manufacturing tolerance, or the availability of a critical component. Speak with more than one supplier. Compare technical capability, lead time, quality systems, minimum order quantity and communication—not only price.

At what quality? At what volume? At what cost? With what failure rate? And how consistently?

6. Do the Math Earlier Than Feels Comfortable

For a physical product, cost is not just components and assembly. There may also be tooling, packaging, testing, quality control, storage, transportation, duties, damaged units, returns, warranties, payment fees and customer support. Start with a realistic selling price and work backward.

I would rather discover an uncomfortable margin problem in a spreadsheet than after the product has entered production. Cost is not something finance solves after the product is designed. It is part of the design.

7. Match the Test to the Question

There is no single activity called “product validation.” Customer interviews can show whether the problem exists, but not prove that people will pay. Concept images can show whether people understand the idea, but not prove ease of use. A prototype can test function and usability, while a pilot and paid commitment get closer to real-world evidence.

  1. What assumption are we testing?
  2. What result would count as meaningful evidence?
  3. What will we do if the result is negative?

The purpose of testing is not to defend the original idea. It is to improve the decision.

8. Keep a Short List of What Could Kill the Product

Every project has dozens of risks, but only a few can seriously damage it.

  • Customers may not care enough to pay.
  • The core technology may not perform reliably.
  • The cost may not support the intended price.
  • A critical component may depend on one supplier.
  • Certification may force a redesign.
  • Quality or logistics may become difficult at larger volumes.
  • The product may conflict with existing intellectual property.

Each risk should have an owner and a next step. Test the assumptions that could kill the project before polishing the things that cannot save it.

9. Increase Investment Only When the Evidence Improves

  1. Define the customer and problem.
  2. Understand the current alternatives.
  3. Test the product proposition.
  4. Prove the difficult technical assumptions.
  5. Confirm the economics.
  6. Run a small real-world pilot.
  7. Improve the product before expanding.

At the end of each stage, make a real decision: continue, revise, pause, or stop. The goal is not to move forward at all costs. The goal is to make the next commitment with better information than you had before.

An idea becomes a product when it solves a real problem, works outside the meeting room, can be delivered reliably, and makes economic sense. Everything before that is still a hypothesis.