9. Your product isn't your child
And how thinking that it is, gets in the way of making critical decisions.
Welcome! I’m Vincent and this is a Product Manager’s Notebook, a series of notes for people who are interested in sharing and learning the art of product management and career development. You can read my archive here.
If you appreciate reading this post, please consider liking and subscribing.
“My product is my baby.”
“My product is my second child.”
You hear this quite often from product managers, and it is an understandable fallacy that comes with the sense of ownership we feel towards our product. It’s one I’ve experienced before, and one I’ve learned to evolve my perspective from.
Today’s story talks about how and why it happens, and the potential pitfalls to avoid.
One for All and All for One
As I’ve mentioned before, I was the sole PM managing my first product for 18 months. Forget the 2 pizza rule, where the “ideal ratio” is 1 PM to the number of Engineers who can share two pizzas. (About 8, in case you’re wondering. And yes you better hope that’s a big “pie”, as Americans like to call it.) One PM to 5 Engineering teams of 28 people.
What did this mean in practice?
Creating a product vision and strategy, where there wasn’t one before
One-to-one meetings with each of the Engineering team leaders on a regular cadence to make sure we were on the right page
Establishing principles to follow for the tools we were building - were they designed for beginners or experienced users and what were the implications?
In-depth project meetings with project leads and internal teams for ongoing initiatives to see where we were getting stuck and managing timeline updates
Hands-on phased updates for an architectural migration that had been stuck in limbo for years
Creating an internal community for communicating initial releases and beta testing.
Creating the documentation that had not previously existed, whether on internal projects, or client facing guidelines
Being the sole business counterpart for the agile process of 6 week long PIs, leading 10 kick-offs over a year and half.
Along the way, I began to build a deep relationship with my Engineering partners and started to learn the good, and the bad, of being a product partner. I learned about their likes and dislikes, their families, their commute, the ways they liked to work and the ways they didn’t. I started to understand some of the ins and outs of the technology stack, what was possible, what wasn’t.
I became the face of my product, the one who worked with other product teams for integration, provided updates, reviewed bug fixes, and prioritised resources.
And finally, changes were starting to appear in the product. Not just invisible tech upgrades, but changes people asked for. We were making it easier for people to work create custom formulas. We were designing a completely new in-app help that wouldn’t disrupt the user experience. There was somewhere for people to go to see what projects were in flight, and what the future roadmap looked like. Internally, buzz was growing.
I started to feel that there were very few in the company who understood the product as thoroughly as I did: what belonged to the front-end (our responsibility) and what belonged to the back-end (generally not us). I felt protective of it when people criticised it.
I was the product and the product was me. The product was my baby.
Then came the announcement.
Change is the one constant
One thing we joke about a lot in the company is that things change a lot. And I mean, a lot.
“Change is the one constant.”, we like to say, as leaders move, team structures change, reporting lines shift, and responsibilities migrate. It can be a great thing, as people get wider experience around different business areas, and no-one gets “stuck” within a position for so long that they get pigeon-holed. The fluidity can also create a sense of uncertainty, which can be unsettling.
None of them had ever really impacted me in the past. When the “musical chairs” took place, my job had always stayed the same. This was about to change.
The call came late on a weekday as I was coming home from work. The message was simple. The reporting structure for my product was completely changing and changing departments. There had been some politics involved (as there always is), but everything had in essence been decided.
In a rare turn of events, I was given a choice to make:
Stay with my product and transfer to the new part of the business.
Stay with my team and manage new products.
I had 48 hours to make the decision. What did I want to do?
Making a decision
I weighed up the pros and cons. First in my head, then on paper.
I really enjoyed my department; the people I work with and report to, and I believed strongly that the future of our business (and finance in general) lies in providing top quality data and technology solutions. The Bloomberg Terminal is the most powerful tool in finance, but our customers are also increasingly asking for more flexibility to create their own solutions. Emerging technologies such as Gen AI and advanced techniques such as Machine Learning continue to drive that trend.
I already had additional ownership of two data products. I was heavily involved in our growing product community. On paper, the choice was simple.
Emotionally, it wasn't.
Letting go of my product meant letting go of everything I’d built up to that point. The projects that I’d been intimately involved with and I wouldn’t see the completion of. It meant no longer working with the dedicated engineers I’d gotten to know and developed a deep appreciation for. It meant letting go of my vision for the product, which would inevitably change under another PM. Letting go of my identity as this product’s PM. My baby.
But in the end, that’s what I did. I knew in my head that that was the right decision to make, to stick with my product team and the community I enjoy. To remain part of a business whose vision I strongly believe in. To continue learning with and from product people that I had a growing relationship with.
I documented as much as I could before the transfer period, said my tearful goodbyes and handed over the reins to someone else.
For a while, I felt very sad. I grieved privately on an event I didn’t feel many people could understand. I did what people sometimes do in these situations. I talked to my family. I wrote on LinkedIn.
Lessons learned
With time comes perspective.
As I sit here nursing 2 children under the age of three, recovering from a particularly bad virus, it’s important to remember that your product is not your child.
The main challenge is with the impact of critical thought:
Overprotectiveness: A reluctance to hear criticism of your product, because “how dare they when they don’t understand how it works?”. Feedback often has a nugget of truth to it, at least for the person giving it, and being overprotective of your product closes you to potential issues, and opportunities.
Emotional attachment: Managing a software product means that we need to sunset features that no longer work for us and let them be deprecated. When you’re emotionally attached to it because you were involved in the build, you can become reluctant to let it move on or die completely. And yet, maintaining a feature for the sake of your connection to it is not a rational decision, and can be a costly one at that. As its PM, you need to be able to emotionally distance yourself from the product to make calm, critical decisions. Your product relies on it.
Product is a team sport: If you’re the “parent” of the product, who is everyone else? Are UX, Engineering, Customer Support the hired help or other members of the family? As I discussed it at more length here, Product is a team sport where everyone plays a part, with responsibility and curiosity across the company. Being a "parent" implies a more hierarchical structure with the PM "knowing what's best".
You’ll need to hand it over at some point: All product ownership is temporary, whether you, the product, or the company moves on. There will be no joint custody and there will be no visiting hours. It’s best to recognise that early on. That’s not necessarily a bad thing - new opportunities await for both you and the product.
So if you’re not the product’s parent - what are you?
Introducing the Product Gardener
While managing a product has parallels with parenting (a topic for another time), instead of a parent for the product, I now see myself more as a gardener.
What does it mean?
It means we have a strong sense of duty to care for our product and make the right decisions for it. While in our care, we do our very best to make sure that we plant the seeds in the right places to grow long-term sustainable roots, as well as bring in the rest of the team (Engineering, Sales, Support et al) to care about it the same as we do. Sometimes that means pruning wayward branches for the sake of stronger, healthier growth. We fix bugs, though not all of them are bad. We look for root causes of problems, in case they infect other parts of the tree. We put systems in place for continuity, even when we're no longer in our position so that others can understand the decisions that were made and carry on our duties.
Over time, the tree grows. 🌳
Doing so helps to bring a critical eye to product decisions. Of course, I still care intensely about my products. However, I base my decisions on evidence and customer stories, as well as product principles. I’m no longer the “X Product Manager” but rather the “Product Manager responsible for X”.
If you take nothing else away:
Your children at home are your children. Let your product be your product. You and your product will thank you for it in the long run.
I hope you’ve enjoyed this piece and you found it useful, please share it with others who might as well.