You are not Focusing Enough
1 November 2020 ‧ 4 min read
In many product organizations, quarterly goal setting exercises and roadmaps discussions amount to a negotiation between product leadership and/or product management and the rest of the team, how many features can get built in a given time frame. The backlog is long and there are so many good ideas on the table. There is the general mindset of “the more good ideas we deliver on, the better our product will be”.
Product leaders often instill this mindset in their product managers and product teams by setting stretch goals and asking the teams to deliver as much as they possibly can.
Product managers are guilty of it, too: version 1 of a feature gets scoped as a “good enough” 80:20 version, 80% of the value with 20% of the effort. Once that is shipped, they move on to the next thing—after all, the remaining 20% value would take a lot more effort, and there are more low-hanging fruits around the corner.
And then there's of course also pressure from across the organization as well as senior management. Everyone has their pet ideas and important requests that just have to make it onto the roadmap. All these requests have great reasons, too, and seem like they would genuinely improve the product.
The feeling undergirding all of this is: “we always have too many good ideas but too little time”. And of course, it's true. There is never enough time to deliver on all of the good ideas. The problem with this mindset, however, is that it leaves the product teams hopelessly unfocused.
The mindset is fundamentally flawed: a great product isn't one that delivers as many good ideas as possible, each done in a “just barely good enough way“. A great product is one that really nails a few things. More bells and whistles is rarely what a product needs to be great.
Put differently: a great product doesn't even need a lot of good ideas. It just needs a few good ideas, executed to perfection.
There are examples aplenty for this. Dropbox, for example: there were plenty of file synchronization solutions around; Dropbox just nailed the idea of “a folder you can pop your files in and they'll show up everywhere”. Or consider Slack: it's essentially a somewhat fancier version of decades old IRC, but they really nailed the user experience and delight. Or Zoom: in the crowded market of videoconferencing software, they focused on making the experience as easy to use and as reliable as possible, achieving the ultimate level of product success during the COVID-19 pandemic when “Zoom” became synonymous with “videoconference”. Or Spotify: in the early days, a lot of engineering resources were poured into making playback of streaming audio as fast as possible, so that it would feel almost as if the audio was local and not streamed from the cloud.
What does this mean in practice, then? Almost certainly, you and your team aren't focusing enough today. You need to increase your focus, be crystal clear what the single most important thing is and then spend the vast majority of your time on it. This will mean cutting many good ideas. You will have to put them off or potentially never get to them. Personally, I am in favor of not even collecting these good ideas in a backlog, which can both be a huge burden to manage and create the impression that all of these ideas will have to be implemented at some point. And then, when you've cut some good ideas, you need to cut some more. You really need to distill the essence of your product and identify the very few ideas that you want to out-execute everyone else on.
Product prioritization is never only about finding the good ideas among all the ideas. It is also, and I would argue even more so, about deciding which of the good ideas not to pursue. This is always almost the most painful and most difficult aspect of prioritization. Saying no to the not so great ideas is easy, once you've identified them (for example, by collecting information about potential impact, through research, or by prototyping). Saying no to some ideas, even most ideas, that still seem good after initial evaluations, is the more tricky part.
In addition to not pursuing good ideas, it also means more iteration on the ideas that work. It means revisiting stuff that's already been shipped, even if it looks good on the surface, and drilling deeper. What are the flaws? Where do people get stuck today? How might this be made more effective, efficient, delightful? How might we make this experience better than anyone else's?
This is what product leadership and product vision really means: narrowing down the value proposition of the product and how it will differentiate vs. the competition, visualizing what a “great” product will look like for that value proposition, and then dedicating all resources to creating that great product.
The counterintuitive aspect of all of this is that the role of product leaders in a great product organization isn't to push the teams to deliver more. That is a mindset that many leaders and managers have—to demand greater “performance” by the team, as measured by the number of great ideas that they can implement. As mentioned above, this will lead to a mediocre product. Instead, product leaders should push their teams to focus, to deliver less. Of course, product leaders also have to evangelize this narrow focus to the rest of the organization, and push back against any stakeholder demands to lose that focus. In a great organization, everyone—including stakeholders outside the product development organization—will understand the need for focus.
Product managers in their product teams have a role to play, too. They have to resist the urge to always chase the next shiny thing, to abandon ideas once the first version is shipped. Instead, they should double down on what works, find the flaws, and work with their teams to make “good enough” features into excellent ones.
I hope you found this article interesting. If you did, feel free to follow me on Twitter where I share thoughts and articles on product management and leadership.