In 2013, MD Anderson Cancer Center and IBM announced the Oncology Expert Advisor, a clinical decision support tool built on IBM Watson to recommend cancer treatments. A 2016 University of Texas System audit found that MD Anderson had spent at least $62.1 million on it, and that the tool had not been used clinically or piloted outside MD Anderson.

The audit did not judge whether the technology worked. It examined management and procurement. IBM’s position was that the tool’s recommendations agreed with experts 90% of the time and that it could have been deployed. Both can be true. What the audit did record is that the project’s focus changed several times, and that the tool was trained on an electronic health record (EHR) that MD Anderson replaced partway through.

This article is for technical founders of seed-stage healthtech companies who have an insight, often a capability, and are about to write the problem statement that everything else rests on. It is part of A|P’s series on the foundation of product-market fit, which sets out the four tests in full; this article shows them at work.

Product-market fit (PMF) is the point at which a product satisfies a market with enough real buyers to pull it out of the company, and the problem statement is where the search for it starts. The previous article in the series, Societal need isn’t a market, covers how to tell whether a market is worth entering at all.

What does “solution looking for a problem” mean in healthtech?

A solution looking for a problem is a product built around a capability before anyone has confirmed which buyer needs it and why. In healthtech it usually starts with a technology that clearly works, such as a model that reads clinical notes, followed by a search for a place to use it. The search is the warning sign.

Three symptoms show up in the plan long before they show up in the revenue:

1. The problem statement starts with your verb. “We help hospitals use AI to…” describes what you do. A buyer’s problem describes what goes wrong for them, and doesn’t need your product to make sense.
2. The scope widens after every meeting. Each prospect mentions a different pain, and the roadmap grows to cover it. A product that serves five problems for five buyers serves none of them well enough to be bought.
3. Success is measured in your product’s terms. Accuracy, minutes saved and notes generated are product metrics. The buyer is measured on revenue, denials, throughput or staff turnover. If your pilot report can’t be restated in the buyer’s metric, the buyer has no reason to renew.

The MD Anderson project shows at least two of them. Its focus moved more than once. And the measure offered in its defence, agreement with experts, describes the tool rather than what the tool would change for the hospital’s patients or budget. Whatever its accuracy, it went unused.

Why do technology-first insights fail?

Technology-first insights fail because a capability tells you what you can build, not who needs it. A good initial insight is earned, unique and grounded. A capability is usually none of the three: it isn’t earned from watching buyers, everyone with the same model has it, and it changes no part of the business by itself.

That doesn’t make a capability useless. It makes it the start of a search, not the end of one. Turning it into a problem takes three moves:

1. Take the capability to buyers as a question, not a pitch. Ask what they are trying to achieve this year and what stops them. Don’t demo.
2. Find the outcome the capability could serve. Listen for a gap that the capability could close, in the buyer’s words.
3. Write the problem statement without the capability in it. If the statement still makes sense with your product removed, it describes a problem. If it collapses, it describes your product.

The third move is the hardest, because it feels like throwing away the advantage. It isn’t. The capability returns later, in the value proposition and the competitive advantage. It just doesn’t belong in the problem.

How to choose the right problem for your healthcare startup: a worked rewrite

The most reliable way to choose the right problem for your healthcare startup is to draft the problem statement, run it through the four tests, and rewrite it each time it fails. The example below follows one statement through four failed drafts to a fifth that holds. It illustrates the method; it is not a recommendation to enter this market.

The setting: a founder has a model that reads clinical notes and payer policies. The obvious use is prior authorization, the approval a health plan requires before it will pay for certain care. The burden is well documented. In an AMA survey of 1,000 physicians in late 2024, practices completed 39 prior authorization requests per physician per week, taking 13 hours of physician and staff time. The target buyer is an independent, physician-owned cardiology group.

Draft 1: “We help cardiology practices automate prior authorization with AI.”
This fails the active-pain test. It opens with the builder’s verb and names the product. It says nothing about what goes wrong for the practice.

Draft 2: “Cardiology practices spend too much time on prior authorization.”
This passes the active-pain test: it describes the practice’s friction. It fails the severity test. Time spent is an annoyance the practice already pays for. Solving it perfectly might save some staff hours, but it doesn’t say what the practice is trying to achieve, so it can’t show that solving it matters.

Draft 3: “The group wants its imaging schedule full, because imaging carries much of the practice’s margin. Late authorizations push or cancel studies, and staff are burning out on payer portals.”
This is closer. It has an outcome, a motivation and gaps. It fails the cause-and-effect test. The first gap blocks the outcome; the second doesn’t. Staff burnout is real, but it is a different problem with a different owner. A statement that mixes two problems produces a product that half-solves both.

Draft 4: “The group wants its imaging schedule full, because imaging carries much of the practice’s margin. Studies are pushed or cancelled because the practice lacks AI that checks payer rules before submission.”
The chain now holds. It fails the solution-independence test. The product has crept back in as the gap: “lacks AI” is not something a buyer experiences. You couldn’t validate this statement without first building the AI.

Draft 5: “The group wants its imaging schedule full, because imaging carries much of the practice’s margin. Two things stop it: authorizations that come back after the scheduled date, which push or cancel studies, and denials discovered only after the scan, which turn completed work into write-offs.”
This passes all four. It starts from the practice’s friction, it ties the gaps to the practice’s money, the sentences follow from each other, and it can be tested in a conversation with the practice manager this week. Notice that the founder’s capability appears nowhere in it.

Draft 5 still has to survive one more check: whether the gap is about to shrink on its own. For instance, for players operating in the US market, under the CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F), Medicare Advantage, Medicaid and CHIP plans must decide standard requests within seven days and urgent ones within 72 hours from 2026. If late decisions are the main gap, part of it is being regulated away. The denial gap is less affected.

What evidence shows each test has passed?

Each test passes only when a buyer gives you evidence, not when the statement reads well. The evidence differs by test: a workaround someone already pays for, a number from the buyer’s own reports, the buyer restating the problem unprompted, and a commitment made before any product exists. Compliments and requests for more information count for none of them.

Active pain: someone already pays for a workaround. Ask who handles the problem today and what it costs. A real problem has an owner and a workaround: a dedicated staff member, a spreadsheet, an outsourced vendor. In the AMA survey, 40% of physicians said they have staff who work exclusively on prior authorization. That is a workaround with a salary. If nobody owns the problem and nothing is spent on it, the pain isn’t active.

Severity: the buyer puts a number on it from their own reports. Ask how many studies were pushed or written off last quarter. If the practice manager pulls the figure from a report, the problem is watched, and watched problems get budgets. If they have to guess, it isn’t watched closely enough to be bought.

Cause and effect: the buyer restates the chain without being prompted. Read your statement back and stop talking. A buyer who recognises the problem will repeat it in their own words, often with a correction: “yes, but the real issue is the second payer.” Take the correction. If they agree politely and change the subject, the chain doesn’t match their experience.

Solution independence: the buyer commits something before the product exists. Ask for something that costs them: an hour with the billing lead, a sample of last quarter’s denials, or paid discovery. Data access is a strong signal, because it carries a real obligation. Under HIPAA, the US law that protects patients’ health information, a vendor that needs a practice’s patient data must sign a business associate agreement before getting access. A practice that signs one for a company with no product has told you the problem matters.

The order matters less than the standard. A statement with evidence for three tests and none for the fourth is not ready to build against. Go back to the test without evidence.

When should you drop the problem instead of rewriting it?

Drop a problem statement when rewriting it stops producing evidence. Rewriting is the right response to a draft that fails a test; it becomes the wrong response when each rewrite changes the buyer, widens the segment or swaps the gap to keep your capability in play. At that point you are fitting the problem to the product.

Four signals say it is time to stop:

1. The statement passes only when you change the buyer. If the practice manager doesn’t feel it, so you try the CFO, then the payer, then the patient, the capability is choosing the problem. This is the MD Anderson pattern at startup scale.
2. The evidence doesn’t arrive. Set a number before you start, such as ten conversations with people who hold the budget. If none of them produce evidence for severity and solution independence, the problem isn’t acute for them.
3. A known change removes the gap. A rule, a reimbursement change or an EHR vendor’s roadmap can close the gap before you reach scale. CMS-0057-F also requires the affected plans to offer electronic prior authorization interfaces built on FHIR, the standard for exchanging health data between systems, from 2027. A gap that depends on today’s portals has an expiry date.
4. Your success metric keeps reverting to your product’s. If every version of the pilot plan measures accuracy or time saved, and none measures the buyer’s outcome, the problem hasn’t been found yet.

Dropping a statement isn’t dropping the capability. It sends you back to the first move: take the capability to a different set of buyers as a question.

The limits of the argument

Technology-first sometimes works. Ambient scribes are the clearest example from the US. Generative AI arrived as a capability, many companies rushed to apply it to clinical notes, and the category still found buyers fast. Kaiser Permanente rolled out Abridge’s ambient documentation tool across 40 hospitals and more than 600 medical offices in 2024.

It worked because the problem was already acute, measured and owned. Documentation burden had been studied for years, health systems tracked it, and clinicians were asking for relief. The capability made an existing problem newly solvable. That is different from a capability searching for a problem it can solve. The test in both cases is the same: whether draft 5 exists for a named buyer, with evidence behind it.

The decision in front of you is whether your problem statement would still be true if your product didn’t exist, and whether a buyer has already given you evidence that it is.

Next in the series: The doctor loves it, the CFO won’t sign: picking your first customer segment (publishing soon).

Frequently asked questions

What does “solution looking for a problem” mean?

A solution looking for a problem is a product built around a capability before anyone has confirmed which buyer needs it and why. In healthtech it shows up as a problem statement that starts with the company’s own verb, a scope that widens after every meeting, and pilots measured in the product’s terms rather than the buyer’s.

How do you identify a problem worth solving for a startup?

To identify a problem worth solving for a startup, start from the outcome your buyer wants, ask why they want it, and list what stops them today. Write that as a problem statement without your product in it. Then collect evidence from buyers: an existing workaround, a number from their own reports, and a commitment before the product exists.

Can you choose the right problem for your healthcare startup after building the product?

Yes, but it means writing the problem statement as if the product didn’t exist, and accepting that the answer may point somewhere else. Take the product to buyers as a question rather than a demo, rewrite the problem from their outcome, and check whether your product actually closes the gap they describe. If it doesn’t, the product is a capability still looking for its problem.