I’ve been thinking recently about what it means to take on a product that is already some way into development. I’ve joined a project where the product has been developing for a while, but I wouldn’t describe it as established. It has pivoted and changed direction a few times and some of the thinking about where it should go is still emerging.
The Product Manager who has been looking after it is also still involved and has considerably more history with the product than I do. Naturally, they understand much more about why previous decisions were made and what led to the current direction.
One thing that has become clearer as I’ve got further into it is that knowing who is responsible for what only gets you so far. When a product has changed direction several times, understanding the decisions that got it there can be just as important.
What I was trying to understand
One of the first things I did was spend a few minutes mapping the day-to-day responsibilities and where I thought there might be overlap. I kept this high level, surfacing both the obvious areas and more opaque areas.
It was mainly a quick way of clarifying my thoughts and it helped me orient myself. I had a better sense of where I should be focusing and where I still needed to understand more.
Decisions have taken longer to get my head around. There is quite a lot of history behind the product that isn’t visible when you first arrive. Something that looks questionable after a few conversations might already have been explored. I don’t want to arrive and mistake having a fresh perspective for having a better one.
Prioritisation was one of the first places where this became apparent. I was finding it difficult to decide what should come first and, from the conversations and information I had at that point, I couldn’t see a sufficiently clear shared view of what the product was ultimately trying to achieve.
Those things were connected for me; it is difficult to judge competing priorities if you aren’t clear enough about what you are trying to achieve. I raised this with the other PM and started putting together an initial draft of a product vision. That became part of the wider thinking and they are now developing the vision further.
I find that example interesting because it doesn’t fit neatly into the idea of a clean handover. I identified something that I thought was making prioritisation harder, raised it and started shaping a response. I wasn’t ultimately the person who continued that particular activity, but that doesn’t diminish the judgement involved in identifying it.
As I’ve understood more of the product, I’ve also become more comfortable making judgements about what should happen next. Some of the uncertainty I had initially was simply because I didn’t yet know enough about how the product had reached its current position.
Understanding the history without inheriting it
There is a tension here though. Part of the value of somebody joining later is that they haven’t been part of every previous conversation. I want to understand why decisions were made without automatically accepting all of the assumptions that came with them.
Sometimes more context has changed my initial view completely. In other cases I can understand the reasoning behind an earlier choice and still think a different choice makes sense now. That distinction has become easier as I’ve learnt more.
The previous context gives me a better basis for judgement, but it doesn’t make the judgement for me. If anything, understanding why a decision was made makes it easier to ask whether the same reasoning still applies. That matters on a product which has pivoted several times.
A decision might have been made because of evidence that is still completely relevant. It might have been driven by a constraint that no longer exists. Or it might simply represent the best view the team had at that point. Knowing the current direction without knowing any of that history only gives me part of what I need.
At the same time, I don’t need to reconstruct every conversation that has happened before I can take ownership. I’m already making decisions and forming views with the context I have, while continuing to learn more as I go.
The challenge is getting enough of the useful history without allowing the history itself to become the answer.
A different map
This is where I’ve started wondering whether a different kind of mapping exercise could have helped.
Rather than spending any more time documenting activities and responsibilities, I could have looked with the other PM at the relatively small number of decisions and pivots that materially changed the product.
Not every decision and certainly not a complete history of every meeting. I’d want to understand where the product changed direction, why it changed, what was learnt and what influenced the choice at the time. I’d then want to understand what still applies now.
Which decisions were based on evidence we still trust? Which were responses to constraints that may have changed? Which assumptions have been tested and which are still assumptions? And perhaps most importantly, which parts of the current direction are genuinely settled and which are simply where the product is today?
For this product, I think that would have helped me build some of the important context faster. It might also have surfaced the question around product vision earlier. Looking across several pivots and asking what each was trying to achieve could give a useful indication of whether they are now pointing towards a consistent outcome or whether different ideas about the purpose of the product have accumulated over time.
In practice, I’ve been learning much of this as individual questions and decisions come up, which is a normal part of joining any product. I’m also already much more comfortable making decisions within the team than I was when I arrived.
The decision-history approach wouldn’t replace that. It would give me a way of accelerating part of it.
If I was approaching a similar transition tomorrow, I’d still spend a few minutes getting clear on responsibilities. But I’d also spend some early time on the handful of decisions that shaped the product: what changed, why it changed, what was learnt and what remains open. That would give me a stronger starting point for forming my own view about what the product needs next.