Head of Product: What I've Learned after 4 Months
I started my career as a product manager just over 4 years ago. The boom in social gaming allowed me to leverage my analytical background to transition from finance to PMing games. Being entrepreneurial, a problem solver, and fascinated by technology, I gravitated to product management and can't think of a better career option.
The funny thing about product management is there's very little hierarchy, which also means there's limited upward mobility.
Recently, I've been given the opportunity to lead product management at a 270 person startup while they searched for a Chief Product Officer. Since joining, I've been leading a small team of 5 product managers and dealing with things I've never had to touch as a product manager.
It's healthy to take some time to reflect and introspect once in a while.
Here's what I've learned. It's not a list of what makes a great Head of Product, but just what I've noticed. Actually I haven't found many resources at all about being a successful Head of Product. Most resources are about being a product manager.
1. Always challenge the narrow framing to build something.
I'm learning to challenge requests in a cooperative way. At Helpling product managers rarely get time to dream up ideas on what we should build next. There is so much demand, so much opportunity, so much growth and so many more bugs that we are inundated with requests. Requests come from every department and passionate employees push their requests through harder than Lonsdaleite. So all this leaves product managers with quite an enormous burden of understanding the request, analysing its efficacy, considering whether or not it (or a better solution) should be built and the priority.
A book that has helped me with this is Decisive: How to Make Better Choices in Life and Work by Chip and Dan Heath. A particularly helpful section of the book is about how to widen alternatives. One way is company introspection: finding effective and efficient parts of the business to be used as role models for boosting efficiency. Another is competitive analysis where you look at people who have already solved the problem for you. Walmart for example largely rode to success with this strategy-- Mr. Walton extols the effectiveness of taking great ideas and tactics from other businesses. Finally there's analogies, taking solutions from other realms and transplanting it to a new domain.
Once you've opened the narrow frame of the request, you are much more likely to build something amazing.
2. You can't build something that is perfect.
Just like there isn't a perfect animal, there isn't a perfect product. A shark is great at swimming, biting, and hunting. If it were a product, it'd be a pretty awesome product. But a shark is not a perfect animal. It can't fly. It can't walk. It doesn't have good defensive armour. Check out a great white shark vs. saltwater crocodile fight thought experiment.
That's why it's crucial to understand your goal and users when trying to build a solution. If you came to me and said your goal was to survive in the ocean and reproduce, then I'd probably build you a shark. But if you were a vegetarian and pacifist, then I'd need to re-think and build you a jellyfish or something.
To see how successful your animal is you'd look at KPIs such as how much energy the animal consumes, how long the average animal survives, how many babies are born, and mortality rate. Given how long sharks have been around (450 million years), I'd say it's a pretty solid product.
The key is what you build truly depends on your goal and users.
What follows is standard product management...
Once you've understood your goal and your users, you'd generate lots of cool ideas. There shouldn't be a blindly obvious choice because if there is, it means you don't really have a decent set of options. Next, you'd use some criteria to decide what to build or not build. Generally, I'd use customer impact, cost to build (tech difficulty, time, money), and monetary return. You'd also pick a set of metrics to watch to determine if your solution was successful or not so you can adjust accordingly. A good product manager knows what to pick. Just because usage of a feature is up doesn't mean the feature is a success ;)
3. Most of your work will be on process and structure.
At the executive level, it seems the job is more and more about managing people. Sure I get to make some cool strategic decisions from time to time, but mostly I'm tasked with spearheading workflow and process improvements, communicating and documenting it, and ensuring successful adoption. I'm not sure that's entirely for me and perhaps I'd be happier leading a dedicated team where I can be more hands on.
I thought I'd spend more of my time on road mapping and experimenting, but currently it's all about managing workloads, communicating with other departments, and crafting process and structure.
4. Sell within your company
I also realised you need to sell to your team, to your stakeholders, to people you work with. Often times you don't have simple, obvious decisions. Not everyone in the room is going to say yes. And that's a good thing for the product and business.
When working in an environment where views are opposed. Here are two great tactics to use to build cooperation.
What would need to be true for X, Y, or Z to each to be the best alternative?
Asking this question increases cooperation by shifting the focus to the realities of the situation, which gives the alternatives all a fair chance at being considered. Sometimes it involves collecting more data but whatever is the reality determines which choice should be taken.
Under what situation would we reconsider this?
This allows teams to take action but also lets dissenters to voice their opinions or concerns without seeming like they are trying to undermine their colleagues. Here the dissenters can still be team players and let results determine if something should continue or be reconsidered.
5. Ask for updates in writing.
This was something that I found to be quite a time saver. When you ask your reports for things verbally, often they feel put on the spot and may not give you the most comprehensive and coherent answer. It's also synchronous which means you can't look at it at your convenience. So this is more of a tactical thing I've learned that could help new managers.
I'm looking forward to continuing my personal growth in product and building awesome products. Let me know if you want to meet for a coffee in Berlin or work at Helpling (we're hiring).