Almost three years ago, I made the transition from development to product management. I had met a few product managers working for online companies in the Czech Republic before that, but I never understood how their role was actually useful to a company. So, it was quite weird that it was me starting a product department at Mews. Or was it?
I stepped into product management after reading Marty Cagan’s Inspired. My notion of product managers significantly shifted through that; but also, I started seeing how different people in our company had taken parts of the role of a product manager onto themselves, without explicitly knowing so.
Back then, it was mainly Matt, our CEO, giving us context and helping us understand what to build next. Vividly, I remember him telling us what to build and us engineers asking him questions like “Why?” and, “What’s the problem you’re trying to solve?” As we were growing rapidly, we saw the need to replace Matt in that function to be able to scale, but also, for Matt to have time to be the CEO.
As a first step, our CTO, Honza, and I took the development team and the design team and transformed them into multiple cross-functional teams, assigning them different parts of our product surface. We split the teams and the product around different types of end users.
Quite quickly, I, myself, became the bottleneck. As a fresh Head of Product, I was a people manager, but also the only product manager (while catching up with financials and a lot of context and customer knowledge). So, I started hiring for product managers immediately.
The hard truth about product management is that there are not many true product managers. Well, you find people with that job title, but what they think they’ll do and what they can do are vastly different from what they should do. I know it sounds harsh. But we need to stop hiding from this to become collectively better.
When you read that a product manager should be a mini-CEO, that speaks mainly to their skillset and the fact that you need to be able to imagine that this person can grow into the next leader of your company. They need to understand financials, sales, marketing, data, customers, technology, M&A, a little bit of legal, manage all stakeholders, manage their time well, be able to run a team of people who don’t report to them… and more.
To be fair, the name of the role says it all and that’s why I intentionally named this post “managing products.” As a product manager, you need to hit objectives by leading a team through product discovery. You figure out what the problems of your customers are, then you solve them through technology in a way that works for your business (I.e., create product). You work with your team to make that solution a reality.
Most people with the job title “product manager” who I have seen do just the last bit. They run product delivery, but they are told by someone what to build. However, that’s called project management.
The eye-opening difference starts here.
By building the right solution, your job doesn’t end, it almost only begins. And I’m not talking about iteratively improving the product to solve the customer problem well – that’s a given. I’m talking about making sure the product is compliant and certified. You need to make sure contracting and other legal issues are tackled. How does this impact your pricing? If it’s a new product, you need to establish tiers and pricing from scratch. How do we talk about this product? Who did you build it for? What’s the product value proposition? What metrics does this improve in the business of your customers? How do you sell this product? What are the buyer personas and what does the sales team need to know in order to sell this in the best way? How do you ensure existing customers adopt this new product? What’s the expected change in the customer’s business you’re driving here? And more. All these things are a part of your job from the moment you start looking for the best solution for a customer’s problem you’re trying to solve.
You and your team have run discovery, you know the answers to these questions the best. And you know them before you’ve asked the team to write a single line of code. That’s why you are asking them to build A and not B. Yes, product marketing, sales enablement, and customer success will pick up your answers to these questions and polish them into customer facing materials, they will train the teams, but they will not figure this out. If you’re expecting them to do so, most likely, you don’t know why you have asked your team to build that product.
If you’re spending time running delivery and not answering the questions in the above paragraphs, you are most likely not managing a product. Best chances are that you are managing a backlog or a gantt chart. You might be delivering relatively successful features and those are most probably sold to customers. But answering the questions above is what wraps them together into a product that someone can sell and someone wants to buy.
How to get there? Ask for an objective other than a list of features to build. You’ll see what a vastly different set of skills you need to start using. How much more context you need to have from customers and stakeholders. How many new things you must consider, learn, discover, and manage. But that’s the fun part, driving a change, discovering a new product. Not hitting a deadline or “discovering” usability of something someone told you to build.
As a part of real discovery, you will also master the problem domain and learn the real value proposition of your product. You can stop selling features and start selling solutions to problems, saved time, bigger revenues.
Are you managing products or projects? Be honest to yourself, that’s the first step towards becoming a great product manager.
