When product management theory meets cold reality
We recently ran a series of in-depth interviews with product leaders at large businesses to validate our thinking around their “jobs-to-be-done”, pains, and gains. The results were eye-opening.
Product management means a plethora of different things in different organizations. It even means different things to different teams within an organization. There are many variables when it comes to the activities product managers (PMs) are engaged in and the outcomes they are expected to deliver.
The role of a PM varies by an organization’s size, it also varies whether they work on new ideas or develop established products, and whether they work on customer-facing products or business capabilities and platforms. Is the product software, hardware, or data? Is it a financial product or service? Is the PM operating in a highly regulated industry? Perhaps it has all the unique requirements associated with the public sector?
One clear differentiating factor in interpretations of product management is whether the organization is transforming and embracing a truly product-led operating model or whether old ways of working persist. Many of our respondents confessed to feeling constrained by their company’s culture and history. Some wanted to adopt good product management practices, but didn’t see how it could work in their organization. This is corroborated by research from McKinsey in which 75% of PMs surveyed claimed that “product management best practices aren’t being adopted at their companies, that product management is a nascent function within their organization, or that it doesn’t exist at all”.
So given these stark realities, what does good product management look like in a large (perhaps unwieldy) business today? We have dozens of fantastic guides written by titans of the game (think Osterwalder of Strategyzer, the creator of the Business Model Canvas, and other authors like Cagan, Perri, and Torres). But what lessons do they hold for your average PM? How would they work, for example, for someone working on a portal for the customer support team at a large insurance business, waiting for a data warehouse to be re-platformed with expected completion in Q4 2024?
In this article, we take a look at ‘textbook’ product management, offer a reality check, and advise on what product practitioners can do independently of their context.
The three pillars of good product management
1. Good product leadership
Setting up the team for success
In “textbook” product management, it starts with strong leadership. Product leaders must translate business strategy into coherent portfolio strategy and ensure that the organization is working on the most valuable things. This is a massive statement and a crucial role.
Whether the title is Chief Product Officer, VP, or Head of Product, the most senior product practitioner in the building is the enabler of good product management. They need to be strategists who understand their customers and the competition. They need to understand architectural principles and how their portfolio of products and capabilities align to deliver a customer experience. They must demonstrate that they are working on the most valuable things while reducing waste.
They need to be deft stakeholder managers as they will relay the messaging around team achievements in measurable outcomes. These outcomes won’t always be about cost, revenue, user numbers, or other widely accepted, lagging metrics. The product leader needs to be able to sell the value of experiments and less tangible leading metrics to those making the ultimate financial decisions.
Product leaders must provide a framework that lets PMs know what they should work on. It’s just as important to promote the mindset that lets a team know how to approach a problem as it is establishing a coherent set of goals and measures – embrace uncertainty, be curious, experiment, call out, and validate the assumptions in your thinking.
Good product leadership makes everything else easy. It makes “textbook” product management possible.
Reality check
In reality, product leaders are very often on the hook to deliver, for example, a cloud migration, a new customer portal, or a transformation. No matter what they are delivering, it is often viewed as a “silver bullet” by senior management, so the role comes with unrealistic expectations, pressure, and deadlines. They are judged on lagging metrics.
Often, they don’t have a seat at the top table and must operate in a system that doesn’t reap the full benefit of adopting product management. There are dense layers of governance. There are dozens of legacy projects that consume developer resources and run over budget and time. There are myriad dependencies. There might even be a longstanding CTO who only pays lip service to adopt “product” – this CTO is happy delivering projects like they always have and is probably more interested in AI and automation.
The product leader may have inherited a team new to product management – people who were good at their jobs, well-liked, and re-shuffled into a new product team. These new PMs are inexperienced in building product strategies, understanding customers and their problems, and haven’t worked with developers much. At any rate, they use a large service integrator, and projects get thrown “over the wall”, coming back some months later.
The business is making a mess of implementing Objectives and Key Results (OKRs).
If this sounds familiar, what can you do?
- Get a hold of your portfolio. Map out your product and project landscape (with architects if you have them). Visualize your target customer experience and the products and back-end capabilities to drive it. Understand the work in progress (WIP). Most WIP will not add value or be strategically significant, so start lobbying to kill what doesn’t matter and use your resources on the bits that do.
- Set your product team clear and measurable goals that are obviously derived from business and portfolio strategy. Drive a culture of measurement and evidence-based decision-making through the team.
- Invest in your team’s capability. There is a ton of literature out there on product management practice. There are courses, coaches, and consultants if you have the budget. Theory is one thing, but you also need to allow the team to put this stuff into practice and give them the space to make mistakes. It’s a cliché, but mistakes are the quickest way to understand where that theory has come from.
2. Good product discovery
Using evidence to define what customers value
No matter what product you are working on or what stage in the lifecycle, you will have a customer with a problem you are attempting to solve. As a human, you will have a pre-conceived idea of how the problem is best solved.
As a textbook PM, at that point, you stop yourself and go back to the problem. You validate the problem exists for your target, typically using advanced techniques courtesy of your UX researcher. You build a profile and a customer journey map, validate it, and discover a more significant problem to solve. You ideate with an engaged UX designer and architect, prototype and validate with your customers, and add to a backlog to be built in the next sprint by your willing team, who are all bought into the value of experimentation.
Reality check
Reality is a little different for most product folks. Often, they are on the hook to deliver to a deadline, despite leadership “embracing agile ways of working”. They aren’t given the time and space to discover problems. Worse still, they are expected to deliver the solution their boss’s boss dreamed up.
They have no data. They have access to a UX designer for three hours per week.
If this sounds familiar, what can you do?
- Read some of the well-established product literature mentioned earlier and apply that knowledge. Using some of the well-established tools and techniques will help you clarify and visualize your thinking, even if real-world implementation is trickier. We frequently use Strategyzer’s Value Proposition Canvas to define the most important components of our offerings, how we relieve pain and create gains for our customers.
- Accept that most of your work is an assumption. Go and get evidence to test those assumptions. Bang on doors until you have exhausted all sources of existing data in your organization. If access to customers is tricky, then get creative. Test your assumptions on friends, family, and people you meet in the pub. Just be aware of potential biases. Use evidence to challenge the tricky stakeholders and validate your thinking. Consider using Strategyzer’s Innovation Project Scorecard to understand the strength of evidence you have to support your ideas.
- Use simple root cause analysis techniques (like the “Five Whys”) to understand why you are being asked to work on a product or project. This will help you unpick the problem to solve from the solution you are being given. Your goals should reflect the resolution of a customer or business problem and not the delivery of a prescribed solution.
3. Product delivery
Getting value into the hands of your customers quickly
PMs should be servant leaders of cross-functional end-to-end teams, we are told. They build high-functioning teams drawing on established frameworks, tools, and techniques to facilitate concise communication and foster collaboration. While different agile methodologies exist, in the perfect world, the team is well-versed in all of them and settles on a hybrid that is best for their context.
Your product owner and scrum master, while not conforming exactly to the textbook roles, are both excellent, meaning requirements are captured concisely with just the right level of detail. A dynamic backlog is prioritized. Flow is measured, retros are run, and a culture of continuous improvement abounds.
Your developers talk to customers; they have been involved in discovery and solution design and are fully bought into the increment release.
Releases are regular and easy to roll back, and developers are empowered to push code into the production environment.
Reality check
For many PMs in the real world, the idea of having a say in the way software is delivered is laughable. Even today, product practitioners are asked to gather requirements, put them in a nice big document, and pass them over to a development team to design the solution. These development teams want large projects to keep their heads down for a good while, and they crave certainty, hence the term “requirements”. The PM will probably be invited to test it before it’s released to production some months later, but the time that lapses in between is shrouded in mystery as far as the PM and wider business are concerned.
This situation is exacerbated if using a third-party service integrator, as the nature of the relationship tends towards a “throw it over the wall” mentality, because the supplier will be paid for outputs (software) rather than outcomes (software that helps achieve a goal).
If they are lucky, a PM will get to populate a backlog with basic user stories in a tool like Jira. If they are new to the role, Jira or any tool can be daunting. The backlog stories will multiply at a rate of knots until the whole thing becomes a ploy to placate stakeholders (“I’ll add it to the backlog”), at worst, a farce. Nobody believes the backlog represents value either way.
The one available UX designer is spread across three teams and has to rush their work to the extent that they’re just “making things look pretty” rather than researching anything.
The developers complain that the documentation isn’t good enough. The developers talk about the constraints of a legacy system and tech debt.
The team has to wait for IT security sign-off that comes once per quarter before pushing things to production.
The act of launching features is celebrated rather than the outcomes and results those features lead to. In fact, people are still determining if the feature worked.
If this sounds familiar, what can you do?
- The first one is simple – if you launch a feature, measure its impact on your leading and lagging customer metrics in the days and weeks after launch.
- Map out, measure, and improve your end-to-end workflow. Reflect this flow in your tooling. Measure flow metrics focussing on lead time (end-to-end) as we aim to improve the system rather than siloes.
- Challenge yourself to break down the work. Any large piece of work can be made smaller if you get creative. If you can’t break things down by customer value, try looking at risk or geography. Try placating one stakeholder at a time.
Conclusion
The full value of product management is far from being unlocked in most organizations. That’s because organizations are groups of humans who live in the real world, and in the real world, change is slow, and humans are inconsistent.
The good news is that even in a sub-optimal system, many of the fundamentals of product management can improve the way people and companies work. As we have suggested, PMs struggling with their environment’s realities can deliver impactful work if they understand some of these fundamentals.
If you enjoyed this reading and you’d like to learn more about our approach to product management, dive into our latest article, “Is it time to move from projects to products?” and download our “Moving from projects to products” thought paper.
Are you looking for support to implement product management best practices in the context of your organization? Reach out to [email protected] or visit our Product Management page.
Additional insights
Is it time to move from projects to products?
Time to put MVP to rest
The 2 key metrics delivery managers should care about first
