The origin story was personal. It earned the right to make an argument. This module makes it.
The Problem ↔ Solution Framework is where felt becomes named — where your lived discovery gets translated into language a customer, investor, or partner can immediately recognize as their own reality. It's the point in the narrative arc where the most personal thing you've built becomes the most transferable thing you own.
There are two distinct moves here, and the sequence matters. The problem comes first — not because it's easier, but because the solution only earns belief if the problem has already been made undeniable. Work through Part 1 completely before you begin Part 2.
The output of this module is a durable document — a single, authoritative articulation of the problem your company solves and the fundamental shift your solution introduces. It isn't audience-specific. It's the underlying argument that every audience-specific version is derived from.
You'll use it in investor decks, OEM conversations, grant applications, website copy, case studies, and team onboarding. When it's done well, the people reading it feel like you finally named something they already knew but couldn't articulate. That recognition is the mechanism behind every high-stakes conversation that follows.
Where your discovery becomes an argument. The goal isn't to describe a category of pain — it's to name the structural condition that makes the status quo unacceptable. Specific. Systemic. Undeniable.
Three prompts. Each one tightens the argument. Write 200–400 words per prompt before editing. The precision comes in the revision, not the draft.
What is the underlying condition — the design assumption, the systemic constraint, the inherited model — that makes this problem persistent? Don't describe the symptoms. Describe the structure that produces them. Why does this problem keep appearing no matter how hard people try to work around it?
Who loses — and how? Not abstractly. Specifically: what does the person on the receiving end of this problem experience? What does it cost them — in time, money, trust, performance, or quality of life? The structural condition becomes undeniable when its human consequence is named precisely.
What assumption did the incumbent players make — consciously or not — that allowed this problem to persist? Why was the constraint treated as inevitable rather than solvable? This is where you name the blind spot that your company exists to correct. It's also what makes your reframe feel earned rather than arrogant.
Before moving to Part 2, test what you've written against three questions. If you can't answer yes to all three, return to the prompts. The solution only earns belief if the problem statement has already removed the exit ramps.
Not what you built — why a fundamentally different approach is possible. The solution block isn't a product description. It's the macro reframe: the new premise, the structural shift, the argument that changes what the market believes is achievable.
Three prompts. Each one earns the technology introduction that comes in Module 3. The goal here is the reframe — the new premise — not the product specification. Stay macro.
What is the foundational assumption your solution is built on — the premise that is different from every incumbent? This isn't your product feature. It's the underlying logic that makes a different kind of product possible. State it simply. It should be one or two sentences that make an incumbent player uncomfortable.
What does your solution replace — not improve? Name the transition at the level of principle: what condition changes in the world when your solution is adopted? Write in outcomes and consequences, not mechanisms or architectures. The how belongs in Module 3. Here, the question is what becomes possible — and what is no longer acceptable — once the new premise exists. Each "from → to" should describe a change in the customer's or market's experience, not a feature of your product.
Why does this reframe matter beyond your initial deployment context? Where else does the same structural condition exist? This isn't a market size claim — it's the argument that the new premise is applicable at a scale that makes this company worth building, investing in, and partnering with. It should feel expansive without being inflated.
Complete and test Part 1 before touching Part 2. A weak problem statement produces a solution that sounds like a pitch, not a response.
The product specification belongs in Module 3. Here, the job is to make the new premise undeniable — not to enumerate features.
Read your origin story, then your problem statement, then your solution. Each one should feel like the inevitable next sentence. If there's a gap, close it.
One question: after reading this, does your company feel necessary? Not impressive — necessary. If they say "interesting," keep writing. If they say "of course," you're done.
This framework isn't a deliverable — it's the source document everything else is derived from. Every deck, every website page, every investor memo draws from this.
If the prompts surface real uncertainty — about the structural argument, the reframe, or the scale of the opportunity — that's not a writing problem. It's a clarity problem. The Problem ↔ Solution Framework is Module 2 in Track 1: Foundational Clarity. The technology narrative in Module 3 depends entirely on the foundation built here.