Don’t prioritize features! Some lessons in PM prioritization
(I gave a talk at Product School, as a part of their Product Masterclass course in the fall of 2019. This article summarizes the content and the key takeaways that I presented in the talk. The slides from my talk are below)
When you ask a PM what they do, there are several common answers that might arise: write specifications, build a roadmap, figure out the MVP, support customers, analyze metrics, and so on. Though, if one peels back the layers, there is one thing at the core: prioritization. Prioritization means building the right product for the right user at the right time.
A simple way to approach prioritization is through a ROI matrix. You look at the possible options to pursue and the costs and benefits for each of them. Then you pick the ones with the highest ROI. While this works in theory, reality is a lot more nuanced.
As a PM, I’ve learnt some lessons in prioritization, that seem contrary at first sight:
- Don’t prioritize features
- Don’t focus on customer wants
- Don’t build an ROI matrix
- Don’t work on improving your product
Don’t prioritize features
A feature prioritization table assumes that you know which features to consider building. Though that may not be the case at all.
On an early stage product, you’re looking for product-market fit. On a more established product, chances are you’re looking for feature-product fit. You might not know what you need to build to make a product or feature successful!
This happened to me when I was building Dropbox Extensions. We wanted more weekly collaborative users (WCU), and simply didn’t know what to build. Our goal was to find the elusive feature-product fit.
Instead of features, we prioritized learning and time. We talked to users constantly and found underlying motivations. We talked to retained users, users who used it once and abandoned, and users who never found it. We took hypotheses and built experiments. We thought of ways in which we could run experiments faster. We optimized to learn. Our team motto was “learn faster”. Within a few weeks, we were able to push past the 100K WCUs.
Sometimes products/features that you launch don’t do well. At that time you won’t know what to build. What you need to prioritize is to move fast, learn, and save time. This also reminds me of this quote from Mark Zuckerberg.
Don’t focus on customer wants
Not focusing on customer wants? That doesn’t make much sense at all. Or does it?
When I first joined Dropbox, I was the PM for an internal analytics tools team. A large company such as Dropbox has diverse analytics needs. The team had been ambitious and was building and maintaining 8 different products. All with 8 engineers. This huge workload in supporting products was burning the team out. Most of these tools were semi-critical if not important for users — so no obvious products to shut down.
We were stuck between a rock and a hard place. But we had to save the team. We brutally minimized. We cut down development to 1 product and kept a couple more on life support. It was painful. We felt like we were letting so many customers down. Without cutting down, the sheer tech debt would have caused the team to quit. Over time, we recovered and were able to grow back up.
At another time, my team was proposing foundational work for developer efficiency. We decided to spend 30% of our time on it. Did the customer get any value? Not directly. By keeping engineers happy and increasing their productivity, we optimized for future output.
For prioritization, there is an another entity to consider beyond users — it is the team itself. Focusing on customer wants while neglecting team’s needs is a recipe for disaster.
Don’t build an ROI matrix
Prioritization is more of an art than a science. While the ROI matrix is a guidepost, you can’t rely on it entirely. Though, at times, the situation is different and what needs to be worked on is going to be blatantly obvious. Yet we don’t see it at times.
I myself have been guilty of over complicating things. A couple of years ago at a Dropbox, I remember a particularly long meeting on prioritization. We spent hours talking about potential product integrations. But one number made our prioritization obvious: 250M. That is number of common users between Dropbox and Gmail. To help our users, we needed to build the best Dropbox- Gmail integration experience. Everything else paled in comparison. We built that Gmail integration. It was one of the top ranking apps on the Gmail app platform almost immediately.
Take a step back, look at the larger picture. What might be obvious? It might help to look at the data. On a previous team, what our users loved the most was this tiny data visualization tool. 1 engineer built it in his spare time. It wasn’t obvious to us that this was that valuable. Though once we looked at the data and then talked to the users, we saw the obvious.
Don’t work on improving your product
Prioritization isn’t only about seeking to improve your product. The process surrounding your product is very well a part of it.
Back on my analytics team, we had 1 particular problem that was causing a ton of burn out for the on-call. We had a Slack channel for support and the entire company pinged it for support. Imagine getting 30+ ad-hoc requests for 8 separate code bases at the same time. You’d pull your hair out!
In this case, it wasn’t important to improve the product. We had to improve the process around it. We did 2 things to fix it. We spent 1 entire sprint as a team on documentation. We then setup a Zendesk instance with automated responses. With an improved process, we delivered a better, faster experience to customers.
At a separate instance, we prioritized processes around data integrity: hire a data engineering team, classify source-of-truth data etc. . This was because users weren’t using our analytics tools because the data wasn’t reliable. There wasn’t anything we could do to make the product. We had to improve the underlying process the product relied on.
In summary
- Don’t just prioritize features, but prioritize learning and time
- Don’t just focus on customer wants, but also think about your team’s needs
- Don’t just build an ROI matrix, but work on what’s obvious
- Don’t just improve your product, but improve your process as well
Disclaimer: All opinions expressed here are my own reflections. They do not represent the views or approach of my current or previous employers. Send in your comments and feedback to ketan.nayak@gmail.com. Please do not reproduce or quote any part of the article, email me for permission.
