As the discipline of product management matures, there is often talk in the product management community about a product manifesto — a set of aspirational principles that guide us — similar to what the Agile manifesto did for software development. Here is my take on what it should say:
As product managers, we have come to value…
Positive outcomes over cool features
While we love building stuff, our calling is to delight our customers and deliver value to our businesses. We will resist the urge to build things that the world doesn’t need and waste the talent of our product teams.
I’m as guilty as the next product manager when it comes to adding hot features to our product without proper validation. But the world has a shortage of product, tech, and UX talent. What if we doubled down on the things we’ve put in users’ hands that don’t work as well as they should? What if we measured our performance based on how well our user’s goals are met? What if we forced ourselves to remove a feature every time we added a new one, to keep our codebase small and free our developers from maintaining features that no one uses?
Empowered teams over top-down decision making
We believe the best work gets done by small, cross-functional, highly collaborative teams with shared objectives and the authority to make decisions for themselves.
Most of us believe this but as we rise in the management ranks, we have trouble living by these words. We’ve gotten to where we are because we’ve made good decisions, or so we think. We are not used to staking our reputations on those with less of a track record. But great leaders know that the best outcomes come not from the leaders making the decisions, rather from leaders creating the right environment for decisions to be made. Good decisions are born when there is free flow of information, open debate and respect for others’ opinions, clear roles and ownership, trust between team members, and risk tolerance by leadership.
Watch this Fireside Chat for Prioritised members where product author and coach, Joe Leech and our Managing Director, Emily Tate explore how the Jobs to be Done (JTBD) toolkit can be used to make better product decisions.
Customer needs over internal priorities
We don’t ignore internal priorities. But we realize that while we are focusing on our internal stakeholders, there is a chance our competition is focusing on the customer. And ultimately the customer is the one who picks the winner.
Again, most of us know this. But in practice, when we spend our days in internal meetings with no customers in the room, the customer’s voice is the one often not heard. Especially at large companies, internal requirements, and political dynamics often dominate our mindshare. It’s incumbent on us, the product managers, to represent the customer in these conversations. If we are not the ones doing it, who is?
Serving those who care over those who don’t
It’s unlikely that our product has mass-market appeal. That’s okay because we can make a good living serving those for who our product is meant for. We won’t let the critics and the disinterested distract us from serving our customers who care.
Serving all types of customers who want all sorts of things is not possible. We have to pick our shots. Do we focus on those who see value in what we have? Those who are willing to tolerate a few imperfections to reach their desired outcome. Those who treat us like partners, give us productive feedback, and want us to succeed. Or do we focus on the much larger pool of those who have no interest in what we sell? Those that want something for nothing. Those who won’t notice if we are not around tomorrow. Hint: those customers who believe in us will stick around and won’t mind spending more on our product over time if we continue to delight them as their needs evolve.
Shipping to learn over shipping when perfect
We realize the limitations of our intuition and know that the best products are built with users, not for users. We look for quick, inexpensive ways to test our assumptions and we are honest in our assessment of market signals. We treat adjustments to our plans as part of our process, not a failure of our process.
We could ship today or wait another year. If we wait a year, our product will have more features and fewer glitches. We’ll have more time to incorporate feedback from internal testers. Our marketing materials and documentation will be better. But what if our competitor ships today? Customers will see their product’s flaws and limitations. But they’ll also see what works, and may actually find it useful. And they’ll give feedback. Our competitor will have a year’s worth of customer engagement before we get out of the gates. Who would you rather be?
Read Paul’s previous article on Mind the Product — Building a product roadmap to avoid potholes down the road.
Ecosystems over ownership
Our products go farther when others can extend them, other products can integrate with them, and users can contribute to them. We believe the benefits of empowering and enabling the members of our community outweighs the cost of giving up some control of our products.
The open-source world taught us that people we’ve never met can make our products better, often faster than we can. Social media platforms taught us the power of the network effect of content. While our products may not fit either model, we should be open to the possibility that our core assets could be leveraged by creative people in ways we never imagined. And if that happens, usually there are ways we can reap the benefits from that.
Read this blog post by Jorge Rodriguez-Ramos who elaborates on user demographics and changing your mindset over user-centric ideas.
Contributing to society over winning at all costs
We recognize that software powers the world. We care about how our products are used and take personal responsibility for what we create. We aspire to build products that do more than just serve the bottom line.
This isn’t about making products that save the world. This means being deliberate about what we build. Understanding not just the benefits our products bring, but their associated costs. It’s about being aware of who our software enables and what they use it for. It’s about how we treat our people and all those in the ecosystem that makes our products possible.
Accessibility and inclusion over focusing on the ‘typical’ customer.
We are mindful that potential users of our products may not look like us, think like us, act like us, or have access to the same things we have. We believe that empowering a diverse community of users, partners, and stakeholders invites opportunity and is simply the right thing to do.
It’s easier than ever to focus our product on a particular audience. We create personas representing those typical buyers, interview real people fitting the mould, build features they want, speak their language, and target our advertising to individuals like them. The problem is, our product may be good for others not like them. But we didn’t take the extra few steps to truly make it work for them, or communicate a message that resonates with them, or even make them aware of it. The good news is it is also easier than ever to make our products more accommodating. If our product is good enough to build a community around it, does it really need to be a gated community?
These are the principles that guide me as a product leader. What would your product manifesto be?
If you liked this post, explore more content on Product Development Process.