Mapping Venture Assumptions Across Key Risk Dimensions

Hello. Last lesson gave you a solution-neutral opportunity thesis: a proposed user, a situation, an unmet need, and a desired outcome. That thesis is useful precisely because it can be wrong. The next step is to make its hidden assumptions visible before a promising customer conversation—or a prototype—makes them feel like established facts.

In this lesson, you’ll map assumptions across desirability, viability, feasibility, trust, and regulatory risk. You do not need to settle on an app to do this. The map should help you see which questions concern the heavy-flow management problem itself and which arise only if you choose a particular product or business model.

Start with three different ways a venture can fail

A person can have a serious problem without wanting your proposed help. A useful offering can be difficult to deliver reliably. And a product people use can still lack a sustainable business model. Desirability, feasibility, and viability separate these possibilities.

Watch the opening of Desirability, Feasibility, Viability – A Guide for Questions While Innovating from Mastering UX. Use the three lenses to classify uncertainties, rather than treating them as a sequence in which one must be fully resolved before the next matters.

Apply those distinctions to the illustrative thesis from the previous lesson: people who describe difficult-to-manage flow and work shifts with restricted breaks want to get through high-flow workdays with fewer interruptions and less worry about bleeding through. It is an example to map, not a finding about your prospective customers.

A desirability assumption is that the disruption remains important even after people use existing workarounds, such as bringing backup supplies. Another, separate assumption is that they would want additional support rather than regard those workarounds as sufficient. Evidence that the situation is difficult would not, by itself, prove interest in a new offering.

A feasibility assumption concerns what you could deliver. If the eventual concept involved a private record of flow experiences, could it be made easy to use during an already demanding day? Could it function dependably while handling sensitive information appropriately? If the better response turns out to be a physical product or a service, the feasibility questions will change. Do not let the convenience of building software define the problem.

A viability assumption concerns whether a way of delivering that value can be sustained. For example, you might hypothesize that users would pay directly for support, or that another customer would pay to provide it. Those are different business models with different customers and costs. Neither follows from the fact that people describe a painful experience.

In your strategy work, you may be used to discussing market attractiveness and execution together. An assumption map deliberately pulls them apart. “This problem disrupts work,” “people will adopt this particular help,” and “we can acquire users at a sustainable cost” are three claims requiring different evidence.

Add trust as a distinct lens

Health-related products can fail even when the experience is desirable, technically workable, and affordable. Someone may need help yet reasonably avoid a tool that asks them to disclose menstrual information, makes them feel judged, or appears to replace a clinician’s judgment. That is why trust deserves its own place on this map, rather than being buried inside “good user experience.”

The diagram below is a prompt for spotting possible adoption barriers, not evidence that any particular barrier applies to your customers.

Notice how a seemingly small design decision can raise several questions. Asking someone to record every product change might make a proposed summary more detailed. It might also impose too much effort (feasibility of sustained use), feel disproportionate to the benefit (desirability), or create concern about where intimate data goes (trust). The categories distinguish the questions; they do not imply that only one category applies.

Trust also includes how an offering relates to existing care. The qualitative study you encountered last lesson describes participants’ differing experiences of communication with healthcare professionals. Read its short section on those interactions now, with a narrower purpose: to notice what feeling informed and taken seriously meant in those accounts. Do not infer from a positive or negative care experience that participants would want a digital product.

For the illustrative opportunity, a trust assumption might be: People would regard an optional, private account of their experiences as supportive, rather than as another demand to disclose sensitive information. A different trust assumption would concern language: People would understand that the offering helps them describe an experience, not judge whether their bleeding is medically normal. Neither is established by the study. Its participants’ accounts help you ask sharper questions, but they do not represent everyone who reports heavy flow.

Treat regulatory risk as uncertainty about the concept, not a label for the problem

Your opportunity thesis does not require a regulated medical device. A particular implementation and its claims, however, may raise regulatory questions. Compare two possible statements about an otherwise similar tool:

“Keep a private record of experiences you may choose to discuss with a healthcare professional.”

“Detect abnormal bleeding and tell you when treatment is needed.”

The second asserts a medical judgment that the first does not. What a product does and what you claim it does both matter. That does not establish the legal status of either hypothetical product; it identifies a consequential assumption to investigate before committing to features or marketing claims.

In Regulatory Strategy: Top 5 Mistakes Healthtech Founders Make, Dreamit cautions against confidently declaring that no FDA review is needed without being able to explain the reasoning. The segment also connects intended use and promotional claims to commercialization. Watch it for the founder’s decision-making principle, not as a substitute for regulatory advice.

For an early-stage US concept, record at least two separate kinds of risk:

• Product and claims risk: Would proposed functions or statements about detecting, predicting, diagnosing, or recommending care require a different level of substantiation or regulatory review than an experience-recording or educational tool?
• Sensitive-data risk: What privacy and security obligations would apply to the actual organization, data flows, partners, and users you choose?

Do not assume a consumer product is automatically covered by HIPAA—or that being outside HIPAA means there are no privacy obligations. The answer depends on the arrangement and applicable law. At this stage, the assumption map should flag decisions that need qualified review, not announce compliance or a regulatory classification. A later module will examine these boundaries in detail.

Regulatory and trust risks can interact without being interchangeable. A claim might be legally permissible but still feel misleading to users. Conversely, reassuring language does not resolve an underlying legal obligation.

Put the assumptions where you can see them

An assumption is a claim your venture currently relies on but has not adequately established. Write it so that contrary evidence is imaginable. “Privacy matters” is a topic; “People in the proposed segment will be willing to enter menstrual details if they can control what is saved and shared” is an assumption. It may prove false, or only true for some people.

The table models a first pass for the restricted-break shift example. Every entry is illustrative and unverified; the provisional private-record concept appears only where a product-specific question requires one.

The last row is intentionally conditional. “We can legally launch an app” would be too broad to evaluate: which app, with which functions, claims, data practices, and partners? Likewise, the viability row becomes more useful when you specify who you think pays. Those details can remain undecided for now, but the uncertainty should remain visible.

Keep two distinctions in mind as you make your own map.

First, do not promote evidence into a conclusion it cannot support. A published account of work disruption supports the plausibility of a problem. It does not establish its frequency in your intended segment, willingness to adopt your concept, or willingness to pay. A participant saying “that sounds useful” may suggest interest, but does not establish sustained use.

Second, do not hide an assumption inside another. “Users will trust and pay for an accurate prediction” contains at least three claims: that the prediction can be produced accurately, that users would trust it, and that someone would pay enough for it. Separating them reveals how the venture could fail even if one claim holds.

A brief mapping pass is enough at this point: take your current opportunity thesis and any concepts you are considering, then record one or two claims under each lens. Mark each as grounded in something you have observed, suggested by secondary evidence, or presently a founder inference. You are making a legible inventory of uncertainty, not yet choosing a winning concept or ranking tests.

Takeaways

The five lenses ask different questions. Desirability concerns an unresolved need and willingness to seek help; viability, a sustainable way to provide it; feasibility, the ability to deliver it; trust, whether people can confidently engage with it; and regulatory risk, whether the chosen functions, claims, and data practices create obligations the venture can meet. A claim can cross lenses, but splitting it into specific assumptions makes the uncertainty easier to investigate.

Your solution-neutral thesis remains the anchor. The map exposes what must be true for a venture built around that opportunity—without treating a tech solution, a clinical claim, or a business model as settled. Next, you’ll rank these assumptions by how uncertain and consequential they are, so your discovery effort focuses on the risks that matter most.