Who is a product person, really?
I often spend a lot of time thinking about this question and still find myself shifting between the various over-lapping answers.
PM = Product Manager
What is this glorified term gaining so much popularity, a job description that is not software, not design, not business, not analytics, not marketing, not sales, and yet, is somehow all of these?
As product management gains a strong foothold in the technology industry, I find a lot of people early in the career migrating towards this holy grail of a job function. And rarely do they know what will follow.
New product managers often find themselves in a quandary on the job, and most of it has to do with romanticizing the notion of product. It gets much harder because more often than not, there’s no clear answer to what product and product management is. It is a lot of things, navigating the murky waters at the intersection of business, technology, and design, yet the actual execution varies for each company, the stage of the company and the background of the person.
Whether you are venturing into product management, or have been here for some time, or work with product managers, it always helps to gain a deeper understanding of what it actually entails.
What is product?
Product, as simply put by Wikipedia, is a system made available for consumer use; it is anything that can be offered to a market to satisfy the desire or need of a customer.
To quote Mike Cohn on the subject:
I define a product as something (physical or not) that is created through a process and that provides benefits to a market.
From that, a chair would be a product. Microsoft Office would be a product. Agile consulting services would be a product. A painting would be a product. A product can be a something physical (the chair). It can be a digital product (Microsoft Office, an ebook or streaming videos). It also can be a service (consulting on how to adopt agile).
A product can even just be an idea (a patentable algorithm or the secret to getting more right swipes on Tinder).
The secret recipe — The extra
I recently met an old friend and mentor, Mr. A, who has re-ventured into entrepreneurship.
He said,
“When people talk about being a Product person, they imply following something “more” or different than just writing software. They must be. That’s the only reason why they’d specify it so proudly that they’re product people.”
I like to think of that “extra” as the secret sauce, like Grandma’s secret recipe for your favorite dish.
You have all the ingredients and the steps to cook, yet the taste is not the same. What extra did she do? Maybe it was not the ingredients or the order of the steps, but that extra twirl of ladle she gave at the end that blended the spices in so wonderfully.
Each product that has worked really well, has had a secret recipe. More often than not, it is not just the patents or the algorithm or the growth hacks alone. It is a way of blending all those things in a way that works.
The understanding of the use-case, the whys, and whos, analysis of the whats and a process driven how. Rinse. Repeat.
Product is something that works, for the very purpose the consumer wants it to work. It is the secret recipe blending the idea and the technology and everything else that makes it edible and tasteful.
It is what its user makes it to be.
And the product person is someone who identifies this what and builds the entire narrative around it.
Clutter-free Facilitator
A while ago, Noah Weiss, having headed product at Google, Foursquare and now Slack, wrote this fantabulous piece on what product management is not. I have it bookmarked, and every time I am asked to clarify what product management is and is not, I read his article to clear my mind.
One statement from his post that stands out,
They should be the ultimate facilitator: pulling the best ideas from their team, coordinating with cross-functional partners, and getting executive context.
For me, this single phrase defines a product manager: Clutter-free facilitator.
As a product person, your extra is to facilitate the execution.
Perhaps there’s a reason for the popularity of this very popular Venn diagram, describing what exactly is a product manager.
You research, you guide, you analyze, you communicate and you manage. The result of your management is governed by the seamless cross-functional execution of other teams you intersect with.
Connecting the dots
A product manager’s job thus, at its core, is to connect all the dots.
What industry are we operating in? What does the market look like? What do we currently have? Is the consumer happy? Can I make them happier? How can I plug in the gaps?
In other words,
Business. Market Research. User Research. Competitive Landscape. Roadmap Planning. Product Design. Sprint planning. Launch. Measure. Usage Analysis. Iterate.
NOT Technical Manager
Time and again it has been debated whether a product manager should have a technical background. Or, vice-versa, whether a technical manager can be a good product manager.
To this point, my friend, Mr. A, further added,
“People specifically call out “product development” as a separate or unique activity. Notice I’m not using a term for the other activity. Is that software development? Is that app (or application) development? Is that something else?… When I was a student it was just software development. You could create a product, a utility or an app — it was all a part of software development. It’s the scope of the requirements that would change — quick and dirty utility with CL as UI or polished GUI product with user manuals and a tech support team OR maybe in some cases the customer of the activity that would change — sometimes internal and sometimes external. Any trained PM would know how to manage both extremes appropriately. So where I come from, that’s the super set. Or the universal set.
When did Product Development become a thing? What “extra” is brought to the table by a product person — above and beyond good old software development management skills that makes said product person special?”
It is a fine line between product and software management, or is it?
I believe neither product nor engineering is the super set. They’re peers.
Engineering lays out how to build the product right.
Product lays out the definition of the right product.
For a long time, just engineering management was enough to drive a product and the respective organization. However, as the consumer mindset evolved, so did the demand for far better experiential products, and thus, the requirement for a unique skill-set that is a thing on its own.
I think this critical distinction is also advocated by the onset and adaptation of design thinking, where, for an end-user, experience and context wins over the technical functionality. All the internet-eating-the-world-and-oh-so-many-memes-businesses have changed the very definition of user requirements.
Engineering Manager (Software Development Manager, Technical Product Manager, etc.) needs to understand the technology with its implementation details. Comprehensive knowledge of the available tools and technologies to build the software product.
Product Manager, on the other hand, needs to understand the technology as it relates to the business use-cases. A deep appreciation of the translation of business to design to technology.
Take a cab booking service for example.
Business goal: To provide the fastest cab-booking service possible.
Steps to execute: Figuring out whether it is going to be a function of design or technology (most likely both). Communicating the research to the respective teams. Testing the results. Improving on them.
One could argue that the engineering manager can possibly handle all the steps mentioned above, but here’s the thing — the introduction of multiple platforms, varying interfaces, and heavy user expectations, make it increasingly difficult for her/him to have an undeniably good handle on all the aspects, and get a flawless software product built all at the same time.
Step in Product Manager.
Perhaps if we look at who will get fired for what, the “head on the chopping block” perspective.
The Engineering Manager will face the fire if the product doesn’t do what it is supposed to do.
The Product Manager, on the other hand, will get fired if nobody uses the product, for whatever reasons.
Who is a product person, then, really?
A product person is someone who handles all this, every day, and comes out with a solution that works.
She / He is not the project manager.
She / He is not the analyst.
She / He is not the beta tester.
She / He is not the business consultant.
She / He is not the sales rep.
She / He is not the engineer.
She / He is not the designer.
She / He is not a specialist.
A product person is everything else, with eyes on the business, ears on the customer, and hands and words aiding everyone else to execute seamlessly on their respective turf.
This post is an understanding of product and product management drawn from personal experiences, and took a long time in making. If you liked what you read, a clap wouldn’t be so bad 😊 Drop in a hello on twitter @Nidhi Gurnani 👋🏼
