The Five Product Risks

When a Working Pilot Hides the Risk

Consider a founder testing a no-show recovery service for independent physical therapists. When a patient cancels, the clinic sends the founder a message. The founder checks a waitlist, contacts patients using clinic-approved language, and reports whether the appointment was filled.

The first recovery feels like strong evidence. The clinic regains an appointment it expected to lose. A second clinic agrees to a paid pilot. The workflow appears simple enough to automate.

By the third clinic, the founder is carrying six versions of the process. One clinic allows outreach only to patients who have explicitly joined a waitlist. Another wants approval before every message. A third distinguishes cancellations by therapist, treatment type, and insurance status. Replies arrive while the founder is coding, selling, or asleep. The service works because its founder remembers the rules and catches the exceptions.

The calendar integration is no longer the most important uncertainty. The product may create value and still fail as a solo-founder business.

Product work is often described through four risks: whether customers will choose the product, whether they can use it, whether it can be built responsibly, and whether the business can support it. A solo founder needs a fifth question: can the same person keep operating and improving what the product requires?

That is sustainability risk. It is not a euphemism for working fewer hours. It is the possibility that the product creates an operating model its only operator cannot keep alive. Customers eventually experience that risk as delayed support, brittle workflows, messy data, abandoned improvements, and slow recovery when something breaks.

Five Different Ways to Be Wrong

The risks overlap, but they do not ask the same question.

Value risk: Will a specific customer act to obtain the outcome? Evidence lives in recent behavior: the cost of the problem, the workaround already in use, the urgency to change, and the willingness to return or pay. Praise is weak evidence because it asks nothing of the customer.

For the clinic product, the value question is not whether therapists dislike no-shows. It is whether enough recoverable cancellations occur, whether empty appointments matter economically, and whether clinics will change their behavior to fill them.

Usability risk: Can the customer reach value without the founder interpreting the product for them? Watch the attempt. Notice where a user hesitates, supplies the wrong input, misses the next action, or needs coaching. A customer can want the outcome and still fail to reach it.

Here the workflow includes clinic staff and patients, not just the buyer. Staff must flag a cancellation quickly. An eligible patient must understand the offer and respond. A polished clinic dashboard would not repair a slow or confusing handoff.

Feasibility risk: Can the product deliver the outcome with acceptable reliability, data quality, security, and recovery? A technical spike can answer a narrow question about an integration or algorithm. Real use reveals the less tidy boundary: bad inputs, duplicate messages, unavailable calendars, permissions, failures, and the cost of change.

The clinic founder may prove that two calendars can synchronize and still have no safe rule for conflicting updates. The thin product can be narrow; it cannot pretend that privacy, consent, and message delivery are solved when they are not.

Viability risk: Can the business survive the way value is sold and delivered? The user, buyer, and payer may be different people. Price must carry acquisition, infrastructure, support, and service work. A paid pilot establishes more than a compliment, but it does not establish a viable business if each dollar of revenue arrives with an unpriced hour of founder labor.

Sustainability risk: Can one founder operate the current product while preserving enough attention to learn, sell, and improve it? Track weekly attention cost, custom rules, support load, exception frequency, monitoring, and recovery. A workflow that is tolerable for two design partners may become the company’s limiting architecture at ten customers.

Keeping the questions distinct improves diagnosis. Users who fail during setup may make strong value look weak. A product that sells only through custom onboarding may have both viability and sustainability problems. Founder-led data cleanup can hide a feasibility problem. One symptom can implicate several risks, but naming the possibilities prevents the most comfortable explanation from winning by default.

Risk Moves as Evidence Arrives

The five risks are not stages to complete in order. Their relative weight changes with the product.

Before building the clinic service, the founder knows too little about value. The cheapest useful work is to examine recent cancellations with clinic owners: how often slots remain empty, what staff do now, which patients could realistically take short-notice appointments, and what one recovered appointment is worth. Proving calendar synchronization at this point would answer a familiar engineering question while leaving the product question untouched.

Suppose several owners show the founder recent empty slots, and two agree to a paid manual trial. Value has not been proven for a market, but it has become strong enough to expose the next uncertainties. The founder now learns whether staff can flag openings promptly, whether patients accept the outreach, and which rules protect trust.

Manual delivery is useful because it makes the hidden workflow visible. The founder logs each step, delay, exception, patient question, and clinic-specific rule. If the same bounded sequence works repeatedly, part of it may deserve automation. If every recovery requires personal judgment, the manual service has discovered a boundary rather than a backlog.

Payment moves viability into view. A monthly fee may look attractive until the founder measures the work behind it. Perhaps the clinics will pay enough for a standardized recovery workflow. Perhaps payment tied to recovered appointments creates disputes and uneven revenue. Perhaps the buyer values the outcome but expects a staffed service. Each result changes the possible business, not merely the pricing page.

By the end of the trial, the most consequential risk may be sustainability. If three clinics consume every afternoon, adding a fourth is not growth. The founder can narrow eligibility rules, require a common intake format, change the service window, raise the price, automate one repeated bottleneck, or stop. More customers would only make the diagnosis more expensive.

Write Assumptions That Can Lose

A Five-Risk Assumption Map should fit on one page. It is not an inventory of everything that might go wrong. Write one decision-changing claim under each risk, the cheapest credible evidence you can obtain, and what you will do if the claim is false.

For the no-show recovery product, the map might read:

• Value: Independent clinics lose enough suitable appointments to act on recovery now. Inspect recent cancellations and existing recovery attempts. If the loss is rare or accepted, change the painful moment or stop.
• Usability: Clinic staff can flag an opening and patients can respond without founder coaching. Observe the handoff with minimal help. If it fails, simplify the workflow or narrow who participates.
• Feasibility: A bounded service can coordinate outreach without unsafe calendar automation or ambiguous patient state. Run a manual flow with explicit consent, ownership, and recovery rules. If it cannot be bounded responsibly, change the design or do not offer it.
• Viability: A clinic will pay enough for the repeated outcome to cover delivery and support. Ask for a concrete paid trial and measure its full cost. If the economics fail, change the buyer, package, price, or service model.
• Sustainability: Repeated clinics share enough rules that one founder can serve them and still run discovery, engineering, and distribution. Log every step and exception. If custom work dominates, standardize, narrow, price it honestly, or stop.

Statements such as “clinics need better scheduling” do not belong on the map. They are too elastic to fail. A good assumption names the customer, behavior, constraint, or economic condition clearly enough that contrary evidence forces a decision.

Do not manufacture symmetry. One risk may need a patient observation while another needs only a vendor check. Two risks may share an experiment. A manual trial can test value, usability, viability, and sustainability at once, provided the founder records evidence separately instead of turning a generally promising experience into five claims of success.

Choose the Assumption With Decision Power

Three judgments determine what to test next.

First, consider consequence. If the assumption is false, does the product direction change? Testing button copy before knowing whether clinics will pay for recovered appointments spends evidence on trivia.

Then consider ignorance. What do you actually know from observed behavior, as opposed to inference, enthusiasm, or founder-assisted use? A belief does not become evidence because it has survived several planning sessions.

Finally, consider testability. What credible proxy can you test now without building the imagined product? The largest theoretical risk is not always the next useful test. Enterprise procurement may decide the eventual business, but an early founder may be able to learn only whether the economic buyer recognizes the pain, controls budget, and will fund a trial. That can still change the next move.

Choose the assumption where consequence and ignorance are high and a credible test is available. The aim is not to remove uncertainty. It is to spend the least founder effort needed to make a better decision.

Founder Labor Can Teach or Conceal

Early manual work lets the founder see inputs, exceptions, language, quality standards, and support burden before automation freezes the wrong workflow. It becomes dangerous when the labor stops producing new understanding and remains necessary for the product to function.

Custom setup for every account may mean the segment or promise is too broad. Repeated support questions that never change the product are a recurring tax. Data cleanup before every report means founder effort is hiding a feasibility and trust problem. Paid use that depends on unpriced service couples viability to sustainability. A founder who has no time to speak to new customers is no longer using manual work to learn; the work has interrupted the learning system.

This distinction is especially important when early results look good. Five users may activate only because the founder spends an hour with each one. Revenue may rise while every account adds new rules. The product appears to be working because the founder has quietly become part of its runtime.

Decide Before Adding Scope

The next experiment should target the highest-risk assumption that can change your decision. Write the possible decisions before running it:

• Proceed when the current assumption has enough support and a different risk now deserves attention.
• Narrow when value exists but risk concentrates in one segment, workflow, buyer, data path, or operational step.
• Defer when a question is interesting but no current decision depends on it.
• Harden when repeated use makes reliability, security, data quality, recovery, or operating burden the constraint.
• Stop when consequential assumptions repeatedly fail and no sharper wedge appears.

A good experiment can end in any of these. Discovering that every clinic needs a different service is not failed learning. It is a successful sustainability test—possibly for a valuable service business, but not for the solo-operated product the founder meant to build.

Now write the map for your own product. Give each risk one assumption that can lose, one source of honest evidence, and one action if it proves false. Circle the assumption with the greatest power to change your next decision. Design the smallest responsible test for that assumption, then set a limit on the code, custom work, money, or calendar time you will spend.

The five risks do not tell you how to make the product safe from failure. They tell you where another week of founder effort can buy a real decision—and where more building would only make uncertainty harder to abandon.