Skip to content
Anchor
All posts

Running discovery when the last PM left no notes

A first-fortnight sequence for inheriting a product whose reasoning walked out the door.

Noa Bergman9 min read

Inheriting a product is not the same as starting one. The decisions are already made; what is missing is why. Reconstructing that in order matters, because starting from the roadmap gives you the least reliable artefact first.

Start with the disagreements

Search the archive for conflict, not for summaries. Threads with many replies, tickets reopened more than once, documents with several revisions in a short window. Conflict is where reasoning gets written down.

Then the incidents

Post-mortems are the highest-density product documents most teams own. They describe what the system actually does under pressure, which is frequently not what the specification says.

Then the customers who left

Churned accounts hold sharper information than active ones, and nobody is protecting the relationship any more. The reason they gave for leaving is usually a requirement in disguise.

Only then the roadmap

Read it last, and read it as evidence rather than instruction. A roadmap tells you what a previous person believed under conditions you cannot see. Treated as a source it is useful; treated as a plan it is inherited debt.

Write the contradictions down first

Your first deliverable should not be a strategy. It should be a list of the places the archive disagrees with itself, with each side attributed. That document buys you more credibility in week two than any plan, because it is checkable.

PlaybookDiscoveryOnboarding

Stop writing PRDs without understanding the product.

Anchor reads your interviews, tickets and docs first — then writes, citing every line.