Running discovery when the last PM left no notes
A first-fortnight sequence for inheriting a product whose reasoning walked out the door.
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.
Stop writing PRDs without understanding the product.
Anchor reads your interviews, tickets and docs first — then writes, citing every line.



