How I Adapted Working Backwards Into a Full-Stack Startup Strategy System

I’m not sharing a specific company strategy. I’m sharing the operating system I use to pressure-test startup ideas before I commit too much time, money, and attention to them.

That distinction matters.

There are things I do not want to publish while they are still live: the exact idea, the exact ICP, the exact product wedge, the exact investor logic. But the method itself is worth sharing because it has become one of the most useful ways I know to reduce self-deception early.

Amazon’s Working Backwards framework is a big part of that method.

It is also not enough.

What Working Backwards gets right

The core idea in Working Backwards is simple and unusually powerful: start with the customer experience you want to create, write it as if it already exists, and force clarity before you start building.

That is why the PR/FAQ is so good.

It makes you answer questions most founders try to avoid:

Who is this for?
What problem does it actually solve?
Why is it meaningfully better than what exists?
Why would anyone care?
What objections would a skeptical customer have?

That discipline is valuable because most startup ideas sound more coherent in conversation than they do in writing.

Writing exposes fuzziness.

The moment you try to explain the product as if it has already launched, a lot of weak thinking becomes obvious:

the customer is too vague
the pain is too soft
the language is too internal
the value is too incremental
the idea is really just a feature in search of a user

That is the part of Working Backwards I would keep even if I threw everything else away.

Why PR/FAQ alone stopped being enough for me

A PR/FAQ is excellent for clarifying customer value.

A startup, unfortunately, is not only a customer-value artifact.

At some point, if the idea survives first contact with writing, more questions appear:

Is the market actually large enough?
Is the buyer the same as the user?
Is the category too crowded?
What would make this defensible?
What has to be true in the product for the promise in the PR/FAQ to be real?
Who would fund this?
Who would acquire this?
What sequence of proof points would matter most?

This is where I found the standard Working Backwards pattern too narrow for the way I wanted to think.

It gave me one very strong artifact. I needed a system.

The document stack I ended up building around it

What I use now is closer to a strategic document stack than a single framework.

I still start with the PR/FAQ. But from there I branch into a set of linked documents that answer different questions.

The cleanest way I know to describe it now is:

core Working Backwards artifacts
strategic extensions built around them

I published the sanitized version of that structure here: working-backwards-framework.

The core artifacts are:

And one of the clearest examples of how I extended the method is the Market Analysis.

Conceptually, the stack looks like this:

PR/FAQ: what is the customer promise?
MRD: what does the market actually need?
PRD: what are we actually building?
Market analysis: is the opportunity large and attractive enough?
Competitive analysis: where do we win and where are we weak?
Investor landscape: who is likely to fund something like this, and at what stage?
M&A analysis: who would plausibly buy this, and why?

Each one exists because a startup idea can feel compelling while still failing one of these tests.

A PR/FAQ can sound great while the market is too small.

A market can be large while the positioning is weak.

A product can be interesting while the investor case is unconvincing.

A company can be fundable while being strategically unattractive to likely acquirers.

The point of the stack is not to create more paperwork. The point is to make hidden assumptions collide with each other early.

The real value is cross-document tension

The most useful thing about this system is not any single document.

It is the tension between them.

A good PR/FAQ can be undermined by a bad market analysis. A strong market analysis can expose that the PRD is pointed at the wrong user. A sharp competitive analysis can reveal that the language in the PR/FAQ is not actually differentiated. An investor memo can expose that the entire sequence of milestones is unrealistic.

This is why I think of the stack as a strategy system rather than a template collection.

Each document is answering a different question, but they are also checking each other.

That makes the system more honest.

It is also why I cleaned up the public repo the way I did. The core documents are the spine. The extension documents exist because once an idea survives the first customer-value pass, more strategic questions begin appearing whether you are ready for them or not.

How LLMs changed the practicality of doing this

This is where the process changed the most for me.

Before LLMs, maintaining this many artifacts felt expensive. Not impossible, but expensive enough that most people would only produce one or two of them with real care.

Now the economics are different.

LLMs do not replace judgment here. They make disciplined strategic writing much cheaper to do and much easier to iterate.

They are useful for at least five things.

1. First drafts

The blank page is expensive.

Recording yourself, recording conversations with other people about the idea, and capturing rough notes early are all good ways to create the initial raw material. Customer interviews, founder debates, personal memos, product hypotheses, and market observations are all much better inputs than a blank prompt.

The more human-generated material I have, the more useful the LLM tends to be. Real conversations create friction. Notes preserve uncertainty. Interviews surface objections. All of that gives the model something real to work on.

What I do not want is the LLM generating the starting point itself. Humans should originate the thinking. The LLM should help synthesize, structure, compare, and sharpen it. Otherwise it becomes too easy for the model to make weak thinking sound more mature than it is.

Once I have that raw material, an LLM can help generate a first pass at:

PR/FAQ
MRD
PRD
market analysis
competitive analysis

That does not mean the first draft is correct. It means I am no longer paying the full cognitive cost of starting from zero every time.

2. Critique

This is more important than generation.

I can use an LLM to ask:

Where is this too vague?
What assumptions are unsupported?
Which objections are not answered?
Where does the ICP drift across documents?
What is missing from the strategy?

That kind of critique is useful because it gives me a second pass at rigor before I waste time socializing weak thinking.

3. Cross-document consistency

This is one of the best uses of LLMs in the whole process.

I can ask:

Does the PRD actually support the promise in the PR/FAQ?
Does the MRD describe the same buyer as the PR/FAQ?
Does the market analysis justify the investor story?
Does the competitive analysis contradict the positioning?

That is high-leverage work. It is not glamorous, but it prevents strategic drift.

4. Research synthesis

Markets, competitors, investor patterns, and acquisition histories produce a lot of scattered input.

LLMs are useful for compressing that into something legible:

summarizing repeated themes
clustering competitor patterns
translating scattered notes into structured arguments
identifying contradictions in the evidence

Again, this does not remove the need for judgment. It lowers the cost of reaching a judgment.

5. Iteration speed

The final benefit is simply speed.

A system like this works better when it can be revised often.

LLMs make it easier to:

test alternate framings
rewrite sections after new evidence
generate sharper versions of weak arguments
update multiple documents after a major assumption changes

That is not intelligence by itself. It is leverage.

What LLMs do not do

It is worth being explicit here because this is where people get sloppy.

LLMs do not decide whether an idea is good.

They do not talk to customers for you.

They do not remove the need for taste.

They do not eliminate the need for evidence.

They do not tell you what to care about.

What they do is make it much more practical to externalize, compare, pressure-test, and revise your thinking across multiple strategic artifacts.

That is already enough.

How to avoid doc rot

This is the part most people ignore.

The problem is not only writing strategy documents. The problem is that most strategy documents die almost immediately.

They are written for one meeting, one offsite, one investor conversation, or one product cycle. Then reality changes and the documents stay still.

That is how doc rot happens.

In this system, I try to avoid that in a few ways.

Clear document roles

Each document should answer a distinct question.

If two documents overlap too much, both become vague and neither stays authoritative.

Explicit ownership

Every important document should have:

an owner
a status
a last updated date
a reason it changed

If no one owns it, it is already decaying.

Update triggers

This is probably the most important rule.

Documents should not update because someone vaguely remembers they exist. They should update when something important changes, for example:

a batch of customer interviews changes the ICP
a new competitor launch changes positioning
pricing changes
product direction shifts
fundraising timing changes
new evidence invalidates a core assumption

That keeps the documents coupled to reality.

Regular review

Not every artifact needs constant rewriting, but the system needs review cadence.

Some documents should update with market movement. Some should update with product changes. Some should update only when strategy meaningfully shifts.

The point is not permanent editing. The point is preventing dead strategy from masquerading as live strategy.

Why I think this is worth the effort

A lot of startup work dies not because the founders were lazy, but because their thinking stayed too implicit for too long.

They felt the strategy in fragments:

in conversation
in decks
in product decisions
in fundraising narratives
in half-written notes

But the fragments were never forced into coherence.

That is what I use this system for.

Not to make ideas look polished.

To see whether they survive coherence.

The real upgrade

The real upgrade is not “use Working Backwards.”

The real upgrade is:

start with customer clarity
extend that into a broader strategic document stack
use LLMs to reduce the cost of disciplined iteration
keep the documents live enough that they continue absorbing reality

Most people do not need more startup ideas.

They need a better way to pressure-test the ones they already have before those ideas absorb too much time, money, and attention.

That is what this system is for.

Thanks to Sunil James for first introducing me to the Working Backwards framework and helping set this line of thinking in motion.