Ruthless Prioritization permalink

As an aside, most people think startups are fast because they work harder and are more ambitious. The truth is that most of the speed difference comes from having far less dependencies (and few customers to upset if something screws up), so it’s just easier to get stuff done.

I just finished this lunchtime reading and thought it was worth sharing with you all. Simply put, Brandon Chu’s post, Ruthless Prioritization, hits home for me. I suspect it does for a lot of you also.
Try to take a moment to read it.

This post lines up with a few things, in particular, that I’ve struggled with of late:

Prioritization based on value

My overall goal, in any role I’ve had at any company, is to provide as much value as possible while I’m there. In order to do that, I need to understand the value that any particular item will provide. I feel that “value” is too often a mixture of the Squeaky Wheel, HiPPO, and Urgency and less frequently an articulation of the ROI to the business, or even better, the customer value. In addition, given the breadth of many companies, even if one were able to effectively prioritize within one’s area of responsibility based on value, the ROI across the company isn’t apparent.

Dependencies across teams in achieving value

Simply put, there are too many hand-offs in order to get to customer value today. This has resulted in us adopting enterprise-y levels of delivery speed. It has also led to a lack of understanding of how the system works as a whole, making it less likely that we actually achieve the value our customers are looking for.

Tradeoffs in implementation (and the request to have no more tradeoffs - aka “do both”)

This most often surfaces as Quality vs Speed to Market. But there are others around technical approaches that just reflect a lack of confidence in an assumption of the problem such as “customer data will only contain numbers.” This blog post does a remarkable job in breaking down prioritization across and within a project, taking into account team and project dependencies, constraints based on time and team composition, and balancing the “quality vs speed” debate purely as a function of assumptions and risk.

Summary

Steps to prioritize across projects

1. Estimate the ROI for the company.
2. Apply three constraints to each project: dependencies, time and team composition.
3. Sequence the projects based on capturing as much value as quickly as possible (HOLY SHIT! THIS LINES UP EXACTLY WITH MY GOAL!)

Steps to prioritize within a project

Effectively, this tries to get us to answer the question, “Is this absolutely necessary to build?”

1. Build prioritization systems (reduce the mental overhead of sorting work items within a project and get to decisions quickly)
2. Use product assumptions to drive quality vs speed tradeoffs
3. Focus on The Time Value of Shipping (or “Get something to 80% of the customers in 20% of the time”).

Gems

On company speed and project dependencies:

As an aside, most people think startups are fast because they work harder and are more ambitious. The truth is that most of the speed difference comes from having far less dependencies (and few customers to upset if something screws up), so it’s just easier to get stuff done.

On balancing speed and quality

I’d like to leave you with one last truth about prioritization: there is always a way to accomplish your goal faster than you currently plan to.

Always. You just have to find it. You just have to ask, “How can we do this in half the time?” at the end of that planning meeting, and miraculously — the team will find a way.