Feature Teams vs. Empowered Product Teams
Many companies inadvertently create feature teams that serve the stakeholders of the business, churning out feature requests but not accountable for the actual outcomes. The feature team’s backlog more or less reflects something like, Customer A wants this, Customer B wants that, Internal Team C wants this, let’s go go go! But, often, that doesn’t go anywhere great… leading to a frankenstein product with an incoherent set of features that are hard to maintain and get orphaned over time.
Instead, at Ellevation, we work to cultivate empowered product teams that solve hard problems for customers in ways that work for our business. This means teams are responsible for the overall outcome, optimizing value for customers and for the business overall.
Choosing Which Problem to Solve
The Silicon Valley Product Group has a great article on output-focused feature teams vs. outcome-focused product teams, but perhaps the biggest difference between them is the process of problem selection. In fact, the most important job of an empowered product team is choosing which problems to solve. This can be hard! And, the way we evaluate problems depends on the type of decision we are making.
- At the highest level, there’s the work of choosing which high-level problems or opportunities to pursue.
- For example: Should we focus on helping specialists effectively set goals for their students, or should we focus on helping administrators easily send translated letters to families?
- This essentially comes down to comparing Return on Investment – choosing the problems that offer the most potential value for our customers and our business relative to the effort required.
- Then, once we make a bet on a specific opportunity, it’s a matter of choosing the order of which problems to solve on the path to that outcome.
- For example, let’s say we’ve decided to make a bet on helping administrators send translated letters to families, but within that initiative what do we prioritize first: mobile usability, printing capabilities, something else?
- For this, we lean on risk ordering and steer into the high risk areas first. (We’ll save this topic for a future blog.)
A Framework for Evaluating Problems
For high-level problem selection, evaluating Return on Investment sounds easy enough, but any product leader knows it’s not that simple. It takes real digging to unpack a problem, interrogate the value, consider how to approach it incrementally, and ultimately decide whether to prioritize it.
We’ve developed a series of questions to help with this - going beyond the common framework of Reach, Impact, Confidence, and Effort - to help empowered feature teams choose which problems to solve.
Value
The most important thing we dig into is value - how important is this problem, really, for our customers and our business? This encompasses considerations of Reach and Impact, as well as the question of Relevance to other current business priorities.
As a quick and telling heuristic for value, the first question we often ask is, What’s the bad thing that happens if we don’t solve this problem. We ask this so often that we’ve contemplated buying t-shirts emblazoned with The Bad Thing for all of R&D. Often the answer to this question is simply, Well… actually it’s not so bad…. Some customers would have to rely on an alternate workflow, and they might be annoyed, but that’s small potatoes compared to other problems we could solve. And, for what it’s worth, knowing the answer to this question also makes tradeoff conversations much easier.
- The bad thing: What’s the bad thing that happens if we don’t solve this problem, or if we defer it till later?
- Reach:
- How many customers are impacted by this problem? How much ARR is associated with these customers?
- How many and which types of users are impacted?
- How frequently does the problem impact users?
- Impact:
- What’s the impact of this problem on customers?
- What are their workarounds or alternate options?
- What’s the impact of this problem on the business? (would solving it drive revenue, reduce cost, achieve some other business goal?)
- Relevance:
- Does solving this problem accelerate or complement other business priorities? Or does it contradict or complicate them?
Importantly, when assessing value, remember to be skeptical about:
- General feedback like “this is a sales blocker” or “this will make customers” without actual validation or details
- Claims that specific features are required for “compliance”. Customers interpret compliance requirements differently, and many possible solutions can get at the same requirement, so we can’t take it at face value when we hear “I need X feature to be compliant”.
Confidence and Effort
When choosing which high-level problem to solve, we want to be confident that it’s both a valuable problem and that we have the ability to solve it with reasonable effort. Building incrementally - or shipping to learn - helps us both increase confidence and reduce effort. More on that another time, but for now, here are few key questions we consider:
Confidence:
- How confident are we in the value of the opportunity? (We often lean into user research - as we described in a recent blog - to build confidence in the value of the problem and generate ideas for how we might solve it.)
- How confident are we in our ability to solve this problem?
- How can we build confidence?
Effort:
- How much effort is required to solve this problem?
- Or, a much better question: What’s the smallest increment that might at least partially address the problem and allow learning?
Return on Investment
Taking all the questions above ultimately allows us to assess the likely Value divided by Effort, or the potential Return on Investment. But it’s not the ROI of a single problem that matters, but rather how the relative ROI of various potential problems stacks up.
Relative ROI:
- What’s the ROI of this opportunity - the amount of value for customers and value for our business that we get for the investment?
- Relative ROI: How does the ROI of one problem compare to the ROI of other problems we could work on?
These are not easy questions to grapple with, but they make for far better product decisions, and far more fun and meaning for the empowered product teams that make them.
