Outcomes Over Output

Product roadmaps often present as a time-based list of feature deliveries. We’ll build A by X, then B by Y, then C by Z, …, on and on we go.

More advanced companies call them solutions. You might even have a Solutions Roadmap. These companies at least orient around the problem, recognizing the difference between a feature and a solution.

Features are outputs, solutions have outcomes.

After understanding this difference, the next step is to embrace the goal of building as little as possible to solve the problem at hand. Intuitively, this makes sense. You’d obviously rather invest $1M solving a problem than $5M.

But we’re product managers, designers, and engineers. We produce. So intuition be damned, we’re going to ideate, design, and build some amazing stuff.

Once we realize the goal of building as little as possible, we can orient our planning process around building less. To my mind, this aligns well with the Build-Measure-Learn model presented in The Lean Startup.

Engineering managers and product managers pride ourselves on delivery. Did the thing get built on time, on budget, on spec? That’s how we judge our own performance and also how our managers typically judge us.

Instead, we should be measuring ourselves against user and customer behavior changes. Email open rates, user interactions, account creations, and the like.

Orienting a team of producers around outcomes is difficult. Equally difficult is retraining yourself to be outcomes focused.

When feature requests come in from users, there isn’t much we can do about it. Users will be users.

But from internal staff (notably Support), I recommend shifting conversations about features to conversations about problems. I helped facilitate this change a few years ago within my organization and have seen these benefits:

Company-wide, we are orienting around solutions, not features. We can ask what the desired outcomes are, not just the desired outputs.

1. Support doesn’t feel on the hook for solving the problem
2. Designers and engineers don’t feel obliged to reject an idea that won’t work for various UX or technical reasons
3. Product managers can think more conceptually and tie together previously unconnected ideas

Your product may have a long list of features, but that doesn’t mean each feature is delivering value. By extension, the features you currently have planned will not all deliver value. It’s your job to figure out which features customers will value the most then use that information as part of your product roadmap and prioritization process.

Unsaid is that you should also kill off features which aren’t providing value. These infrequently used features often clutter the UI and increase the cognitive load for users. Unused features often create negative value.

You should have a hypothesis about each new feature on your roadmap. What customer behaviors will change if they are provided this feature?

Testing your hypothesis may not require actually building the feature. Instead you might rely on interviewing customers or building a clickable design prototype.

Software engineering is expensive and you can optimize your efforts by testing your hypothesis earlier in the design and development process.

Key results should leave out how to deliver on those outcomes so that your people have the freedom to experiment. This autonomy will aid in their sense of ownership over the key result, whereas dictating how the work is to be performed absolves them of accountability.

May projects are named around outputs like “Redesign Homepage” or “Build Notifications”. Focusing on outputs pins the team to a specific deliverable and holds them accountable toward that deliverable, regardless of results.

These projects could be better named by focusing on the outcomes. “Increase Homepage Conversion Rate by 10%” would be a good project name, which leaves open the outputs and enables the team to apply divergent thinking aimed at doing as little as possible in order to deliver the desired results.

Holding people accountable for outcomes leads them to less guessing and hand-waving about the success of features. They dig into the data to guide their product management and engineering decisions.

For engineering leaders, what’s important is getting the data into the hands of your engineers. Too many teams outsource their data-oriented thinking and analysis to Data teams. Meanwhile your software engineers, who are incredibly smart and often highly analytical people, are left on the sideline where their data skills go unleveraged. Not using software engineers to look at data is a huge missed opportunity for product development organizations.

The counter argument is that the time of your software engineers is too valuable to have them digging into the data. Sure, there is a limit. But the biggest waste of time and money is having software engineers building things that nobody wants and won’t produce the results your business needs.

At my company, I built a simple data dashboard tool leveraging a theme from Themeforest that can connect to our databases. Our engineers can quickly build visualizations using a few lines of code, where their analysis covers enough to be directionally correct in understanding customer app usage patterns.

Your bug and feature ticket system probably has hundreds or thousands of requests that are unlikely to ever be prioritized because addressing those issues would not yield meaningful results.

Delete those zombie tickets and start fresh. Move your team past outputs thinking and towards outcomes thinking.