From Pain Points
to Activity Gaps.

A lot of product ideas begin with a simple observation: this does not exist on the market; someone should build it.

Sometimes this works. A founder sees a missing product, builds it, and the market responds. But very often, absence is not evidence.

Something may not exist because the pain is weak, the problem happens too rarely, the workflow is too hard to change, or the buyer, user, operator, and beneficiary are not the same person.

A missing product is not the same as a real opportunity.

So product thinking evolved. Instead of asking only what does not exist? we started asking: what pain does the user have, what job are they trying to get done, what progress are they trying to make?

This is already much better. It moves us from product ideas to user needs. But pain is still often a symptom.

The deeper question is: what activity is the user part of — and where does that activity fail to close?

That is the shift from pain points to activity gaps.

I think product discovery can be described in three levels — not as a rigid hierarchy, but as increasing depth.

Level 0: absence-driven thinking. “This does not exist. Let’s build it.” The object of analysis is the market gap. Useful as a first signal, but still too weak on its own.

Absence does not tell us how often the problem happens, how painful it is, who pays, how urgent it is, whether the user already has a workaround, or whether the workflow can actually change.

Level 1: pain-driven and JTBD thinking. Here we ask what the user is trying to get done, what pain blocks them, and what progress they want to make. This is a major improvement because it shifts attention from product to activity from the user’s point of view.

But even this can remain too shallow if we stop at pain. “This takes too long.” “I need a better dashboard.” “I want automation.” These are important signals, but they do not yet show how the result is structurally produced.

Level 2: activity gap thinking. Now we stop looking only at the person and start looking at the activity the person is part of. The user becomes an actor inside a system of transformation. The product opportunity appears where that transformation does not close.

JTBD asks what job the user is trying to get done. Product Breakdown asks how that job is actually produced inside a real activity system — and where production breaks.

Product Breakdown has two parts. The first is ontological: it asks what activity is made of.

Before we can find product opportunities, we need to understand the structure of the activity itself.

There is an actor. The actor starts with initial material. The actor performs operations. The actor uses means, tools, knowledge, interfaces, and internal abilities. The actor tries to transform the initial material into a desired product or result. The result often becomes material for another actor.

And the whole process happens through the actor’s screen of awareness: how they understand the situation, what they see, what they do not see, what they fear, and what they consider success.

This matters because product opportunities are often hidden in places where ordinary discovery does not look — not only in pain, but in the material, the operation, the handoff, the criteria of quality, the missing knowledge, the wrong interface, or the gap between one actor’s output and another actor’s input.

The ontology gives us the map. But the map is not enough. We also need a method.

The second part of Product Breakdown is methodological. It asks: how do we interrogate an activity to find product opportunities?

The goal is not to produce a beautiful canvas. The goal is to find a real activity gap — a place where something should be transformed into something else, but the transformation is incomplete, expensive, slow, risky, manual, unclear, or unreliable.

Below is the practical question set I find most useful for product discovery, product strategy, and early-stage idea breakdown.

This is the practical core of the method: start with situation, map the act, locate the gap, define the intervention, and measure whether the activity closes better.

Take a simple example: a patient receives medical imaging results.

A shallow product idea might be: patients need online access to their medical files. That is not wrong, but it may still be too shallow.

The actor is the patient. The initial material includes a radiology report, medical images, technical terminology, anxiety, lack of context, and lack of next step.

The desired result is not “open the PDF.” The desired result is: understand what this result means and what I should do next.

The quality criteria include clarity, trust, medical safety, correct distinction between report, explanation, and advice, and the ability to take the next step or share the result with the right doctor.

The gap is not only access. The gap is interpretation, confidence, and next action.

So the product opportunity changes. Instead of building only a file portal, the product could introduce plain-language explanation, a smart summary, a doctor question list, a share package, a second-opinion flow, a next-step navigator, and follow-up tracking.

The real product is not medical file storage. The real product is turning medical results into clear next action.

Now take job search. The old model says: resume meets job description, candidate meets vacancy. But this model starts too late.

The company opens a role when the work is already urgent. The person starts looking when they are already dissatisfied, under pressure, or ready to leave. Both sides use weak artifacts.

A resume is a thin representation of capability. A job description is a thin representation of future work.

Now look at the deeper activity. From the person’s side, the activity is not simply find a job. The person is developing capabilities over time: experience, interests, values, constraints, portfolio, learning path, and proof of work.

From the company’s side, the activity is not simply fill a vacancy. The company is developing future work: strategy, future projects, emerging roles, capability gaps, technology shifts, team structure, and execution risks.

The gap is that developing people and emerging roles evolve separately. They usually meet only when hiring becomes urgent.

That suggests a different product idea: not another job board and not another resume database, but a system that matches future roles with developing capabilities over time.

A capability trajectory system. A place where companies can signal future roles, and people can build preparation paths toward them before the vacancy exists.

This framework becomes especially useful in the AI era because AI is powerful when it becomes a new means of transformation.

It can help turn unstructured text into structured data, documents into summaries, conversations into records, raw ideas into product hypotheses, fragmented signals into recommendations, medical reports into patient questions, job descriptions into capability maps, and customer requests into resolution paths.

But AI only becomes a product when it is placed inside a real activity gap.

AI outside activity is a demo. AI inside unfinished activity is a product.

The question is not where can we add AI? The better question is: which activity can now be completed differently because AI can become the missing means?

A founder should be able to explain the product idea like this:

The customer is trying to transform [initial material] into [desired result], but the activity breaks because [gap]. Our product introduces [missing means], so the customer can complete the transformation with less time, less effort, less risk, or better quality.

If this is hard to fill in, the idea may still be too vague. If it becomes clear, you are much closer to a real product bet.

The old discovery question was: what problem should we solve?

The better question is: what activity is unfinished?

The old product question was: what features should we build?

The better question is: what missing means would close the activity?

The old validation question was: do users like the idea?

The better question is: can users now complete something they could not complete before?

Great products do not just solve problems. They close unfinished activity loops.