The Machine that builds the Machine - Part 1
Some companies are born with product management, some achieve product management, and some have product management thrust upon them. Avoid accidentally stumbling into it.
I used to host the Product session at Plaid’s New Hire Onboarding, and my starting slide was this:
All except one of these panels show an aspect of reality. Which one is fiction is left as an exercise for you! It was fun having the new hire class try to guess this live, and there was rarely consensus — which should tell you a lot about product management.
Ask 10 product managers what Product Management is and you will get 11 answers. This is actually fine! Every company should mold the PM function based on what it needs. Unfortunately, most companies stumble into product management and have to live with the accidental choices.
There is an underlying commonality across all the incarnations of product management — a genetic code, if you will, based on which you can … create life anew. I mean, humans even share 44% of our DNA with a banana. (And that’s the last you’ll hear of this over-extended metaphor!)
Here are the foundational tenets based on which you can shape the function to suit your company:
Product Management is about taking the art that resulted in a 0-1 product and converting it into a science to evolve the product 1-100.
A corollary to the above is that 0-1 product initiatives should not lie within established product processes.
Product Management is a “glue” role between functions.
It can be split up into “Product” (what to build) and “Management” (how to scale the build-ship-iterate process).
The role is a dichotomy of leading and sweating the details.
Let’s dive into each of these.
1/ The science of building
The ultimate north star of product management is taking the esoteric craft that resulted in finding product-market fit and converting it into a science to grow and evolve that product. It is not formulaic, but it can be methodical.
Every tech product company starts out with the founders wandering the idea maze until they find product-market fit. This is the 0-1 stage. After this, it is off to the races, and growing the product and building a successful business around it needs the following:
Expansion of product market fit: you’ve had success with a “beachhead” feature and you need to build around it to really solve that one customer problem well, and later, also solve adjacent problems.
Growth through product efforts (consumer growth or PLG for SaaS)
Enabling functional experts to contribute in parallel to different parts of the core product.
How you decide what to build and how you build / ship it needs to be repeatable and scalable. Even as individual PMs work on their own areas of the product, the product leaders need to make sure they are building the machine that builds the machine.
2/ The 0-1 exception
For 0-1 products, there is no formula or science that can be applied. If there was… 🙂
When companies with one successful product embark on creating the next new product, the first mistake they make is trying to leverage the machinery meant for 1-10 or 10-100 products to help create the 0-1. They have forgotten what the first 0-1 took.
It is impossible to “product manage” your way into finding product-market fit.
One of the most important decisions a Head of Product can make is when to insulate teams from the regular product rituals. They need to give 0-1 teams the space to break rules, be creative and experiment, not require them to write status updates or calculate ROI or draft strategy docs. Let them “fuck around and find out”, as the kids say.
3/ A “glue” role
Look at all the different functions that can be involved in building and launching a product: engineering, design, data science, user research, product marketing, growth marketing, brand, comms, legal, compliance, bizops, sales, account management, customer support, partnerships, solutions engineering, developer relations… (what else am I missing?)
Product management needs to be the glue between these functions. Being “glue” typically involves:
Knowing how each area of expertise contributes, when to bring them in, when there are gaps, and helping each function contribute effectively and efficiently.
Helping make tradeoffs between different areas, when needed
Being a central point of co-ordination and a translation layer as each function often speaks in their own language — this is more than just project management.
Most importantly for growing startups where rarely are all these functions fully staffed — fill in the gaps where needed (do it, or figure out how to get it done!).
It is much more than project management and stakeholder management. This is a great post on “glue” from an engineering lens: https://noidea.dog/glue
A common pitfall is thinking of PM as yet another leg of a multi-legged stool. In reality, PM needs to be the function that holds all the other legs together. This becomes important as you draw lines between functions and decide who to hire into the role.
4/ “Product” + “Management”
Product: what we build
A good test of good product management is whether the people at a company — collectively and individually — know the answer to the question of what should they build next. This comes from a solid understanding of the “why”.
The most important leverage PM brings is clarifying the inputs to that question — who are the customers, what is important to them, what is important to the business and what are the desired outcomes (on the path from here to the ultimate vision). Often, this takes the shape of a product strategy, and needs to be laid out both on different time horizons and at different levels of altitude.
In terms of defining the actual product solution, the only right answer to what role product management plays is “it depends”. Sometimes PMs are the facilitator, some times the editor, and some times they need to be prescriptive. It really depends on the business, the kind of product, other functions and expertise involved and the rest of the team involved.
Management: how we build
Everyone wants to “do strategy”. Hardly anyone cares about the unsexy work of building operational excellence. Yet, the latter does most of the heavy lifting in creating successful outcomes.
It is easy to trivialize operational excellence as “project management” or “stakeholder alignment”. But it is much more.
A high-functioning organization should be thinking about:
Their operating cadence: not just how they plan (which is project management) but how fast they ship, how they learn and iterate and pivot.
Their system of insights: from customers, from objective data, from the market, from available competitive intelligence. How these are collected and combined together and used.
A system of prioritization: At the lowest level, this is about which items make it into a task list. At higher levels, it is about knowing how different efforts tie into company goals. It is also about being able to make high-beta bets and work on multiple things in parallel (or create extreme focus when needed).
A system of accountability: How do teams track progress, measure success or failure, and keep themselves accountable.
Comms, both internal and external: Internally, this ranges from information your team needs to know to representing your team’s work and objectives to the rest of the company. Externally, it ranges from copy in the product to building the product narrative through events and press (usually falls on Product Marketing or Comms).
Building operational excellence is shared responsibility between the different functions involved in the product, and hence often becomes the ball that Product leaders let drop. Delegate if you need to, but know that a lack of operational (execution) excellence will prevent even the best product strategy from succeeding.
5/ The dichotomy: 10,000 feet <> 10 inches
One of the unique strengths of high-performing product managers is how quickly and smoothly they are able to switch between the “10,000 feet” mode (leadership, strategy, etc) and the “10 inches” mode (combing through data, knowing all the edge cases, customer insights, doing QA when needed, etc.).
Leading @ 10,000 feet:
Product management is a leadership role: not necessarily of managing other people, but of being accountable for their collective output and everything that that entails, of directing effort, of underwriting decisions and making tradeoffs.
In most roles, you can start at the ground floor — a proficiency level of, say, 1 and work yourself up to a 10. However, in an explicit leadership role, you need to start at a 5 or a 6, and work up from there. The ability to lead people is one of two or three most important inputs into the ability to execute.
Sweating the details @ 10 inches:
At the same time, your PM team needs to be able to dive into the details of any product problem at hand. This does not mean they do the work of other functional experts but they should be able to sweat the important details. It allows them to work across (or make hard tradeoffs between) separate areas.
The biggest implication of this inherent dichotomy is in who you hire into the role and what the rest of the org relies on PMs to do. It is also why you see founders gravitate towards product management in large orgs.
To conclude: Building the product management function is like building the machine that builds the machine. Know upfront what you would like product management to look like at scale, and convert that into proactive hiring choices and role definition early on. What your early PMs excel at and where they add leverage (or not) to the rest of the team implicitly becomes your product culture later on.