The Paradox(es) of Product Management
On Friday, 28 August, at 10pm local time, while most other Malaysians were either unwinding for the weekend or getting ready for bed, I started my talk for World of Webinar.
I had been invited by Sumit Kumar Singh to do a talk for World of Webinar, and given that it was for their WOW Originals series, I decided to do prepare a new topic (I don’t really enjoy rehashing my presentations so coming up with a new content is always motivating for me, but who knows, if I get famous, I might have to 😅 ?).
This session was recorded and is now available on YouTube and I have provided the link below but I have also decided to write an article about this for those who prefer the written medium, all pun intended.
The definition of paradox
We start by understanding the the definition of paradox, and the google definition still seemed quite wordy and a little hard to follow, so I’ve taken a stab at simplying it:
“A paradox is seemingly two opposing standpoints which are both true”
A popular paradox examples are like the famous saying “the only constant is change”. From a product management perspective, common paradoxes are like being “mini-CEOs without the power” or “successes from failures”.
Rather than addressing popular product paradoxes, I decided to share 5 paradoxes which I have faced as a product manager and leader in my career which I believe will be helpful for you to recognise and how to tackle them.
1. Data is great, until it isn’t
For product managers, data is king. But data is also a double edged sword. Too little data, and you’re making blind decisions. Too much data and you get into analysis paralysis.
So we must use the right data, at the right time, in the right way. I like the saying by Ronald Coase, who said that:
“If you torture data long enough, it will confess to anything”
There was a project that the product team implemented when we finally launched our new e-commerce platform, and I remember seeing disturbing data where conversion numbers were going down after launch. I was grilled on this, but the full story was found in data regarding average checkout amount. While conversion numbers were indeed down, it was actually in inverse to the average basket size for checkout, which had gone up since launch.
When it comes to data, we must also know when to use data and when we need to trust our product judgement. This is especially true when we’re innovating for the new vs incremental changes because there is usually little data for new products. I won’t go into the details but I would recommend you read Clayton Christensen’s “The Innovator’s Dilemma” to understand that sometimes in these situations, we may need to wait for user behaviour to change en mass or complementary technology to catchup for user behaviour to change.
2. Your job title says product, but your most valuable asset is people
Any product manager that doesn’t need to deal with people, be it customers or colleagues, will need some counseling 😅.
If you look at Martin Eriksson’s incredibly famous product manager Venn diagram, it shows product managers in the overlap between the circles of business, technology and user experience. What is the common denominator that you have to work with in all of those circles? People. When you’re trying to better understand user behaviour and you do user research, what is the most important element? People. When the deliverables for a project was well done, one of the key successful elements will definitely be how well the people in the team worked together.
So if you’re a product manager who thinks that you can get away with just writing kick ass requirements alone, you may want to reconsider. I once had a product manager in my team who was seemingly fantastic at the role but somehow the deliverables were frequently found wanting. It turns out that while this team member was incredibly meticulous in written form and writing specs, this person was not good at interacting with people, and a lot of assumptions were made when planning.
This is also why developing empathy is crucial and why I’m a big fan of having product managers listen in on customer calls. I had Mike Dickinson as a guest on The Product Un(censored) Show recently, and he said it really well when he said there is nothing like getting the first hand feeling of somebody filling your ear with rage that you understand what’s really going on.
3. To focus on delivering value, fix the process
This is a potentially controversial one, but hear me out. In my journey as a product leader, I’ve found that in order to consistently deliver value, usually what’s broken or not working well is actually the process.
Process seems to be a bad word especially for those who love the hustle culture of early stage startups. While it’s true that process takes a back seat to hustle when it’s a really small team trying to get product market fit, you will eventually need to embrace this as a necessity as the organisation scales. The balancing act is to implement just enough to fix the issue while ensuring that all that is good like team autonomy and direct communication is not affected.
In one of my experiences as a product leader, I noticed how value delivery from the tech team was incomplete and disjointed. It was actually an engineering team issue, but I realised that it was imperative that this issue was addressed. So, I presented my observations and solution to the head of engineering and worked out a solution. We got buy in from the leadership and we ended up moving from being layer teams to full stack teams so that features that were delivered were fully functioning and not dependent on other teams.
But it’s not just managing downwards, it’s also managing upwards. In another incident, I noticed that the engineering was not able to deliver their sprint deliverables almost every sprint. Upon further observation, I noticed that there was constant last minute requests that came from the marketing team and going straight to developers. The quick win would be to make sure that all requests went through the product team, but there was a bigger issue where it was not clear to the other teams what the engineering teams were working on, so creating a quarterly planning sessions helped to not just bring visibility, but also cut down last minute requests.
4. You are a problem solver who won’t fix all problems
The product manager role has a lot to do with fixing problems. In fact, without problems to solve, it is likely that many of us would not have jobs! However, it is critical that we’re not trying to fix every single problem that we come across. I mentioned earlier about developing empathy for our users and customers, but we must be equally adept at prioritisation. If we continue to solve all the small problems raised by our customers, we do it at the expense of solving real problems for our customers.
The temptation is that these small problems are usually relatively easy to fix but they also tend to not be as high in value delivered — these low effort, low value endeavours are termed as feature snacking by Hunter Walk. Let me quote from an article from intercom:
“This work is easy to justify because “it only took 30 minutes”. And when it achieves nothing useful, it’s easy to excuse because it “took us so little time”. This is not strategy — this is flapping. Do this enough times and you’ll grow a low impact team that doesn’t achieve anything.”
I remember one of my former CEOs who would continuously send me messages and emails about all the issues that he found across the platform (ever notice how only CEOs tend to find all these really weird problems which we always seem to miss???). While he was always keen to emphasise that he was just passing on feedback, there would be a few bug bear issues that he would continually press on why work on it had not begun and when it would be done. I actually explained the dangers of feature snacking, but more importantly, I always kept the roadmap transparent on what was coming up next and whether he felt any of the upcoming initiatives was less valuable than the issues he was highlighting. We never changed anything on the the priority list.
5. Be stubborn and flexible
This final paradox is actually an adaptation of Jeff Bezos’ quote “be stubborn about the vision and be flexible about the details”. However, I modified it so that it would encompass the breadth of a product manager’s role and not just be narrowed to the vision.
As a product leader, there are things that I am extremely stubborn about, which are my principles and then there are things that I am flexible about which are secondary issues that do not relate to principles.
Personally, for me, there are a few principles that I will not compromise on such as: culture, autonomy and ethics.
I actually make it clear before I join a company that I care about those aspects within an organisation. There was once, I was pretty new in the organisation that I witnessed one of the top management yelling at one of the engineers over a call due to an issue. I stepped to understand the problem, make sure that we had a way forward and de-escalated the issue. That evening itself, I voiced my grave concern to the CEO that if this was kind of behaviour we tolerated as an organisation, it would be very hard for me to stay.
An example of an area I’m flexible about is ideas. I believe that great ideas can come from anywhere and anyone. So whenever someone comes to me with a new idea, rather than responding with a no, I respond with trying to understand these areas:
- what problem does it solve for the customer
- how big is the opportunity for the potential solution(s)
- how will the solution differentiate us from the competition
The video actually has an extended session of Q&A where I answer questions from the viewers, so do watch it if you’re interested .
I hope these paradoxes have been helpful for you, and if you do have any comments or feedback, do feel free to post them below.
Follow Product Un(censored) for more content relating to product and product management focusing on the South East Asian region.
Connect with Product Un(censored):
