Seven Product Management Principles
How to improve your product management and leadership practices
Product management is a relatively new discipline that keeps evolving rapidly. Every week, there are new articles about product development best practices that industry leaders are following. This deluge of information can make it difficult to understand what practices to follow and how to look for improvement opportunities in one’s own work and team.
Moreover, this constant evolution means that what is considered best practice today might be outdated tomorrow. For instance, earlier this year, news broke that Spotify is no longer following the “Spotify model”, which for a while was hailed as the model for a large scale product development organization rooted in agile and lean principles. So, can any of these best practices be taken at face value?
There’s a solution to this dilemma, though. Instead of chasing a changing understanding of best practices, uncover the principles underlying these practices. These principles are higher level than the practices and also more stable over time. You can then implement these “best principles”, not the best practices themselves, for yourself, your team, and your larger organization, in a way that fits your specific context.
In this article, I will share seven principles for product management and leadership and some of their implications:
- Start With Why
- Understand the Problem
- Focus Relentlessly
- Empower the Team
- Embrace Uncertainty
- Balance Inputs, Outputs, Outcomes, and Learning
- Iterate, Iterate, Iterate
The beauty of looking at principles instead of practices is that these principles can be followed at any level of an organization. Whether you are an individual product manager on a team, a team lead, a CPO, or a startup CEO, you will be able to find a way in which these principles apply within your scope and how you can improve your work and your organization.
1. Start With Why
The first principle, “Start With Why”, is the title of a TED Talk by Simon Sinek (and an eponymous book). Starting with “why” means that before getting into the details of “what” should be done and “how” it should be done, the discussion should revolve around the “why”: What is the higher-order purpose of our work? What are we trying to achieve? What is our vision for the future?
John Doerr famously coined the differentiation between missionaries and mercenaries — missionaries follow a their passion to achieve some higher level purpose, while mercenaries seek to exploit opportunities they see arise. Great companies and great products tend to be built by missionaries. Missionaries exhibit greater intrinsic motivation (because they are working on a purpose that matters to them), more perseverance in the face of difficulties, and greater attention to detail than the mercenaries. Building a team of missionaries requires starting with why. You can’t make someone a missionary for the vision of the company and the product without sharing and achieving strong buy-in to that vision.
Starting with “why” is possible at all levels. Clearly, one of the key responsibilities of company and product leaders is setting the direction for the product, which includes the aspirational vision as the basis for product strategy and roadmap. Ensuring that that vision is broadly evangelized and embraced by the team as their reason for being is crucial, then, for the leadership of a “missionary” organization.
The same is true even within individual product teams. You might not have a grand vision for every single thing you work on, but it is still crucial to tie all the work happening in a product team to the product vision and company mission. In addition, even for individual feature work, you can discuss among the team why you are working on what you are working on: not just in terms of that being a small piece of the puzzle to achieve the overall vision, but also in terms of how this particular feature is going to improve the lives of your customers (and/or contribute to the company’s success).
In summary, whether you are a product leader, a product manager, or even just an individual product team member, you can follow the principle of starting with why by continually making these connections between the day to day work and the bigger vision.
2. Understand the Problem
The second product management principle is to truly, deeply understand the problem you are solving. At first glance, this principle sounds obvious, even trivial. How would you solve a problem you don’t understand?
In practice, though, very often we end up chasing feature ideas without taking the time to truly understand the problem this would solve, who of our current and prospective customers actually has this problem, and whether they care enough about this problem to pay for a solution.
Following this principle therefore first and foremost requires the crucial product management skill of empathy, which means being able to put yourself in others’ shoes and see things from their perspective. If you don’t understand how your customers perceive the world, it’s very hard to attempt to solve problems for them. However, you also cannot myopically assume only the perspective of your customers, otherwise you wouldn’t be better positioned than they themselves to solve those problems. Truly understanding the problem therefore requires looking at the problem from different perspectives, which requires diversity of thought in the product team.
Understanding the problem also means defining the problem before attempting to solve it. However, it also means understanding that especially in technology-enabled products, problem and solution are often interdependent. For example, when emerging technology opens up new possibilities, it might shift our understanding of the problem, and we have to go back and adjust the definition of the problem as well. That is why the “double diamond” design process, which separates the process of designing a product or product improvement into separate phases for diverging and converging on problem and solution, is often fundamentally flawed for digital products. A better metaphor is the “design squiggle”, which shows a chaotic exploration at first that then converges over time.
Following this principle also means focusing on people problems before product problems. Too often, product managers see their world primarily through product objectives: “we need to improve retention, therefore we should build feature XYZ”. Low retention is a problem, of course, but it’s a product problem, not a problem of your users and customers. No one ever said: “gee, I wish this product retained me better.” On the other hand, poor retention probably means that you aren’t solving your customers’ problems as effectively as possible, otherwise they wouldn’t be churning from your product. So find out what those problems are, understand them, and build those improvements.
Of course, sometimes the work you are doing is almost exclusively focused on product problems. After all, you want to build a business, not just solve people’s problems. Monetization features, for example, or improvements to conversion funnels are mostly for the benefit of the business, not so much the benefit of the customer (you could just give stuff away for free, otherwise). However, it’s important that the balance is right. In order for you to extract value for the business, it has to first be created for your customers, which requires solving their problems. So understand and solve customer problems first, and then focus on extracting value for your business.
3. Focus Relentlessly
When you have started with the “why” and truly understood the problem that you are trying to solve, it is time to focus relentlessly. Focusing relentlessly means doing fewer things than you think you should be doing, but taking them to perfection.
Focusing relentlessly means understanding that a great product isn’t one that does a lot of things in a way that’s just good enough. A great product means really nailing a few things. It means doing fewer things better.
The principle of relentless focus means that an 80:20 approach can be misguided in product development. The 80:20 approach means finding the 80 percent of the value that can be achieved with 20 percent of the effort, and then only delivering on those 80 percent. The truth is, however, that differentiation is often achieved through those last 20 percent, precisely because they are more effort. If the remaining 20 percent of value were easy to deliver, everyone would do it. By going the proverbial extra mile, your product becomes more attractive to those customers who value the remaining 20 percent in a way that is expensive to copy.
Focusing relentlessly thus means that you can’t prioritize work on your product by following a framework or calculating ROI. For one thing, these frameworks disregard the fundamental uncertainties underlying innovative product development. More importantly, though, these frameworks would never tell you to focus on the differentiating features that are harder to build. They would never tell you to focus on customer delight, because the payoff is hardly ever immediate. Instead of following frameworks, you need to prioritize based on vision, strategy, and a deep understanding of your customer and their problems.
Lastly, this principle requires understanding that there isn’t a single prioritization process. There are, instead, many levels of prioritization, and at each level, much more needs to be cut out than focused. Crafting a product vision is the highest level of prioritization, because anything that’s outside of the product vision should be out of focus. Product strategy, selection of product roadmap themes, problem areas within that theme, and solution ideas are levels of prioritization further down the stack, and each of those levels requires relentless focus. In other words, this principle again applies at all levels from leader to individual contributor.
4. Empower the Team
The forth product management principle is to empower the team to solve the customer problems (in ways that serve the business) through cross-functional collaboration between all the disciplines involved in product development (at least product management, design, and engineering). Empowered teams are different from feature teams or delivery teams in that they are given goals for problems to solve, not feature projects to deliver.
Empowered teams have many benefits in terms of motivation, customer centricity, velocity, and capacity to innovate. They are more motivated because they have higher autonomy and sense of purpose. They are more customer centric because they can learn the best solutions in close contact with the customer, not based on senior management decisions. They have higher velocity because feedback loops are inside the team and don’t have to go up and down the management chain. They have higher capacity to innovate because of the cross-functional nature, in which understanding of the user, technology, and the business comes together.
For this principle, it is important to note that true team empowerment requires senior management buy-in (after all, the teams need to be given their goals in the form of problems, not in the form of feature roadmaps). However, even as an individual product manager, you can do your best to empower the rest of your team. Many first-time product managers think that their job is to know all the answers and have all the ideas, when in fact, nothing could be further from the truth. You can leverage the collective knowledge of the team and produce better results through more diverse thinking by making sure the whole team is involved from the start of the process. This especially means that engineers should be involved in the discovery phase, even before a solution idea has been formed.
Of course, not every team member will have the same level of involvement throughout the process. Design and product management will still have heavier workloads during the discovery phase, and engineers during the delivery phase. However, involving engineers earlier in the process helps them both bring their perspectives to the table (for example, to highlight potentially novel approaches enabled by technology), connect their work with the bigger purpose, and ensure everyone’s buy-in to the selected approach.
Starting together and discovering the solution together also makes everyone more invested in the chosen solution, which means greater attention to detail and craftspersonship, and therefore, in turn, a better product.
5. Embrace Uncertainty
Empowering the product team is particularly important because it allows following the fifth principle to embrace uncertainty. Product development is a fundamentally risky endeavor. That risk doesn’t just lie in how well the ideas you have can be executed. It is far more fundamental than that: regardless of your initial confidence in product ideas, most of them won’t deliver the hypothesized value (to the customer, to the business) you hoped for. Moreover, you won’t be able to identify the bad ideas until you have invested substantial effort in exploring them. That is the uncertainty axiom of product management.
Without embracing this fundamental uncertainty, you will never deliver a great product. Embracing this uncertainty means accepting failure, recognizing that some of the ideas that sound great in theory will fail to deliver any real value. It means killing your darlings again and again. It also means that you sometimes may have streaks of bad ideas, where idea after idea fails. Accepting this can be hard. No one likes to fail all the time. It is therefore important to understand this as a fundamental property of product development and nothing to be ashamed of. To the contrary: every idea that didn’t turn out to deliver the hypothesized value should be understood as a learning opportunity.
Following the principle therefore means validating all ideas. It means that no idea, even ones that come from senior stakeholders or customers, are sacrosanct — everything needs to prove that it’s really making a difference. This validation needs to happen as early as possible — shipping something and then realizing it doesn’t deliver the hypothesized value means a colossal waste of resources. It’s still better to kill something that was shipped and failed to deliver value than to leave it in the product (due to the cost of increasing complexity), but it would have been even better to validate the idea through a prototype and realize it doesn’t work.
There are many practices for validation and that all follow the principle of embracing uncertainty. When evaluating validation practices to apply, it’s important to understand that the only signal you can really trust is people “voting with their feet and wallets”. Just asking someone whether they have a certain problem or would like a better solution is very likely to result in an affirmative answer. Words are cheap. If you really want to understand if the problem is big enough or your solution works for the customer, you have to get them to put their time and/or money on the line — start using your solution or even better, paying for it. That can be in the form of a prototype or Minimum Viable Product (MVP), but just words without action should never be understand as strong evidence to validate an idea.
6. Balance Inputs, Outputs, Outcomes, and Learning
Following from the previous one, the next important principle is to balance inputs, outputs, outcomes, and learning. Traditional management of software development processes is often myopically focused on outputs: how many new features are we shipping? However, from the uncertainty axiom of product development, it follows that it is by no means guaranteed that shipping more and more features is at all beneficial to the customer (or the business). Modern approaches have therefore realized that focusing on outcomes (for customers and for the business) is important. Even a singular focus on outcomes, however, has its challenges. Instead, you need to also consider inputs (the quality of information you use to make product decisions and the decision process) as well as learning (how you feed information from the outcomes you have achieved back into the product development process).
As with team empowerment, you can only fully follow this principle with senior management support. If teams are measured by outputs, then it is hard for a team to focus on the other aspects. However, making sure that outcomes, inputs, and learning are not completely disregarded is something that even individual team members can pay attention to.
This need for balance is particularly pertinent when it comes to validating that you are actually solving the problems you set out to solve. Organizations that focus too strongly on short-term outcomes can fall into the “A/B testing trap”, where every product change is tested against the current version of the product in an A/B test. A/B testing is a great tool to scientifically measure the impact of changes, of course, but it is also a tool that can stifle true innovation in favor of mere optimization.
Another important way that this principle can be implemented even within the scope of individual teams is in terms of ensuring enough emphasis is put on the learning feedback loop. The challenge with learning, distilling findings from the outcomes that were achieved, and feeding them back into the process is that it requires work today that will pay off only in the distant future or even benefit different people (when the current members of the product team have long left). However, in the interest of the longer term success of the product, it is important that lessons learned are collected, documented, and shared in some form or another.
7. Iterate, Iterate, Iterate
The last product management principle is to iterate, iterate, iterate. This principle includes not only iterative delivery of software through Scrum or other agile software delivery practices, but the entire process of discovering, delivering, and improving the product.
This starts with product discovery and the misunderstood MVP. Many people believe that the MVP should be the first version you ship of a new product or feature, scoped as small as possible so you can still validate or invalidate the core value hypothesis. A better way to understand the concept of the MVP is that it is a tool to validate the currently riskiest hypothesis or assumption. This means two things: firstly, an MVP doesn’t need to be a product. In fact, often, it won’t be: a prototype or proof of concept is frequently cheaper to produce and validate than a full, scalable product. Secondly, once the riskiest assumption is validated, another assumption becomes the riskiest. This means you can now iterate and produce another MVP to validate that next hypothesis, until the remaining assumptions bear little enough risk that you’re confident building a real product. That first version of the real product then doesn’t have to be an MVP with a lot of “cut corners” anymore — since you have reduced the risk, you can build a product that users will be happy and delighted to use instead of a crappy half-baked experience. In other words: there should be a series of MVPs, followed by a v1 of the product which isn’t an MVP.
Iterative delivery is almost a given these days with plenty of iterative software development practices. One particularly important aspect I have already covered above: make sure the entire team including engineers gets involved not just during delivery, but also in the discovery iterations. That way you can ensure there is no hard “hand-over” between discovery and delivery, which would make the iterative process a much more linear waterfall process.
Lastly, the principle of iteration also covers what happens after a product is shipped. Too many teams try to move on from features they have shipped successfully as quickly as possible: “This works well enough, metrics have improved. Let’s get to the next thing on our long backlog!” In line with the principle to focus relentlessly, though, it is often better to instead double down on what works and improve it from good to great. Again, a great product is one that really nails a few things. So when you’ve found a feature that works and delivers value for your customers, why not make it really stand out and differentiated?
All of these principles are just guiding ideas. There are many ways in which you could implement these principles in your organization, depending on the context, the culture, the processes, and the product. In any case, I hope that these principles can be helpful in investigating the practices you follow today and how they could potentially be improved.
I hope you found this article useful. If you did, feel free to follow me on Twitter where I share thoughts and articles on product management and leadership.
