5 things I wish I knew before becoming a Product Manager
I’ve been working as a Product Manager on both software and non software products, as a consultant in marketing strategy and as a consultant on lean methodologies and user centred design. Throughout my career, I’ve worked in fields spanning from finance to tech and communication. I still remember the abrupt transition to Product Manager for a software product and how much confusion there is in our industry about this role and its responsibilities.
Here are 5 things I wish I knew before becoming a Product Manager.
1. Sometimes you will spend more time managing stakeholders than managing your product
In order to create a valuable product you need to ensure coherence between user needs, stakeholders expectations, and the way the team works. Managing expectations and communicating effectively is a tricky task, and should not be underestimated.
Often demands come from so many places that we don’t even know who we should be talking to. Make sure you identify and call out your stakeholders early in the project. Try to narrow down as much as possible the number of stakeholders in order to keep a clear line of communication open.
Nevertheless, requests are often conflicting, and at times it can get a bit overwhelming for the Product Manager. My best advice for a Product Manager in this situation is to spend time understanding all of the motivations, fears, hopes and expectations of the people involved in their project. Be assertive and make sure to set expectations straight. Take the time to listen and communicate early and often. Make sure that everyone feels heard and earn stakeholder’s trust by truly listening and by knowing your product and your backlog in and out.
2. You will only be a good Product Manager when you learn to say NO effectively
Saying ‘no’ is one of the most challenging parts of being a Product Manager. There are so many great ideas coming up all the time and ideally we’d like to do all of them. But as a Product Manager, you need to keep focus on the vision, the user needs and the value this ideas can bring.
Saying no and declining a request or an idea can be hard, but it is very necessary for having a successful product. Nevertheless, this doesn’t mean it has to be confrontational. Instead of just saying no, don’t hesitate to point out impact on costs and risks. Whenever you can, say ‘not now’ especially if the idea is valuable but not yet to be prioritised. You need to focus on the next most important thing to be done.
In addition, try not to say ‘I’ while saying no. Use data and complete transparency in prioritisation and show the value for the product and for the business versus a personal opinion.
3. Writing user stories is not as easy as it seems
A user story describes a feature or set of features the developers will work on. This seems like an easy task as it is something we already do all the time: describing a task for ourselves, our kids and for other people.
Only that writing a user story is much more than simply describing a task and if you want to do this effectively, it will prove to be harder than you would expect. Here come questions about how to split stories, how specific should the stories be and how do we manage edge cases and bugs and chores.
Also, some stories take time to think them through. Don’t go quick and dirty. Many of the junior Product Managers I’ve known want to write super quickly even the most complex user stories. Take time to empathise with the user but also to write clear acceptance criteria without getting into technical solutioning. Keep stories simple and concise, but insure that they make sense by themselves.
Be flexible to change user stories depending on new user feedback and technical constraints. Accept that the stories might not be perfect from the beginning. Iterate and constantly find room for improvement. Don’t be afraid to ask for help from designers and engineers in specific cases.
4. You are not the boss of the team
Ben Horowitz, in his famous post Good Product Manager/Bad Product Manager, introduced the idea of a good Product Manager as being the CEO of the product. Even though he wrote that 20 years ago, there’s still a lot of controversy around this topic.
Product management is still a relatively new discipline in the world. Across different companies the responsibilities of the role can range from those of a project manager to product owner or even being the boss of the team. Not long ago I heard one of my clients say ‘I know what the team has to do and how to do it’. Another time they said ‘I told them to do this exactly, why isn’t it done?’. This approach is very far from my view of what a Product Manager should be.
A good Product Manager leads through vision, communication and influence, not commands. They focus on bringing together the best people to drive the product forward and make sure every team member is heard and enabled to speak up and share their best ideas.
Sometimes, when we don’t have enough information or consensus is not achievable, Product Managers need to step up and take decisions for the team. Nevertheless, a good Product Manager knows that a successful product is a team job. The best Product Managers spend time supporting other disciplines and making sure that the team is happy and cohesive.
5. Advocate for the right methodology instead of the number of engineers
In one of my past experiences I worked with a team of 10 engineers. The main competitor for this product had 200 engineers. The Product Owner, the Product Manager and I spent endless amounts of energy to advocate for hiring more engineers. Looking at the figures, this made sense to us at the time: 200 engineers will get 20 times more work done or deliver 20 times faster than 10.
Once you’ve identified a competitor, they are already several months or years ahead of you. Even if you could hire 200 engineers today and scale your application and process, you would still be playing catch-up. What you actually need is some good engineers and an effective methodology. Here at Pivotal Labs we create successful products with our clients with very small product teams by building empathy with the user, de-risking technical challenges early and engaging in strong collaboration within the team. In this way, we build effective products that users love while also ensuring the business achieves their goals.
If there is one take-away from this entire list, it should be that good Product Managers focus on building the right thing, empower their team to take the right decisions and share the success of the product.