How do we measure the success of a project? It’s a simple question, but the answer will have a profound impact on product planning. Usually, the responses fall into two categories: outputs and outcomes.
The difference is subtle. In any product launch, you have the feature you’re making (the output) and the problem you’re trying to solve (the outcome). Which is more important for product teams?
People are naturally drawn to immediate gratification, which can be satisfied by measuring outputs. Outputs are tangible. Outputs are exciting. Meanwhile, outcomes often require more upfront effort, are harder to report on and take longer to measure. It’s easier to be seduced by provocative outputs, such as creating newfangled tech, than passionate about solving frustrating problems. But focusing on the output could be an exercise in Sisyphean futility when the outputs don’t serve the outcome and the product goes nowhere, like a hamster on its wheel.
Built In Chicago put this question to a panel of local product experts and the response was unanimous: outcomes eclipse outputs across the board. Read on to discover why these local product pros use outcome-focused planning with their teams.
Outcomes guide good unit testing.
“It took me a while to learn that outcomes, not outputs, are more important to unit testing. We always hear about 100 percent unit test coverage, but I’ve realized that this is an output-driven requirement that doesn’t satisfy the true outcome desired, which is minimizing bugs in the codebase.
Now my mantra is: ‘Test every line that matters.’ We ensure really good coverage for functions that are called frequently, highly visible, particularly tricky or known to have previous bugs in them. When we focus our testing we achieve our desired outcome of reducing the bugs without spending excessive time testing components that aren’t important.”
Jason Burich is a senior director of mobile engineering at Bounteous, a digital experience consulting firm.
Customer outcomes reign supreme.
“There’s nothing worse than pouring your heart into a feature that no one uses, and it’s almost a rite of passage for a growing company to accidentally build something useless to understand what’s important. We’ve grown and adapted from these experiences, and now approach our outputs as a means to a more important end: customer outcomes.
We’ve invested heavily in our user research team and actively vet our product ideas with real customers. Oftentimes this greatly changes what we build and helps ensure that Reverb evolves alongside the musicians who rely on us.”
Andy Fate is a product manager at Reverb, an online music marketplace.
Outcomes guide teams through creative conflict.
“Outcomes are more important than outputs. Our team recently redesigned our landing experience. We wanted to create the newest interactive design and solve all possible use-cases. After venting our excitement, we asked thoughtful questions about outcomes. We realized most of the insights from customers were, ‘I don't want it to look like the 1990s.’
Customer insights helped our team cut through the noise. We were able to negotiate through every creative conflict to laser focus on solving the crisply defined problem. Our success was adoption, and we avoided the motivation loss common among teams that solve for output over the outcome.”
Sai Swaroop Sanagavarapu is a senior product manager at Club Automation, club management software for businesses such as athletic clubs and wellness centers.
Outputs are a red herring in product planning.
“Over the past year, HealthJoy started using objectives and key results to drive planning. When you first implement OKRs, teams often focus on outputs and lose focus on the impact to members. In recent quarters, there has been a greater emphasis on OKRs being outcome-focused. This has led to top-down alignment and improved collaboration between product and engineering. Once you’ve defined your product outcomes, it’s easy to tell the story of why we are building a product and how we are creating positive outcomes for our members.”
Brian Fanslau is a group product manager at HealthJoy, a healthcare benefits platform.
Outputs should serve outcomes.
“Outputs are secondary and should only exist if they serve the outcome, not the other way around. For example, let’s say you want to bring a product to market in six weeks, with 30 transactions in the first week. Also, team members should enjoy the process, enjoy working together and share ownership in the success.
Once the outcome is defined, the team can figure out the outputs required to achieve it. If the product team produced all the outputs but the outcome was not achieved — the product didn’t ship and everyone was miserable — then the outputs are not serving the outcome.”
Randy Janzen is a product manager at Arrive, a mobility and parking software.
