My First 10-ish Lessons Learned As a Product Owner
In April 2019, I gave my first ever talk on product management. The theme of the event was about transitioning from software engineering to product management. The title of the talk I gave was “From Software Engineer to Product Owner: 10 Key Lessons Learned”. This is the list of the 10 lessons with a little something extra at the end.
1. It’s about what, not how.
This was the first big lesson I learned and it was a huge shift in my daily thought process. As a software engineer, the core of your job is about how to solve a problem. You’re constantly thinking of how to design that button right, how to show the right animation that the designer just added, or how to reduce the page load time from 3 seconds to 1 second. Whether it’s to improve an algorithm, or to add a new design, or to change a system architecture, the primary concern is how to get it done.
As a product manager, however, the primary concern is what to get done. Let’s assume you’re faced with the option of adding the new button, or improving the page load time or changing the system architecture. The primary thought is not about how to do any of those, but which one of those is more important and why. That way, you’re better able to decide what is more important. This can be a real challenge if you’re coming from a software engineering background and you’re used to thinking of how to get things done. Figuring out what to build can take as much time and effort as figuring out how to build it. So your time is more valuable as a PM when you’ve done the research and know why one problem should be solved first before another one.
2. It’s not about your ideas.
I have to admit that I struggled with this in my early days as a PM. I thought the ideation process was my job and I had to come up with the best ideas to be a good PM. This misunderstanding of my role came from the common statement that as a product owner, you’re the CEO of the product. Who doesn’t want to be recognised as a visionary? The problem with thinking all ideas (or at least the best ones) must come from you is that you’ll almost shoot down everyone’s ideas and keep finding ways to push yours since you’ll believe it’s the best and idea generation is primarily your job. At least that was my initial mistake.
With time, I learned the best approach is not to get emotionally attached to your ideas, instead, focus your emotions and passion on the problem. By caring deeply about the problem, I learned to realise that amazing solutions can come from anywhere and all I had to do was pay attention and listen. Genius solutions can be found anywhere!
I also learned to stop thinking of my role as the CEO of the product. Instead, I started thinking of the role more like that of a midwife, helping deliver a beautiful product by working with everyone in the room and having a deep understanding of the process, every step of the way.
3. Generalist vs Specialist.
As a software engineer, I was mostly a specialist. A new feature needed to be added in the app and the designs are available and all customer discovery was already done. The step I was primarily needed for was the building process. Of course, the best engineers are not just “code monkeys”, they understand the business, can communicate properly (even if it’s through code clarity), and also have a lot of user empathy. However, you can have great engineers who don’t care about those things but it’s almost impossible to be a good product owner if you’re not a generalist.
Transitioning to the product management role meant adding more layers to my responsibilities. I had to understand the business well enough to know if a new feature was driving the right metrics or not. I had to understand designs and user testing well enough to know how to ask the right questions during a customer interview or user testing session. I also had to understand the scope of the tasks well enough to be able to break things down properly in an engineering ticket. Welcome to the world of context switching 🙂
4. Communication is key.
I can’t overstate this. Quite frankly, I’m still learning this myself.
The general rule is it’s better to over-communicate than under-communicate. Easy enough to remember but extremely hard in practice. I had to learn (and still learning) that you can’t communicate with all stakeholders the same way. For some, an email update is good enough. For others, it has to be through the official communication tool (Slack in my case). Others are okay with having a 5-minute chat while some require an hour-long meeting to go through the entire user journey. This can quickly get exhausting for a new PM, especially one transitioning from a software engineering role where most of your communication is through code reviews or quick questions about what APIs to use.
Something I’ve been practicing lately to help with this is to schedule time on my calendar to update all stakeholders at the same time. Whether they ask for an update or not. That way, it’s always in my weekly schedule to give an update and keep the communication loop open.
5. It’s not about perfection.
There’s a perfectionist in most software engineers. The desire to achieve O(log n), maybe even O(1) algorithms, reduce the total line of code to achieve the same thing, find that perfect framework that solves all your problems, the best keyboard shortcuts, the best machines to work, etc. The list is endless.
I believe this perfectionist mindset makes amazing software engineers but it’s something I had to tone down when I started my product management career. The goal is to iterate as fast as possible and sometimes it means shipping when you know there’s a bug. This shift in mindset comes from the desire to test your solution as quickly as possible before spending too much time on a solution that users won’t care about anyway. You want to know what you don’t know as quickly as possible.
So, deliver value (aka ship) as quickly as you can, validate your solutions and only spend time perfecting anything when you have the right amount of validation.
6. Listen, listen, listen.
It wasn’t so important for me to listen to many people as a software engineer. Not many people in the company knew (or cared) enough about the algorithms, data structures or the frameworks and tools we used to provide work-related suggestions. This rapidly changed when I started as a PM. Everybody had an opinion about the product and they all wanted to tell me about it. I had to learn to listen to everyone.
Listening doesn’t mean saying yes to their suggestions. The reality is, you’ll say no to most, but taking the time to listen to everyone gives them the impression that you at least value their opinion and when they have another helpful suggestion, they’ll share it.
7. Outcome vs Output.
As a software engineer, I’d generally measure my efficiency with the total tickets completed, bugs fixed, architecture improvement, completion of a CI pipeline, and lot more. Almost all the metrics that measured my efficiency always revolved around some output. When I changed roles, there had to be a very different mindset shift. Feature completion (the output) is not equal to success. Success meant whatever was delivered moved the right metric (the outcome).
If we pushed out more features and the KPIs (Key Performance Indicators) didn’t budge, then our product development process needs improvement. On the other hand, if fewer features moved the KPIs significantly, then the product development is top-notch.
In the early stages of transitioning, it can be tempting and natural to focus on the output. One suggestion is to define the metric that determines the success of any feature or improvement and then monitoring that metric after the feature is released.
8. The best questions start with why.
For most of my time as a software engineer, the problem statement was already well defined. The impact of the problem on the business was also well understood before I came into the picture. What dominated my thought process was different ways of solving the problem that was already defined and sometimes I was even presented with the solution only to figure out how to code out the business logic into algorithms and user experience. It wasn’t necessarily my responsibility to care about how the problem came about. That said, good software engineers should always understand and care about the problem just as much as other stakeholders.
In my first few months as a PM, it was easy for me to adopt a problem statement without probing too much into how it became a problem. With time, I learned to ask a lot of whys. Why does the problem exist? Why are we going with the suggested solution? Why is the user doing what they’re doing?
The magic of always asking why is that it unlocks a lot of unknowns and most of the time, the most elegant solutions come from a true understanding of user needs. These needs can only be understood by constantly asking why. Why is the customer choosing Lyft over Uber? Why choose Foodpanda over Grab food? Why is a video completion metric more important than a video opened metric?
The secret to improving the “why question” is to always be curious. There will always be unknowns about the customer, the business, your current process, and lots more. The more you’re committed to fully understand the entire domain from the business to the customer and the competition, the more you’ll be able to come up with truly great solutions that solve problems.
9. It’s all about the problem.
Obsess about the problem, not the solution. This is another way of explaining number 7 (Outcome vs output). Whether I’m riding a bicycle, a motorcycle, or driving a car, my problem is how to get from one point to another. Whether a home-cooked meal or eating at a restaurant, my problem is feeding myself to replenish my energy.
Most of the time, the problem isn’t easy to breakdown. Humans are complex, and so are our problems. A lot of people might have the problem of moving from one point to another, but some might prefer a comfortable ride while others don’t care much about that. Some might prefer to exercise while moving and rent a bicycle while others might want to be driven around. Regardless of the situation, however, once there’s a better understanding of the problem, the solutions that you go with would almost always hit the mark.
Much of the job of a product owner is figuring out the right problem.
10. Your success is in people.
Something I had to learn early on as a PM is that you can be an asshole as a software engineer and still do an incredible job but it is impossible to succeed as a product owner if you’re one. Most of an engineer’s interaction on a day to day basis is with machines. On the other hand, most of the product owner’s interaction is with people. Remember the midwife analogy above? Imagine a midwife who doesn’t care about reassuring the birthing mother or the moment things begin to go wrong, starts blaming the man for impregnating the woman in the first place.
The product owner is the missing link, the conductor, the spokesperson, etc. You get the point. Every day, it’s about working with the designers, the engineers, the business stakeholders, your users, and everyone in between. You’re the traffic police ensuring everyone gets to their destination on time while avoiding serious congestion. It’s a real balancing act where everyone is taken into account.
You have to listen to everyone and reassure everyone that they’ve been heard even if it means saying no or deprioritising their request most of the time.
These 10 things were shared in early 2019. In all honesty, I’m still learning these things every day and constantly catching myself when I’m doing a poor job at any of them. It takes time and constant practice. If I’m to give any extra few tips on what has helped me so far, it would be these:
- Spend time with data to know what your customers are doing with your product. Don’t fly blind.
- Find ways to get (unfiltered) customer feedback.
- Never lose sight of the business objective. No point building a great product that no one would pay for.
Also, you can check out this article from Product School on why software engineers make great product managers.