Stop Confusing Output and Outcome
When you add a shiny new feature to a product you’re producing some sort of “output.” This is what your manager sees. They’re happy when that shiny new thing looks good, works, and is delivered on time.
Not all outputs are equal. Some should never have been created in the first place. Outputs themselves are not important. What a team should be measuring is the outcome they produce. Simply put: what benefit (value) does the feature bring to people?
A Classic Case of Tunnel Vision
We often fail in creating meaningful outputs that produce actual outcomes. You could blame our tunnel vision for that most of the time. We’re so busy focusing on the final output that we forget the bigger picture. Here’s an example of one such fruitless debate:
**Person A:** We need to make it possible for people do `action X` on screen Y. Let’s have a button that could open a modal so you can do that.
**Person B:** Sounds good! But is a button the proper thing for this?
**Person C:** Yeah, and a modal might be too heavy on screen Y.
**Person B:** Yeah, why is it on screen Y do begin with? Screen Z is a more natural place for this stuff.
**Person A:** It should be a button. And a modal isn’t too heavy. We could have it on screen Z as well I suppose.
**Person B:** I still don’t think it should be a button. How about…
And the argument about the desired output continues on.
The team is completely missing the mark. The discussion should’ve been centered around this part:
“Make it possible for people to do
action X.”
That’s the desired outcome. That’s the benefit. You need to start from there! But nobody in the scenario focused on that.
Indeed, nobody even challenged the notion that there’s any benefit to making action X possible!
Person A did not present a compelling case for why the feature is needed. Yet, the team is already locked in a argument over the implementation of the feature.
An Alternative Scenario
What they you need to do is:
- Confirm that people need this outcome (benefit.)
- Investigate how it will help them.
- Weigh the cost vs benefit of producing this output and assign a
priorityto it.
In the end what should happen is that the team scraps the whole thing if it’s not needed. Otherwise the task is pushed to the appropriate person for ideation and design.
If the outcome is truly desired by people using the product, then the product person (designer, manager, whatever) will use their expertise to advance things further. They will write a specification of the feature, create wireframes, and prepare the rest of the inputs for the development stage.
**Person A:** We need to make it possible for people to do `action X`.
**Person B:** Why is that? Did we do our research?
**Person A:** Yes! This is based on our last round of usability testing. 20% of people spend a lot of time navigating back-and-forth between screens Y and Z.
**Person B:** Ok, then this would be a good boost to the overall experience of our product? Hey `Person C` is this within the scope of what we can do this month?
**Person C:** Yes. I imagine the development team could implement something like that next week.
**Person A:** Great! I will work on further specification and design, and then pass it on.
Or perhaps it could go the other way:
**Person A:** We need to make it possible for people to do `action X`.
**Person B:** Why is that? Did we do our research?
**Person A:** Not really. But I’ve used the app yesterday and noticed this will likely bug people.
**Person C:** Development of this feature will take two weeks. Not counting QA.
**Person B:** I don’t think we can commit resources until we know that `action X` it’s worth doing.
**Person A:** You’re right. I’ll add this to the list of things we need to watch for during the next phase of customer interviews and usability tests.
Either way, we’re not wasting time. We’re focusing on what’s important.
Lean UX
If I had read Lean UX by Jeff Gothelf earlier in my career, I would have figured all of this out much sooner. He sums it all up pretty well in this opening words for Chapter 3, “Vision, Framing, and Outcomes.”
Lean UX radically shifts the way we frame our work. Our goal is not to create a deliverable, it’s to change something in the world — to create an outcome. We start with assumptions instead of requirements. We create and test hypotheses. We measure to see whether we’ve achieved our desired outcomes.
The Road to Understanding
To really understand what makes an outcome desirable, you have to get out there and talk to people. If you already have a product with a userbase, then this should be easy to accomplish.
Setup interviews, respond to questions, invite them to fill out a form etc. In short: make it easy for them to constantly provide feedback.
The process isn’t the same for every industry, so you have to do your homework.
Everyone on Support
Recently, I read through the Basecamp employee handbook. They have a really cool activity called “Everyone on Support.” It boils down to everyone on the team doing one shift of Customer Support every month or two.
Talking directly to customers all day helps us realize what’s wrong, what’s right, and what’s utterly confusing about Basecamp.
Final Notes
The TL;DR
If you mess up your focus and don’t provide good inputs, then the engineers will produce output without any valuable outcome. This turns your team into a cost center, rather than a place of profit. Do your homework right, prioritize, and take the time to talk to your users. Do that, and you will not fail.
Technical Debt and Refactoring
The advice given here does not apply to tasks like fixing technical debt or refactoring code. These activities do not produce “features.” They do not provide any direct outcomes for the people using your product.
I’m still working hard on gathering my own thoughts on this issue. If you have a good resource on the topic, feel free to send it to me.