Retconning: constructing a narrative after the fact that someone could think is a plausible explanatory story for how something got to be where it is.
The technical term is "
retroactive continuity".
But I think it's a useful way to understand and develop products.
Imagine you were handed a pre-existing product to be the PM for.
Like all post-PMF products, it will be a bit of a hot mess.
It will have adoption and usage, and also be kind of broken or ugly in some significant way.
How should you develop this product? Where should you take it?
A step I like to take is first try to retcon its story.
Not how it actually came to be, in all of its messy, random glory.
But a story that makes it sound like all of its random little features were intentional, that listeners would find plausible.
This gives you the throughline of what the product is and wants to be.
The things that resonated with its users in practice.
Now that you have a narrative throughline, you can extend it into the future.
Extrapolating, where might it get to in a decade?
Then use that as your northstar.
Once you do that, often you realize there are some parts that felt important that you can now see are vestigial.
Or that some parts you thought were random appendages are actually the beginning buds of a beautiful and important blossom.
Now that you have the throughline, you can make it more like what it wants to be, closer to that narrative.
You can repeat this progress, ping-ponging back and forth, many times over multiple years.
Retconning helps you figure out what the product wants.
A product, after all, is an accumulation of millions of micro-decisions made over many years by millions of people (engineers, PMs, customers).
Finding the troughline, the consistent truth underneath that flowing swarm behavior allows you to see its core emergent story that is being told.