3 Types of Product Management: Which One is Right For Your Company?
Firstly, what is Product Management?
It’s oddly hard to get a straight answer to this question. Let alone a succinct one.
The most common explanation looks like this one:
If someone asked you, “What is the Statue of Liberty?” would you answer, “It’s between Manhattan, Jersey City, and Governor’s Island?”
This kind of information is orienting but incomplete. What does a product manager actually do?
Don’t worry, no one knows
At Google, the unspoken ambiguity always felt like a running inside joke. A typical reaction to the unsuspecting inquiry would start with a snicker and follow with a rehearsed, vague answer such as, “we get things done.”
The amorphous nature of the role permeates outside the Googleplex, as well. In my first “real” software job, far from Silicon Valley at Partners HealthCare in Boston, we developers would often joke about not knowing what our PM was meant to be doing (and it often seemed like she didn’t know what we were doing either).
“The ambiguity of the product management role is near to its essence,” writes product manager Dan Schmidt in The Product Management Triangle, “Within one company, the duties of a product manager can change drastically and quickly.”
BCG consultant Yves Morieux argues that modern corporate managers hamper productivity by overusing “measurability, accountability, and clarity” when architecting their organizations. He claims we optimize for knowing whom to blame when we fail, and consequently we miss out on opportunities to succeed with cooperation.
Are product managers the tech sector’s answer to Yves? If so, might a hardened definition problematically dry out the “glue” that we intended to apply in the gaps between other rigid functions?
Types of glue
Rather than desiccate our PM glue, let’s pick a type.
In the physical world we have white glue, wood glue, glue sticks, super glue, and the list goes on. All of them stick things together, but they also have very different functions. Pick the wrong kind and your birdhouse will crumble in the rain, and your first-grader will end up in the nurse’s office.
What kind of product management do we need?
It’s an important question that will dictate:
- How to source and vet a PM team
- What responsibilities to give them
- How to assess their performance
- What other functions will be needed to complement them
At early start-ups, the responsibilities of “the product person” (start-ups rarely have “product managers”) might hinge entirely on what other resources happen to be at the company. For instance, many early technical teams without a designer will rely on the PM to sketch the user interface.
However, scaling a PM team inside a growing organization involves thinking longer term. Managers must make big, enduring trade-offs between differing sets of skills, knowledge, and experience. The question becomes, “What function does product management have after numerous teams, such as Design, FP&A, and Business Development, are added to fill the large gaps that initially existed?”
Dan Schmidt, Quora’s most viewed writer in Product Management, suggests that product managers ultimately stitch together these various planks at their overlapping intersections inside his triangular “Product Network,” shown below:
The problem is that not all these planks stick together the same way. Each requires a different blend of capabilities, working styles, and core values. A scant few product managers can rotate personalities so seamlessly that they fill every of these spaces with uniform tact and mastery. (And if you do meet such a unicorn, send them my way!)
Much more prevalent are PMs with biases and imbalances that yield greater strength in some areas, and less capability in others. Let’s use the visual model as a basis for understanding some of the more common inclinations.
Triangle #1: The User-First Product Manager
Many of the PMs with this bent come from a design background, such as a UX position, or a design consultancy like IDEO. Their methods likely trend in the direction of wireframing, focus grouping, and crowdsourcing.
My experience is that they demonstrate a penchant for:
- Speed - why is this so slow?
- Data re-use - does the user really have to fill this out a second time?
- Bug fixes - we can’t let users end up with that obscure error message!
- Comprehension - does a 1–7 score really help the user understand this?
- User requests - everyone we surveyed asked for more email reminders…
This type of approach makes the most sense in domains that are technologically “solved problems” and leave little room for business model innovation. In my mind, task management comes to mind as a canonical example (though the performance issues we experienced with Asana may prove there is more technological challenge under the hood than one might expect). Another example might be most education technologies, which primarily use computing technology as a content delivery platform. A last example might be chat applications like Slack.
Triangle #2: The Business-First Product Manager
The PMs I have met with this tendency often come from an MBA program or a general management position (including founding a start-up). You would be hard pressed to find one whose preferred methods do not involve a spreadsheet, whether for a cost-benefit analysis or a Gantt chart.
I find these folks tend to push for:
- Profits - we can charge 20% more for this new feature!
- Competitive features - every other company offers free shipping!
- Biz dev opportunities - we can integrate all these APIs to get more data!
- Growth - let’s find a way to improve homepage conversion
- Investor requests - Paul Graham wants to talk after we’ve automated this process
This sort of approach makes the most sense in domains ripe for business model innovation, built on a foundation of familiar experiences and commodity technologies. Concepts like Wunwun come to mind. If they had achieved their goal of free delivery of local goods, paid for by creative partnerships with merchants and manufacturers, then users would have put up with a buggy, unintuitive, or unexciting app for the same reason they put up with long lines at IKEA: they want what you’re offering, and you’re the only one who’s got it.
Triangle #3: The Technology-First Product Manager
These PMs typically come from technical backgrounds, such as software engineering jobs or computer science programs. They lean toward prototyping, task management, and workflow diagrams.
I find these folks tend to push for:
- De-scoping a launch - can we just give an error in that case?
- Feature re-use - can we use hashtags in the notes field instead of adding a new field for labels?
- Minimizing obsoleted work - let’s not fix this bug since the system is being replaced next month anyway…
- Extensibility - by adding this feature, we can work with both cameras and scanners in the future!
- Consistency with technical semantics - we can’t call this field “school” if it could one day contain peer-to-peer education programs
“Technology first” works best when the user experience is simple, and the business model is already proven elsewhere. Most of Google’s successful products work this way. You literally cannot find an interface simpler than a search box, and the business of showing ads based on your search intent was already well-established when Google entered the market.
Beware changing needs
If one learns nothing else from The Innovator’s Dilemma, it must be that the most important dimensions of performance within a product category will change over time. Canonically, hard drive capacity mattered more than physical size up until the time that capacity reached a certain maximum usefulness.
This critical rule applies as much to hard drive performance as to the balance between our three product perspectives. GMail serves as an interesting example wherein technology-focused product management led to game-changing features (huge storage capacity, and high quality search) in a familiar interface (similar to any other webmail at launch), and with a traditional internet business model (grow the userbase and monetize later). As infrastructural competitors like iCloud and Hotmail caught up, the shift in economic performance moved away from technology and toward design, as indicated by the success of products like Mailbox (acquired by Dropbox).
In summary
What good product managers do, and where to find them, varies greatly depending on your product strategy, which itself is subject to change over time. Despite all of their differences, good product managers somewhat amorphously bridge the gaps that exist between other functional areas working toward a product’s success.
Coming up
In future posts, we will review the charter of the Product Management team here at Earnest. We will go into some depth about how we currently view our role in the company, what skills we look for, how we measure our performance, how we work with other teams, and what lessons we are learning from our mistakes. See you next week!
Daniel leads Product Management at Earnest. Prior, he was a Product Manager at Google and an alumnus of their Associate Product Manager program. Daniel holds a bachelor’s degree in Computer Science from Harvard University and loves flying airplanes.
Earnest is a San Francisco-based technology company building a modern bank for the next generation. Our Product Management team is a nascent group of technical, entrepreneurial, jacks and jills of all trades, and we are actively hiring!
