3 Product Lessons from a 3-month old Product Manager

Renowned Philosopher Karl Popper once said, “The best thing that can happen to a human being is to find a problem, to fall in love with that problem, and to live trying to solve that problem unless another problem even more lovable appears.”

What Popper said has been the story of my life so far. Up until last year I used to dream in code, I felt there was no bigger cause for me to pursue than using code to solve the world's problems and for 5 glorious years and I proclaimed this to everyone who knew me or was pleasant enough to listen to me rant. I was very sure I would die a Software engineer, well, until I came across the field of Product Management.

I quickly become obsessed with shaping the Product to deliver the most value to the customer and how by doing that, we could also increase business returns. Suddenly I was daydreaming about Product Strategy and was studying all the Products I used to see the psychology they used in-order to deliver a great user experience. I loved it, I read up on what it would take to become a Product Manager, wrote some certifications and convinced my employer to give me a Product role, even though at the time there wasn't one in the company.

Being a Product Manager has been a fulfilling journey, and I am loving every part of the ride. On my road to being a PM, I read a lot, from blogs to books, to case studies, listening to Product School podcasts and webinars. This taught me a great deal, but as always there are some things you can only learn on the job. Below are a few of the lessons I've learned in my short stint as a PM for a small software development company in Zimbabwe.

Lesson 1 - The Customer is King but the Business is Queen

Anyone who has ever played chess will tell you that while the King is the most important piece on the board, it is the Queen that decides the game. It is the same with Products, the customer is King and their user feedback is golden and it should drive your Product development but ultimately the business is Queen. The business decides which initiatives get funding and resources, and just like the customer, the business is a very important stakeholder in all product matters.

There is a need to make sure your product decisions and strategy align with your business goals and that business personnel are consulted on major product decisions. As a PM it is your role to garner buy-in from both internal and external stakeholders. In the same way you deliver value to your customers, the business should ultimately see value in all product initiatives. Another important lesson is that when you do get buy-in and leeway to execute product initiatives, always come back to show results to your product sponsors. Routine reports showing progress and results (revenue, new user acquisitions, positive reviews, reduced churn, etc) are key in achieving this and should be sent out regularly to stakeholders. This will ultimately establish your reputation as a PM and give you the necessary goodwill for future initiatives.

Lesson 2 - Sometimes telling people your big idea isn't enough

Starting in my new role I had a lot of big ideas and set about researching them, evaluating their impact on the product and writing copious amounts of documents and sharing them with stakeholders for their input and buy-in. Most of these emails were largely ignored and where responses came in, it was usually a request to meet and have me explain the idea in person. I didn't get it, I just wrote a meticulous 5-page document outlining everything and someone would still ask me to come and break it down to them from scratch.

Now in my previous life as a developer I would have loved having a comprehensive document outlining what needed to be done but what I quickly learned was that communication is not a one size fits all, it needs to be tailored to different stakeholders. Some people want a detailed document, some can understand the idea after a 5-minute chat, some require a meeting where you walk-through the whole concept with them, some don't even care about the initiative they just want to know what results you will achieve.

In your role as PM, a central theme will be getting buy-in for your ideas:

• The business needs to understand the impact so that they can invest in your initiative
• The engineering team needs to comprehend it so that they can build it right
• The customers need to appreciate it so that they can use it
• Likewise, the customer service team needs to know how to support it

All of these stakeholders require different types of communication, you need to learn them and use them accordingly.

Lesson 3 - The Backlog is your friend

Coming into a new PM role you will probably have a lot of ideas on new features and improvements you can add to your product. Your first instinct will probably be to try and implement it all as soon as possible, DON'T. Now don't get me wrong here, I am not saying don't implement your new ideas, I am saying don't rush them. Limit your sprints to 1 to 2 epics, anything beyond that, you risk straining the team.

Another benefit you also get from this is enough time to see whether your initiatives are bringing about the necessary results, without the results being muddied by data from other initiatives you are concurrently implementing. Remember all your initiatives should be clearly defined and SMART, and by SMART I mean Specific, Measurable, Achievable, Relevant, Time-bound. You should have specific metrics you aim to measure after a given time to show that what you've implemented is working, it doesn't help if that data is mixed with results from other initiatives.

Fill your backlog with all the epics you wish to achieve and then use that to clearly define your Product Roadmap according to your product strategy. This will help everyone visualize what needs to be done and also the overall direction the Product is taking. Planning your roadmap also allows you to effectively plan the use of Project resources.

Now this list is not comprehensive and I plan on blogging my PM journey as I learn more and gain more experience, to hopefully becoming Director of Product (one day 😅). I am very grateful that you took time to read my thoughts and hopefully you found them useful. Please do let me know what you think in the comment section, both feedback and criticism are welcome. I am also looking to meet and interact with more people in the Product field, so feel free to also say hie.