Visualising Product Management
For the visual thinkers out there, a mental picture on how product management works
After 15 years in product management — reading the books and blogs, listening to the podcasts, and, very importantly, practicing it — I have settled on a mental model how product management works best.
Below are some key learnings from those 15 years, in both theory and practice. My aim is to gain (and hopefully impart) a deeper understanding of Product Management.
Mental Models
How we think about subjects impacts how we act on them, what we feel is possible and what isn’t, what we choose to fight for, how we communicate about them, etc. I can talk a lot about the importance of soft skills, how to build a product strategy, or balance various forms of product debt, but without unifying context these become disjointed and prone to be forgotten. So first, I’d like to set solid context that will helps us think about product management holistically.
I see product management as the connection between the problem space and solution space, between the discovery and delivery, between an external world and an inside-the-doors world. No big surprises, I’m sure, but my point is that this happens in both directions simultaneously, using context as a currency. I like to picture it in my mind as two spinning gears, with product management as the chain linking them (which is sooo much nicer than thinking of PMs as a greasing agent).
External world
This is where both the customers and “the business” sit. Understanding it requires the PM to understand the users and the problems they face. It’s not just the immediate problem they face, but the context in which they operate (“I need a video editor — that works at the bottom on a mine, in poor light and no connection”, or “I need document analysis — about a petabyte’s worth before next Monday’s court session”).
At the same time, it requires the PM to understand their own company. Which are the markets we can operate in? How can we get our solutions to the hands of users? What is the legal and regulatory landscape, the competition? A “product” isn’t what engineering builds. A product is a vehicle of value exchange, and you need to understand what your business can deliver and capture effectively. (“Your SaaS platform for banks is useful, but here at the national police we just don’t support external hosting”, or “we’ve always marketed directly to teams, but you’re suggesting selling to C-suite and we’d need to hire salespeople”).
It’s the PM’s job to bring all this content back inside the doors to the people who design, build, and deliver solutions. It’s this context that allows you to prioritise the problems to work on, as well as do a quick vet of which solutions would be fit for purpose (“I understand why storing the users’ details in our existing DB would make technical sense, but half our users are in the EU and it’ll make a GDPR nightmare”).
Internal world
This is where the designers and engineers sit, but also the SREs, tech-support, CSMs, accounting, the legal department, and anyone else involved in building, delivering, and capturing the value (in the shape of the product) to the customer. There is definitely some overlap, hence why I put “the business” on both wheels. There is work across the whole company in getting things from engineering out the door and to the hands of customers. All people along the way need to be aligned, and that’s again where context is key.
After you have brought the users’, customers’, and business context to engineering and helped cull the blatantly inappropriate solutions, you need to guide the rest of the business into delivering these to customers. That means briefing sales, pre-sales, support, marketing, accounting et al about the new value propositions, features, pricing, and a gazillion other considerations. It’s contributing to messaging and technical demos, it’s ensuring there’s an SKU in the system for billing and demo systems available. Sometimes it’s even running those first demos and deployments to hand-hold the field people.
Dual-track
We tend to think of running through this as if we’re running on a race track. We start at the discovery gate round the corner of the dev end, put a sprint through marketing, and hit the finish circling the customer. We validate assumptions about pain and value, and then build and test to refine. The double diamond of design thinking — diverge and converge in stages. But in reality, outside of the zero-to-one stage, as soon as you have a product in the market this is a chain that moves all along the track at the same time. You’re delivering the previous release even as the engineers are working on the next set of features and customer feedback is dripping in and indicating future directions.
It’s why product managers need to learn time- and information-management. There is a constant flow of information, continual context-switching. You need to jump from one session to the next without pause, prioritising what’s currently most important and impactful, and protecting some deep-thinking, creative time.
Career entry points
Many budding product managers start as Scrum POs or APMs, where it feels like your responsibility is to keep Jira happy, the devs working, and the releases flowing. This isn’t necessarily a ‘feature factory’ — more likely, at the start of your career you can’t see the whole picture, all the moving parts. It’s easier to focus on the delivery aspect, and as you learn to work with customers and the business, gauge the impact of your latest software drop, you learn the basics of discovery and the domain in which the business operates. As you gain experience (read, battle scars), your horizon broadens and you can take on more and more responsibilities, contribute to problem discovery and leadership.
Discovery: Problem vs Solution
Speaking of discovery, there’s a lot being said these days about the importance of discovering the users’ context and selecting the right problem to work on. This is valid, but it’s not the whole picture. Think back on the Kano Model of attractiveness of features. Sometimes the problem is known, it’s simply your right to play (eg almost every enterprise software will need to integrate with Microsoft Active Directory for IAM, because most of your customers will be using it; nobody gets excited about it, but if you don’t have it you can’t close the sale).
Other times there is a known problem, and it’s just a novel solution. You know what the customer wants done, it’s the details of implementation that make a difference. I once built a product that was a late entry to a saturated market, and still knocked the competitors out of the market and achieved top market share — just by being a better mouse-trap, as it were. It was by understanding where the all the current solutions were sub-optimal and providing users with a (much ;-) better implementation, not by ‘radically shifting paradigms’ into a ‘new way of thinking’.
Going back to the mental model, we know 80% of ideas (more or less) will fail. But “ideas” isn’t limited to customer problems / opportunities (I’m old fashioned and cynical, I think of them as problems). An idea is also whether the proposed solution works. An idea could be a tweak. An idea could be a seemingly unrelated adjacent product, where combining them is suddenly 1 + 1 = 3.
My point is that as you deliver, you discover. As you deliver sub-optimal solutions, you gather enough data about what might be better. That could be a better increment, or a radical shift. And often, in order to test your hypotheses and validate assumptions, you need to deliver something. That’s why I say the chain moves together, in both directions at once around the wheels. How much you can see of it, of the worlds around the cogs, will increase with experience, with deeper understanding.
And so your number one task is to gather context and spread it around. Bring the context of the user and the business to the solution engineering part, and take the context of the product features out to market. Learn qualitatively and quantitatively at each step of the way, to keep the loop going. It’s why 90% of product management is communications, and why it’s a full-time job in itself.
I hope this foray into how I picture product management in my head helps you understand the bigger picture too, helps you make sense of how your tasks fit into a bigger picture and how you can grow in your craft.
I’d love to hear from you! Do you have a different mental model? Do you disagree with anything? How do you think about the complex world of product management?