What Makes a Product Worth Building?

A product team can polish a demo and still not know whether it should support a real decision.

Imagine an operations lead deciding where to assign staff across sites. The recurring reports count completed visits differently and cover different periods. The team has tried combining them, but the numbers still cannot support a comparison anyone trusts. That gives a product team a project to investigate.

Suppose the team builds an assistant to help. In a demo, it produces a clear comparison even though one site's data is missing. The answer looks ready to use. Acting on it could leave the wrong site understaffed.

The project justifies learning. A build, a release, or a standing operating cost requires separate evidence. The team also needs to name what it will focus on, what it will defer, who will operate and maintain the result, and what other work the commitment displaces.

The phases describe where the product is. The gates justify whether to make the next bounded commitment:

Idea → Project → Prototype → Demo → MVP → Product → Business

This is my working model. Project means someone else's effort to solve a problem that matters to them. They can describe what they have tried. A prototype tests a question the team needs to answer. A demo shows the proposed experience. A minimum viable product (MVP) is the first limited version people can rely on for its stated purpose. Product means people can use it to do the work and keep using it when the need returns. Business means the team can keep finding and serving customers at a cost it can sustain.

A phase does not authorize the next phase. Learning continues across the path, and payment can arrive before a finished product. A prototype may send the team back to the person's project. Each gate asks what this commitment will make possible, what it will cost to operate and maintain, and what other work the team is choosing to defer.

1. The Demand Gate: Find another person's project

Idea → Project

Start with an account from someone doing the work. For the reporting assistant, what comparison did the operations lead need? Why did it matter? What did they try, and where did it fall short?

Rob Snyder's PULL framework asks what project the person cannot put off, what options they have, and why those options fall short. The project exists whether or not you build anything. Completing a recurring report is a project. Buying an assistant is a proposed way to accomplish it.

The Demand Gate justifies a bounded investigation. Record the person's work, its importance, their attempts, and what remains unresolved. Name the question the team will investigate. Defer the interface, integrations, and broader workflow until the project earns that attention.

One account is a reason to investigate. It does not prove that others face the same problem or would commit time or money to solving it. The investigation also has an opportunity cost: Every hour spent learning here is an hour unavailable for another product question.

Stop advancing the idea when the project exists only in the founder's explanation. Talk to people doing the work before claiming there is demand.

2. The Learning Gate: Choose what a prototype should teach

Project → Prototype

The operations lead may be struggling with missing data, conflicting definitions, or understanding the result. A chat interface may solve none of them. Choose what to learn before building the interface.

Hilary Gridley's account of prototyping at Whoop describes a shift toward asking what teams could learn by putting a prototype in front of members. For this report, a small test could show whether the operations lead recognizes that missing data prevents a fair comparison. Do not use its result to make staffing decisions. It would not yet show whether the team can produce a reliable report at an affordable cost.

The Learning Gate justifies the smallest test that can answer the question. Agree on what to learn, how much time and money to spend, what data participants can use, and what they can do with the results. Name the result that would change the next decision. If the prototype requires recurring manual preparation, record that work as a future operating and maintenance cost.

If the next step is a service or paid pilot you can deliver as described, ask for payment. Snyder favors paid early work as a demand test. Describe what the customer receives and what remains experimental. In Cagan's customer discovery program, partners provide access, test early versions, and agree to buy if the product works. He prefers not to take advance payment for that arrangement. You still need to see whether they buy.

For an internal product, look for a sponsor committing time or budget to the next test. These commitments can increase as the evidence improves. The team should record what this test displaces before spending the budget.

Stop expanding the prototype when the team cannot name what it will learn. Stop the test itself if its data use or potential harm is unacceptable. Narrow the question or change the method before spending more.

3. The Proof Gate: Show what works and its limits

Prototype → Demo

A demo makes a bounded promise visible. You can prepare the data and choose what to show, provided you explain those limits.

Marily Nika distinguishes a prototype used for learning from an MVP that must cope with real use. A polished interface can hide how much remains untested. Read her explanation.

For the reporting assistant, show the source records alongside the answer. If a person manually repaired those records or selected the only question that works, say so. That preparation limits what the demo proves. Record who did the preparation, how often it would recur, and what the demo leaves out.

The Proof Gate justifies the work required to make the claim inspectable. It does not justify live use. If the demo depends on hidden preparation the team cannot reliably provide in real use, that preparation is an operating cost to solve or defer.

Stop moving toward release if the demo depends on hidden preparation the team cannot reliably provide in real use. Keep experimenting, or promise less.

4. The Dependability Gate: Decide whether live use is justified

Demo → MVP

An MVP earns limited reliance only when the team can state what the product supports and how it will handle failure.

If a site is missing from the data, the assistant should not promise a comparison that includes it. Narrow the comparison to what the data supports and explain what is missing, or delay release until the team fixes the problem.

Before a limited release, agree on what people can use the product for and what evidence would justify that use. Test questions people will ask, incomplete records, and cases where the system should refuse to answer. Judge failures by what they could cause. A harmless formatting error and an unsupported comparison need different responses.

Check whether the assistant can detect missing coverage, explain which comparisons it cannot make, and send the question to someone who can help. Define who can access the data and what users can do with the answer. Name who will monitor the workflow, fix failures, maintain changing definitions, and restore a working alternative. Those are part of the product's operating cost from the first limited release.

Name who can approve release and who will fix failures or take the product out of use. The NIST AI Risk Management Framework calls for decisions about whether to deploy and clear responsibility for taking systems out of use when they do not behave as intended.

Ethical review must also ask whether the intended use itself could harm people, even when the system works as designed. In a 2020 essay, Cagan argued for treating ethics as a fifth risk because it can get lost within business viability. My emphasis in data-product teams is to give that concern an owner and authority to delay a release.

In this hypothetical report, shifting staff using incomplete data could leave one site short-handed. Even an accurate comparison would not, by itself, justify changing the schedule. Ask who is absent from the data, who bears the consequence, and how they can challenge a decision. Name who can stop the use. Raise those questions when choosing the problem and revisit them when the purpose or population changes.

The Dependability Gate also carries an opportunity cost. A limited release consumes monitoring, support, and maintenance capacity. If the team cannot fund that work without displacing a commitment the team has ranked higher, narrow the release or defer it.

Stop the release if a failure could make the product unfit for its promised use and the team has no effective limit or tested response. Fix the failure, allow fewer uses, or keep testing.

Stop if the team cannot acceptably reduce or prevent an identified harm, even if someone will pay. Give the reviewer time and authority to investigate and act. Clinical, privacy, and regulatory assessment remain separate requirements where applicable.

5. The Adoption Gate: Follow the work through to completion

MVP → Product

A reliable answer can still leave the user with an unfinished job.

Suppose the operations lead must copy the assistant's output into another report, resolve conflicting definitions, and ask an analyst which comparison to trust. The analyst now has an assistant to check on. Count that extra work when assessing whether the product helps.

Jason Cohen's Simple, Lovable, Complete calls for a narrow product that completes its job. Aim for that in the first release, then watch whether people can finish the job.

Observe people using the workflow in the setting it was designed for. Check whether they can finish the job and who handles exceptions. Measure whether people return when the need recurs. A monthly decision does not call for daily use.

The Adoption Gate justifies keeping and expanding the workflow. Name the support, data upkeep, definition changes, and exception handling it requires. Decide which requests belong in the next version and which remain out of scope. Compare that ongoing work with the value of keeping the product in service.

Stop adding users if they need unexpected fixes to finish the promised job, or the team cannot keep up with support. Fix the handoff before adding users.

6. The Commercial Gate: Prove repeatability

Product → Business

A product can help people and still fail to justify expansion. If a customer has paid, examine what followed the sale: Did the customer complete the job, continue using the product, and renew or buy again when the need returned? What work and cost did each new customer create?

The Commercial Gate is where repeatability becomes explicit. Costs should be visible from the first gate. Payment for a service establishes demand for that service, not necessarily for software. One successful customer rollout can justify another test. It does not show that the team can repeat that success with other customers. A product that needs extensive custom work for every sale may support a service business. That has different delivery economics from selling repeatable software.

Kevin Goldsmith addresses ongoing ownership in a build-versus-buy analysis: The initial build can be cheap while ongoing ownership and attention become the larger commitment.

Include setup, checking, support, data upkeep, maintenance, and the cost of the opportunities the team turns down. Compare that work with what customers pay and with the next decision the business needs to make. Change the offer, the customer, or the delivery model before taking on more customers.

For an internal product, the equivalent decision is whether the organization should keep funding and extending it. Compare the work it helps people complete with the full cost of running it and the alternatives that budget could fund. Continued funding needs an accountable sponsor and evidence of use and value; an internal allocation alone does not establish either.

For an internal product, stop or narrow the work when no accountable sponsor can justify its full operating and maintenance cost, or when its value does not outrank the work the funding displaces.

Stop investing in expansion when buyer demand remains unclear or serving each customer costs more than they pay, with no credible way to close the gap.

Review the risks at every gate

Marty Cagan's four product risks belong in the review throughout:

• Value: Will customers buy or users choose to use it?
• Usability: Can people figure out how to use it?
• Feasibility: Can the team build it with the skills, technology, and time available?
• Business viability: Can the business support it within its financial, legal, and operating constraints?

These risks are questions for every commitment, not a checklist reserved for the final gate. At each phase, ask what you will focus on, what you will defer, what it will cost to operate and maintain, and what other work the commitment displaces. Keep ethical risk explicit too, including harm to people who never chose to use the product.

Write the decision before the next commitment

For the next commitment, complete a short decision note:

• Focus: What will this phase make possible, and which user or business decision does it serve?
• Defer: What is deliberately out of scope until the evidence changes?
• Project and commitment: What has the person described and tried? What has the team committed to, and which buying or funding decision remains?
• Evidence: What must the next test or release check establish? What did it show? What remains untested?
• Operating cost: Who runs the workflow, handles questions, and restores a fallback?
• Maintenance cost: What definitions, data, integrations, or policies will change, and who will update them?
• Opportunity cost: What other work, investment, or decision is this commitment displacing?
• Stop condition: What finding would stop the next investment, experiment, release, or expansion? What harm would require use to stop, including harm to people who never chose the product?
• Owner and fallback: Who makes the call and restores a workable alternative?
• Next decision: Proceed within the agreed limits, fix a specific problem, or stop.

Bring the note to whoever decides whether to fund the experiment, release the product, maintain it, or expand its use.