There’s more than what meets the eye here. And more than UX, Business, and Tech, that’s required to become a better Product Manager.
Few years ago, when I started my Product Management career, almost every Google search on, “What do PMs do?” or “What skills are required to be a good PM?” landed me on a Venn! This Venn:
The Venn diagram tells you Product Managers sit at the intersection of tech, design, and business. This Venn was a good insight into what I’d be required to do and learn. And so, rather frantically, I started hoarding books on each of these subjects and read up, if not less, 50 odd books in a span of less than a year.
It took a fair share of building products, shedding tears (literally), and a lot of tough days to learn that Product Management is much more than business, UX, and tech. In fact, business, UX, and tech are just a part of a product management job.
At its heart, PM-ing is a job of grit, of incessant patience, of constant emotional battles, and still being happy!
After spending close to four years in the product management industry, building and collaborating on some super successful products with some of the brightest minds in the country, I collected a lot of learnings along the way. All of these come from sheer experience of making mistakes, failing, and getting “I wish I handled it better” thought at the end of the work day. And now knowing what that better looks like.
Here goes:
Weird, you might say? PMs can’t be sad? Does it mean we have to constantly be happy? And how does it even matter?
A typical day in the life of a PM is not about sitting in a corner of the bay and silently, thoughtfully, writing a Product Requirements Document. Instead, it’s a day full of constant nudges by (hoping you guessed it by now) UX, tech, and business folks. A typical day is a lot of meetings, conversations, a lot of alignment, and back-and-forth of ideas and objections.
PM-ing is the kind of sales job where the sales call never ends. Where every moment is show-time! It’s a job where in one single day, you’ll have to interact with tens of different stakeholders with different temperaments, personalities, motivations, and their varied needs and emotional states. How, then, can you afford to be sullen, gloomy, or not in your best, most excited self at any point of time? How then can you afford to be sad? How can you win any of those big and small sales meetings being all tired, exhausted, or anything but enthusiastic?
Happiness is the key, baby. Literally.
You’ll hear the opposite of this a lot — That the product is your baby. And that you have to care for it, and rear it, and love (and defend) it like your own. The reason cited is that you have to give it selfless love, 24X7 unbiased attention, and blood and sweat — just the way you’d do to your own baby.
That’s wrong! For not one, but two reasons.
First, have you ever considered murdering your own baby? Would you be okay with hearing criticism about your baby?
If not, then stop considering the product as your baby. It’s not. It’s a product. You have to work to make successful, and be totally emotionally detached. Least of all, have feelings for it like you’d have for your child.
Second, a child may require 24X7 attention, a product, for its own good, does not.
Sometimes, you have to shut off to be able to listen. Come out of the box, to be able to think outside it. And unplug yourself from the current state of affairs of the product to be able to find a blue ocean for it.
Product management is a journey of constant improvement of the product. It’s also the journey of abandoning bad ideas, bad products and features, and sometimes even sun-setting them when they’re not working as per expectations. Having feelings for your product makes you blind to all the criticism for your product. Sometimes, it may also make you defensive, and unable to take feedback or the voice of the user in the right spirit. And all of that is the recipe for bad product management.
So, today, for your own good and the product’s good, look at the product as what it is — a business to solve a customer need.
While in one of the previous points I compare product management to a sales job, the key differentiator here is that there’s no gratification at the end of the work day. The sales pitch is made, the sale is done, but there’s no ringing of coins in the background.
That sales call you just made is not going to end in a deal today, tomorrow, or even six months later.
A product is not a sales deal, or a contract, or few lines of code, or a design. It’s a journey.
A journey that keeps going on, and on, and on. And do you know the worst of it all? You didn’t make that contract, you didn’t market it, you didn’t write that piece of code, and you didn’t design it (in most conventional PM jobs) and hence the feeling of gratification of having finished something at the end of the work day, is rare to come by. Very rare!
Yet, you’ll constantly be making improvements, iterations, generating insights, optimisations, and taking the right decisions at each point — it’s a never-ending cycle!
Product Management requires incessant patience to see things through. To keep learning and to keep iterating. And to get to the results, which then again, become the starting point of another set of optimisations.
So if you’re looking for immediate kicks, maybe this is not the right stream for you.
Side note: Getting too patient is bad as well. As a PM, one must also exhibit a strong bias for action and be impatient enough to get your products out of the door sooner.
Too many conflicting ideas? Who said it was going to be easy?
As a PM, you’re typically expected to come up with radically good ideas to solve user problems which are better than existing solutions by a delta of at least 4X. In this journey, you’re required to do a lot of research on the problem statement, on who you’re solving this problem for, how big the problem is, and what are the existing set of solutions for the problem.
Also, in this journey, many PMs tend to build a hypothesis along the way on what the plausible solutions could be. Once done, they try to back it up with more research on how well the particular solution could solve the user problem. And in that process, documents are put together, product hypothesis are created, a vision is written down, and some impact analysis is done.
Good going so far! Once at this stage, after having spent weeks (or maybe months) trying to find a solution to a problem statement, it is but human to get attached to your solution. And that’s where the problem starts. Once they are attached to a solution, PMs tend to start seeking validation of their thought process from everyone around, rather than finding the truth. Investment in the idea leads to attachment, and attachment leads to your defence mechanism kicking in — absolutely human!
In times like this, here’s what I do — rather than going around asking if something will work, ask people to tell you three reasons where your idea could fail. Don’t settle for less, ask for three sharp reasons. Once you do that, and talk to just 10 people, you’ll have 3X10 — that’s 30 perspectives different from yours to ponder and think on.
The catch here — use your best judgement still. Not all of these 30 perspectives are right, important, or immediately implementable. The idea of this exercise is only to make yourself okay to seek the truth, and not settle for validation.
This is the most important lesson of all. And possibly the shortest. I started with saying that the product management industry doesn’t care too much about the hard skills. This also means that the shiniest of Product Requirements Document, or the most valuable of insights generated don’t matter if the product doesn’t see the light of the day.
Early on in the game, I would get frustrated easy, and early. My excuse to myself (amazingly, all these years I have worked for bosses who trusted my judgement and gave me a lot of autonomy, and hence the phrase ‘my excuse to myself’) was, “but I have done my bit…”. I wrote the Product Requirements Document, I did customer interviews, I did all tech discussions, I did this, and I also did that… still the truth was, the product was not out.
As product managers, you’re really orchestrators of the entire show. You can’t do a part of the thing and sit and watch things from the fence.
You have to really be in it, to win it. This means, as product managers, there’s no bit you have to accomplish and move on in life from there. You’ve to sit through the entire process — help the engineer where she’s stuck, get enough insights to design a brilliant experience on, be the champion of the product to help marketing and sales understand the product better to do what they’re good at, better. Essentially, any loose end in the journey is your bit. And your bit, is large enough to not qualify as a ‘bit’.
Far too often, we fall in the ‘everyone is like us’ bias. We begin to believe that there are two types of people in the world — people who are like us, and people who are not like us. And everybody who is like us, obviously, thinks, operates, and behaves like us. Which means, if I have this problem, everyone else, who I think is like me, also has the problem. And the problem is so big, and so widespread, it needs a solution. And the moment it is out, all you’ll hear is, “here, take my money! I had been waiting on pins and needles for this product to come out”.
Only, that doesn’t happen.
Philosophy aside, what the above means is that we start believing in a world where our problem is too big to have a business value to it. We start solving our own problems with so much passion that we never look up the tunnel and right size the market. We don’t look around to see if solutions, which we maybe are not aware of, exist! And maybe do a better job than our hypothesis.
And since it’s our own problem, we mistakenly also tend to believe we know all about the problem, and don’t need to hear from others if the problem really exists — going even deeper inside the tunnel.
Don’t do that — don’t build products for yourself. Come out of the tunnel, and do enough research on:
Side note: Facebook, one of the most successful products in the history of the digital era, came out of someone solving their own itch. But there was enough market for that itch and it was established fast and early. Know where to draw the line and do enough research.
Confession: I have done it far too many times.
Weeks of research, followed by weeks of execution, followed by weeks to prepping up to ship. And finally the date of launch is here — don’t we all deserve a breather? A celebration?
Of course, we do.
The only trouble is, many of us take this celebration far too seriously. We think it’s done. We think that the ‘happily ever after’ is here.
Much like we do in marriages? But when, in reality, the date of tying the knot is where the effort really starts. Much like marriages, the real test of your relationship with your product starts the day you start sharing real space — the idea is no more that, it’s a real product, sometimes with shape and form.
Once your product is out there in public, is when you know what all those months of research and effort really meant. Whether your initial hypothesis of the solution fares well with your customer base or not. Whether all the talking you did is even going to get some moolah in the bank. The launch is actually the beginning of some serious work.
And hence, even though it’s okay to scream and shout and feel awesome about your launch, the time to celebrate is when the first customer has used your product, when the first pay cheque lands in the bank, and when many more customers use the product, and many more pay cheques land in the bank!
Time to celebrate is when the hypothesis has worked and your product struck a market fit. And time to celebrate is when your customers become your marketers and salespeople.
Side note: Celebrations are good. Celebrations for milestones are also good. But know what message you’re giving away in the celebration — whether it is, we achieved it, and we’re done OR whether it is, we’re calling cheers to a new chapter!
If you want to find out more about how Waydev can help you, schedule a demo.
Ready to improve your teams' performance?
