In The Hitchhiker’s Guide to the Galaxy, one of the strangest and arguably coolest phenomenons is the Babel fish. It is a small, yellow fish you place in your ear that feeds on your unconscious mental frequencies. In return, it then excretes back into your mind a telepathic matrix from the conscious thought frequencies and the speech centers of the brain. Basically, all of this allows you to understand instantly anything said to you in any language. Which comes in handy when traveling the universe and encountering many civilizations speaking unfamiliar languages.
While we’re not necessarily traveling across the galaxy or running from Vogons, our businesses still need the equivalent of this translation and coordination: a mechanism to ensure that all the various groups and disciplines within our organization are speaking and understanding each other. And that we are hearing and understanding the outside voices of our users, customers and industry.
That is the essence of product management. To ensure understanding across groups. To coordinate. To solve real problems.
How do we accomplish this? How do we gain this understanding, coordinate, and translate across teams and across our company? Product managers do this by focusing on 5 key areas:
Discovery & Research
Product management begins with understanding. And that is what product discovery and research are — the ongoing practice of understanding user needs, business needs, and market trends to decide what to build.
For a brief history, back when software was still being packaged into CDs or DVDs and being shipped to stores, product discovery and research looked very different. Much of the research and discovery was done upfront out of necessity. If you were a product manager, you had to figure out what would get built and go onto the DVD before it shipped.
Unfortunately, many of these practices have never gone away, even though we don’t package most software into a box any more. The idea of gathering long lists of requirements up front, passing them to engineering teams, building large projects, and then hoping that it all works out once it gets to customers.
Good product managers should not be gathering long lists of requirements for modern software, though. Or passing lists off to development teams. Or waiting for feedback from users. The miracle of modern software is that all of this can and should be done in the shortest increments possible. We should work constantly on understanding users, our business, and our markets, continuously adding to our dataset to make better decisions. We should work closely with our development teams so we all have a shared understanding, rather than “toss over the wall” lists of specs. And we should get regular feedback from users and stakeholders. Monthly, weekly, daily. As frequently as you can so you can add that knowledge to the dataset you’re building.
Discovery and research may often feel like it is easy to put to the side. As I’ve worked with a variety of product teams, I’ve seen how easy it is to dedicate far more time to execution and delivery than to research and discovery. Often product managers will look at their impossibly busy schedules and feel forced to make that tradeoff. Getting things out the door always feels more urgent than building an understanding of markets and users. But that is trading the long-term for the short-term. The best product teams and product managers find the right balance, investing in the future while delivering in the present.
For a deeper dive, see my upcoming article Product Discovery: The Beginning of Good Product Development.
Strategy & Roadmaps
Once product managers have done discovery and research, understanding their users, their business and their industry, their role is to set the strategy and roadmap for their product.
The product strategy should align with the higher product vision of the product organization. We won’t get too much into that here, but this vision should be compelling and long-term (think 3–5 years). And the strategy of each product should support it. Your product strategy also needs to align with broader business goals and strategy.
As a product manager, it is your job to set the product strategy for your product, together with your product leadership. We’ll talk more about this below, but you shouldn’t be looking to executives or stakeholders to do this for you. You will need their input, and depending on your company, you may have to balance stronger opinions with your own, but working with your product leader you should create the strategy.
Think of the strategy as a way of achieving the vision, so 1–2 years in horizon. It is fundamentally about how you’re going to achieve the goal of your product, whether that is 10Xing the business or doubling revenue.
One of my favorite tools to solidify the strategy for a product is to use a future press release. This is a tool made popular by Amazon and written about by many others. I’ve used it myself with splendid success. More on that in another article to come soon.
From the strategy, you should create a strategic roadmap, which tells the story of how and why you are working toward the long-term strategy of your product.
Roadmaps are not feature lists. They discuss ideas and direction, so features may be part of that, but the focus should be on the outcomes you’re trying to achieve and how the features may get you there, not on a list of features. Roadmaps also are not timelines or project plans. They are meant to give the direction, but we’re not ready to commit to specific dates or items because we’re determining what will get us to our strategic outcomes.
So if that’s the case, what should be the focus? Roadmaps should be about inspiring participants, communicating the strategy, generating discussion and gaining alignment. The focus should be on the outcome you’re trying to achieve with your product, how you intend to get there, and why that’s important.
For more thoughts on roadmaps, you can see my article on Product Roadmaps: Love, Hate (& Hate).
Partnership & Communication
Product managers are essential in partnerships and communication across an organization.
Communication is literally one of the top traits of a good product manager, so this should be no surprise that it is a key role. But product managers are uniquely positioned to facilitate partnerships and communication both within a department, a company, and outside an organization.
First, the very nature of the role is one of coordination within a product development team and across stakeholders and customers. So you should be building relationships and communicating relentlessly. This starts with your vision, strategy and roadmap, as we discussed above, and continues with prioritization, tradeoffs and delivery as we’ll discuss below.
Second, your role is to create the best product experience for your users and to deliver value through that for your business. You can’t do that alone. You literally need your users and your business partners as part of that equation. So partnering with them, building the relationships you need, and communicating frequently are all critical parts of the role of product managers.
Finally, you need to be an excellent partner and listener. It’s not enough to go out and evangelize your product. You also need to hear and understand your users and stakeholders. That’s the other side of partnership and communication. Don’t forget it.
Prioritization & Tradeoffs
One of the most troublesome parts of product management is prioritization. Frankly, it’s one of the most troublesome parts of life. Because we often have to choose between many good options and make tradeoffs with incomplete information. But it is a critical part of the role.
Prioritization is much more than just choosing the order of the backlog though, or what feature to work on first, though those are important aspects. For a deeper dive, see my article Prioritization: Choosing is the Hardest Part.
At a high level, prioritization comprises:
Like I said, prioritizing features on your roadmap is only one part of the bigger picture. There are a number of frameworks and methods for doing that, all of which have good attributes, so it will often depend on your company and context which will work best. I’ve used many as a product manager and product leader, and as long as you don’t outsource your prioritization to a framework since that doesn’t work, you’ll be fine. Remember, they are tools, not solutions.
Also, you are responsible for gathering the inputs and translating that to action. Stakeholders from marketing will have one perspective. The engineering department will have another. Sales will have yet another. None of them are wrong and all will be urgent and important. Everyone will need to understand the inputs, the framework for deciding, and why we’re prioritizing the way we are (see communication above). It will not be easy. Hopefully, you didn’t think it would be.
Delivery, Launch & Go-To-Market
Finally, everything above will be for naught if you don’t get your product to market and into the hands of users.
Depending on your company, delivery, launch and go-to-market may fall squarely on the shoulders of the product manager. Or it may be a shared responsibility with other groups like project managers or product marketers or sales or other groups. Regardless, it is your product, and you need to get it to your users. So it is your responsibility, no matter who else is helping or sharing in the burden.
After so much work to do discovery and research, create a compelling strategy and vision, partner with stakeholders and users, and make the necessary tradeoffs, it is almost tragic how often I’ve seen teams falter at the finish line. Don’t drop the baton at launch! Make sure you put as much time in preparing a successful launch and go-to-market strategy as you have put in preparing a great product or feature.
I’ve learned this lesson the hard way myself. Several years ago, as we created a new experience in a product we were building, we were incredibly excited about how much more intuitive it was and how great it would be for users. But when we launched it, it fell flat. We had failed to involve our support team and our training teams (we thought we wouldn’t need them since it was so good), but our users were not prepared for any changes. So we had to step back, get training in place, and then move forward again. What should have been a big step forward was delayed because we faltered with our launch strategy. I didn’t let that happen ever again.
While not exactly Babel fish (and we’ll leave the theological arguments aside, and whether product managers will eventually cause more wars than anything in the history of creation — see The Guide for more), product managers are the key to unlocking and translating real problems into real opportunities for our businesses and our users.
My personal musings on a variety of topics.