A little help on making the tough decisions

We’re confronted with a huge array of potential choices every day. More options can slow us down from choosing, and sometimes halts our decision making altogether (“paralysis by analysis”). Buying a can opener on Amazon? 3,852 results — some with more than 2,000 reviews.

Now add stakeholders, high costs, and even higher stakes, and we’re talking about your product roadmap.

You may have done a great job setting and communicating goals with everyone to align your company on the why of your roadmap, but maybe there’s confusion on what’s next. Sales demands more features while Engineering wants to pay down technical debt. Customer Services wants refinement of features already in place. We found ourselves in this exact situation at our last company with increasing tension around pure innovation — moving the needle with completely new features; baseline features — incremental improvement to existing, well-used features; and maintenance — all the indirect value-add or non-value add work that needs to be done to keep us scaling smoothly. We were losing focus, the team was frustrated, and the product team was struggling to prioritize all the incoming requests.

It was a critical time for us and we couldn’t afford really bad decisions, a slow down, or confusion on the team. We quickly pulled together all the key decision makers and we came up with a way to systematize our approach.

The solution was a framework for helping the product team cut through the paradox of choices, to prioritize the larger roadmap efforts, and to evaluate success. Based on those three broader categories, we assigned all requests and in progress efforts to: pure innovation, baseline features, and maintenance:

High level objective examples in a product decision framework

By tagging features in JIRA based on the framework and adding up bugs and chores, it added a new dimension to our throughput. We collected the data in spreadsheets, so we could report out monthly on how close we were tracking to our framework commitments.

The conversations immediately changed, and it gave our team a narrowed lens and context to review everything with. New feature X requested? How does that fit in our current “budget”? It let us push back on loud voices when necessary, and held us all accountable to the direction we agreed on.

The point isn’t to follow what we did exactly, but reflect on whether you have a well-communicated, agreed-upon framework in place that helps with making the tough decisions that you have to make every day. The aha! moment for us was that a little upfront work, accounting as we went, and sticking to the decision framework paved the way for us to execute much more efficiently. And like most aha! moments, it seemed obvious after the fact.

Dave Shanley is the co-founder of Notion, focused on helping teams build, measure, and learn with data.

If you liked this article, click the ♥︎ to help promote this piece to others.

Have tips or suggestions on how to build a data driven team? We’d love to hear them. Comment below or reach out on Twitter.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.