#1: How to Prioritize (Or, What To Do This Week)
Who is a roadmap for, anyway?
Welcome to the first official edition of The Second 90%! I’m very, very happy to have you here. I’m not set on Sunday as a publication day, so if you have strong feelings about when you want to hear from me, let me know in the comments!
My team doesn’t have fleshed out, long-term roadmaps, at least not in the sense that you’ve probably seen. And we’re better for it.
The project that we’re working on a long one. It has a clear-enough articulated goal (although nobody can agree on what “done” means), but it’s long, years long. There are tons of unknown unknowns. There are almost an infinite number of permutations we could sequence the work in. It's a high priority for the company, it has a lot of stakeholders, and it’s also time-sensitive.
From the beginning, we’ve had to make some really deliberate choices about how we work, what we work on, and how we prioritize. Doing this intentionally has surfaced some heuristics for how we prioritize that I think are broadly applicable to building software in general. Some sound obvious, some less so. I want to save you some time, so I’m here to tell you what they are.
When presented with an unbounded choice about what to decide to do now vs later (or not at all), our team has had good results when optimizing for a couple of things:
We prioritize work that will allow us to learn more about the work that we think we’re going to do in the future
We prioritize work that will allow us to validate our future work more quickly (aka shortening our feedback loop)
We prioritize work that will allow us to move more safely
Sometimes, we prioritize work that’s easy and impactful to do first
Sometimes, we prioritize work that is truly time-sensitive. The reason this is a “sometimes” is not because we only sometimes complete work on-time that is time-sensitive, but because there are rather few actual time-sensitive pieces of software in this world. That’s a post for another day.
And then, we prioritize the work that we’ve spent time making easy, safe, and easier to validate. All other things equal, we use impact as a metric.
Because much of our work paves the way for other work in the future, we are constantly learning, and we have such a long project, we purposely don’t promise a roadmap or set anything resembling deadlines. Any prediction we could make would be based on incomplete information and is somewhere between a guess (in the best case) and a lie (in the usual case).
My time on Growth teams also had this ethos. If we’re running experiments to decide what we want to build, how would we know what we want to build next, before we run the experiments? If we have an iterative team, where each week’s work informs next week’s work, why would we make decisions about what to do before we have to?
Who does planning serve? We don’t (shouldn't) plan because someone in the organization demands a roadmap, we plan because we need to point ourselves at the current big problem so we know what to do. Planning too far into the future isn’t useful to teams that iterate quickly. I have the least amount of information today about the project, and I can only learn more as we begin work. Why are you asking me, today, to tell you when we’ll finish, or how we’ll sequence work, or what we’ll do eleven weeks from now?
Not planning too far ahead gives us the flexibility to continually ask ourselves what’s most important, and chase after that. Doing so means more learning, de-risking, and early validation, because we are able to prioritize work in a way that serves those goals.
What did I miss? What factors throw a wrench in your team’s prioritization or planning? What day of the week do you want to hear from me? Let me know in the comments!
Next time: how to make performance review season suck less. I can’t solve all your problems, but I’ll try to solve a few.
Other things on my mind:
For US readers, there’s an election on Tuesday. Please vote if you haven’t voted already, even if you think your vote doesn’t matter. It matters.
Last week was a rough week for layoffs in tech. Check on your people and take care of yourselves
I saw Moulin Rouge in SF two weeks ago. It was a ton of fun, and I haven’t stopped thinking about it since. If the tour comes to where you are and you like musicals, I highly recommend the trip!
Very nice first article. Thanks for sharing these heuristics for prioritization. The point about truly time-sensitive work seems very interesting topic and I found very inspiring the phrase "Planning too far into the future isn’t useful to teams that iterate quickly". I am keen to read your next post. Warmest regards, Alex.
The reason management gives us for all the planning and roadmaps is the people who are paying us want to know what they’re getting and when they’re getting it before they write the check. They wouldn’t give a blank check to a contractor and say “build me a house” without blueprints, a budget, and a schedule. How would you respond to that?