This is a work in progress
I’ve been evolving some ideas that a colleague and I sketched out a couple of years ago. I’m trying to use my personal website as more of a living garden rather than just a place for final, polished content, so I’m sharing my outline as it is so far in the open.
- The atomicity model for prioritizing is a way to help decide what to build and when during big product evolutions: what to say yes and no to, when to do what, and how to decide which teams should focus on what.
- The challenge of prioritizing during big product evolutions
- Significant product evolutions redefine and expand on what the product is and how it’s used. That means the foundation is going to change, and the common thread has yet to be defined—it needs to be found through research, discovery, shaping, testing, and validation. And by the nature of these evolutions, we’ll ship iterative slices of the vision on a rolling basis, but also learn how the parts we’ve previously shipped are working.
- Traditional iterative shipping can paradoxically become waterfall in disguise, because each iteration just leads the way to the predetermined Big Launch, without learning and iterating on the way.
- Larger orgs with many separate product teams tend to find it hard to prioritize known, shared opportunities that would benefit their team’s area, but aren’t clearly owned by any one team. Shared opportunities are inherently prioritized against a product team’s specific opportunities, and product teams are incentivized to be selfish (in a positive way)! This means many cross-cutting opportunities are never prioritized, or have to be tackled by improvised/tiger teams. That takes a lot of work and doesn’t scale.
- It’s often easy to justify “quick wins” that will quickly become obsolete without helping the team actually learn or improve on something.
- The challenge of prioritizing during big product evolutions
- Unlike straightforward redesigns or self-contained product features where the product’s core remains stable, big product evolutions shifts the foundation, and the common threads that define the product’s future emerges over time.
- The atomicity model for product prioritization is a low-process approach to doing and sequencing based on the things that will have the greatest impact towards building the next thing while also continuing to improve what’s there already.
- Ideally it can be done as a quick sketch or notes on a whiteboard. But it’ll scale from small organizations working as one team (working on many product features), to a larger organization with many separate product teams (working on a slice of product features).
- The atomicity model captures how self-contained or context-dependent an opportunity is in relation to the product’s evolution.
Spectrum of Atomicity
- Opportunities exist on a spectrum of atomicity:
- Low atomicity opportunities are deeply context-dependent. An in-product onboarding tour is intimately tied to the current UI and workflow, and will become out of date and obsolete almost immediately as the product evolves.
- High atomicity opportunities are self-contained or adaptable. The solutions generalize well and remain valuable through the product evolution, either supporting or unlocking further evolution.
The ROI Dimension
- Negative ROI represents work that will be obsolete or require redoing
- Positive ROI delivers immediate improvements to the product experience or value prop
- Multiplying ROI indicates opportunities that will ripple across several product areas
Using the model
- Map current opportunities on the atomicity spectrum
- Take a stab at ROI
- Decide a boundary between negative and positive ROI
- Make decisions based on this
- Anything that has negative ROI should not be done at all (in its current form, right now).
- Anything that has positive ROI should be considered.
- Anything that appears in multiple product areas or teams and has high atomicity has a multiplying ROI and should be prioritized.
- What makes this model really helpful is that it recognizes time’s influence—both atomicity and ROI are dynamic as the product evolution unfolds. Something that has low atomicity today, may have high atomicity a month from now. Similarly, something that represents low ROI today, may represent multiplying ROI in three months. Instead of using it to define fixed, long-term priorities, use it to generally discuss prioritization on a running basis.
Scaling in larger organizations
- The model can be adapted to larger orgs by treating each product team’s domain as a separate spectrum line. Opportunities that will have a multiplying affect across multiple teams will be made obvious.