I’m going to try and answer different variations of this question and those that will inevitably follow upon introducing to your fellow colleagues.

What do Product Managers do at work? I mean, I see them talk, blog and tweet a lot.

Do Product Managers do marketing as well?

I see far more Economics graduates of big 5 companies into Product Management than CS majors.

Doesn’t it require technical skills?

There are plenty of resources online that tell you what Product Management means to different people based on if you are in the industry or not, if you know to code or not, the company you work for and more.

I’m going to spare you of needless analogies and cut to the truth. There is no fixed definition.

If you’d like to read a simpler version that answers all the above questions, scroll to the last section of this blog. Those are words from my CEO and mentor who is referred in the SaaS circles as the bootstrapped buddhist.

Going purely by job descriptions I see on LinkedIn, Program Managers at Amazon are usually non-technical folks focussed on delivery of a project. Whereas, Product Managers are the ones who have a fair degree of understanding or curiosity of software architecture, users, use cases and the market. Nonetheless, a degree in MBA is sometimes a pre-requisite for these two roles in many teams at Amazon.

Several teams at Google, Twitter and Facebook expect you to know enough coding or come from strong CS backgrounds.

In many sales-first or marketing-first product companies with strong engineering teams, PMs are essentially front-end/ usability designers who don’t necessarily have had hands-on experience building a product. These are people who are closest to the customers and have deep knowledge on how several industries work.

By and large, the definition and responsibilities vary across tech companies. So you will come across many professionals in this field who play to their strengths.

But what’s important is if this is something you’re comfortable working in the long run. And if you do, it matters if others around you are comfortable working with you.

Before that you need to remember the hard realities of this role.

The hard realities of thinking hard

In short, you’re paid to think.

You are responsible for a lot of things, especially big fuck-ups. You need to be mentally prepared to be the scape goat-in-chief when something goes haywire. You will be the go-to sponge for every possible disagreement from design, engineering and product teams. However, you will most likely have no direct authority on anything. So please don’t reckon yourself as a CEO. You are probably one without any authority.

How does my day look like you ask?

One quality thought at a time

I call it a day at work if I come up with one nice nugget of info to work on or got buy-ins for a small feature I thought of or if I agree to revisit the scope of a module or surveyed a few customers.

That doesn’t mean I say “Eureka!” and head home.

You decide your own homework

I stay back at work into late nights to present features to partners and stakeholders in different timezones. I spend inordinate hours crawling the internet. I define my own learning and don’t feel shy to ask for help. Some of best learnings come from developers and designers. I learn to query and use logs, learn a bit about the tools devs use and things they often have to work on say like micro-services and APIs. I sign up and try out different products for fun. No one compels me into doing these. Some of it is an exercise I take up to empathise more working with developers. Some to learn about new markets. Some to just connect the dots in the most undisciplined way.

The market is your god

I’ve built modules that never saw the light for unforeseen reasons. The market threw a curveball at us like a sudden change in access to third-party APIs. Personally, it felt like a disaster since the sunk costs were pretty high. I felt as though I had let down the designers and developers who put their heart and soul into it. Most importantly, I had promised customers on those modules every single day. I had let down a whole bunch of people because the market was such. But on reflection, it is the best decision for an API-based product to survive in fluctuating market conditions.

Embrace ambiguity

I survive short stretches of utter ambiguity that could have tipped me into an existential crisis of sorts. Like the days your team is working to fix the technical debt and isn’t ready to take up something new. Those are the days you’ll see me be way more active on Twitter or on internal platforms like Zoho Connect. Those are especially the days you are your most vulnerable self if you are new to the role. Those are the days you shouldn’t give two hoots about naysayers. The best way to cope with ambiguity is to learn something out of your zone.

You’ll never know. It could help you tomorrow.

Speaking of which, check out this insanely funny comics strip on Product Management from Shipping Tomorrow.

Empathy and humility are your superpowers

What often matters the most in making the web a better place will never win a Turing Award: Empathy and humility. When you have a high capacity to empathise with problems, you’ll automatically be tuned to learn a lot. That could give you a false sense of knowing all the details. That’s how stories of most fuck-ups begin. Having a lot of humility never hurts.

Importance of having technical knowledge:

A year ago, I quizzed an acquaintance and caught him red-handed at his own bluff. He causally used the word Hadoop in a conversation that really did not require it. I was shocked he had the audacity to use a word he had no idea of. Although it spoke volumes about him, it taught me an important lesson: Learn to detect bullshit.

When you have sufficient awareness about technology, not many can bullshit you. When you feign ignorance, you can find out who bullshits you. This is one of the many reasons why I pay attention to the progress in the underlying technology as much to the market.

I started learning details of what developers do in order to empathise well, make good estimates of difficulty and set expectations for delivery. I’m grateful to the Engineering Lead Nareshram at Zoho for being my mini Stack Overflow at work.

Data is your middle name

When you’re paid to think, you mentally start working right from the moment you step outside your home. It’s not like you’ll need a comfortable spot to start writing. It’s not about that Dribbble post to find your next design inspiration. And when you run into some gaps in your thinking, no one can help you other than data. You’re someone who is comfortable using data to get over product manager’s block.

You’re someone who is comfortable using data to get over product manager’s block.

Knowing to ask good questions is one thing. Knowing how to ask that to a machine is another thing. If you can do both, you won’t be a pain in the ass for others. One of the reasons I learnt querying languages.

Many articles online downplay these scenarios. That paints a wrong picture about the job. Although it’s exciting to be working at the intersection of many fields, that’s the biggest challenge you’ll be dealing with.

Alright. Diving straight to my answer.

What is Product Management?

As adults, we grow to have a framework that helps us navigate life. We usually don’t recognise it for what it is. This framework is our deeply held values + facts about the world + our notions of how things work (opinions) + our biases. This is show we make our day-to-day decisions.

Here are sample frameworks people use to make decisions:

Values	Facts	Opinions	Actions and Biases
I value the work of writers and journalists.	Facebook and Google have inadvertently made it difficult for digital publishers to earn substantial revenue.	The web needs an alternate way to sustain publishing high-quality content.	I prefer reading NYTimes over Washington Post.
I value men with good communication skills and hobbies.	Mr. M studied Economics and is currently a software developer and guitarist.	He seems to be an interesting person. Love his way with words and music.	Too bad he isn’t as tall as I am.
I respect people’s boundaries.	I’m not invited to Ron’s party many of my friends are attending. I don’t know if this is intentional.	OK. Maybe they don’t like me.	Ron has always been rude to me. So I’m not going to invite him either.
Customer is the king.	5 enterprise customers have asked for this feature. Involves redesigning DB. No resources available at work.	Providing this will increase account renewals by at least 20%	Since the team is busy with other priorities, we’ll have to push this to the back burner.
It’s important to get things done on time.	The designer is not at work and I don’t know when he’ll be back. He’s not been online for 2 days.	This is a top priority project that might get delayed by a couple of days.	I’ll drop him an e-mail cc-ing his manager.
Don’t tolerate brilliant jerks.	What? No replies from him yet. We’ll definitely be late to launch.	He’s taking it too lightly I suppose. Or, he perhaps fled the country.	Will give him the benefit of doubt but I’ll reconsider involving him in future projects.

Decision Making Models and Product Management

Values, facts, opinions, biases are building blocks of decisions. In the real world, there is a slim chance they share a linear relationship.

In many examples above, note how the actions directly contradict the values one personally holds. Although Clara values people with good communication skills, she values physical compatibility over mental. She’ll probably revise this through her future experiences.

Biases, that are often looked down upon, are in fact safety nets in a few scenarios. John is biased to think that Ron is rude with him although he does not really know why he wasn’t invited to his party. He takes offence like a piece of cake and misses the party only to learn the next day that there was a deadly gunfire. Given he’s prone to correlate without knowing the cause, this event could make him be more wary of parties in the future.

Loosely held opinions look like facts once you start seeing corroborating events happen often. So it’s important to acknowledge you do not know all the facts and that you don’t know what you don’t know yet. I know that Dick has been away from work for a while but I don’t jump into conclusions that he’s arrogant. That’s because I don’t know why he has disappeared from work. I give him the benefit of doubt that something horrible has happened to him.

You see that many of these scenarios are dealt differently. We don’t always give the same weightage for each of these building blocks. This is often a case in product management. You are battling trade-offs on a daily basis between requirements and people you work with. So you ought to employ a whole range of decision making models. Here’s how I classify decisions:

Rational decisions: Based on company values, facts at hand and outcomes of past decisions.

Intuitive decisions: Based on opinions, biases and outcomes of past decisions.

Incentive-based decisions: Based on values that protect the integrity of company narrative and positive outcomes of past decisions.

Emotional decisions: Based on opinions, biases despite negative outcomes in the past decisions.

Product Management is all about fine tuning these decision making models. When do you use what and how. Preparation for this role is a life-long job. And that’s a tough one.

Even the smartest people and companies you know have made bad decisions in the past. This is to let you know that you need not always be right at this job.

Gawker’s demise due to publishing a private tape of Hulk Hogan.

NASA ignoring warnings of the Challenger disaster.

Intel Inside campaign success and decision to not replace chips.

….and many more.

One of the best ways to prepare for this job is to read as much as you can about history, prepare for the future and practice different decision making models. Of course, people would ask you to prepare for interviews in a certain way but that is only going to test your interview taking skills. You’ll be ill-equipped for the job with just that.

Here’s a bunch of sites I love reading and try applying the ideas at work and life:

Farnam Street

Mark Manson

Paul Graham Essays

Collaborative Fund

Silicon Valley Product Group

Tomasz Tunguz

Have more recommendations for this list? Do add them as comments.

As promised, here are important points on product management from an industry veteran:

https://twitter.com/vandana_guru/status/939417702753435648