Is your team executing well – a healthy backlog, wireframes, designs, stories, features, an automated test suite – but still not achieving the outcome they're after? Do they even know the outcome they're after? Are they overproducing output and underproducing outcomes? If so, what follows is for you:

According to Jeff Patton, output is "what happens between the idea and the delivery". It's all the stuff that gets produced as a by-product of creating software products. Outcome on the other hand is what comes as a result of the output, but only after we deliver it into the hands of actual users and customers.

Outcome is what we're really after but it can be hard to nail down, so output is often all we get. No team is impervious to the output dilemma. I can guarantee you there's an exceptionally bright, well-intended team who is overproducing as we speak.

So how do we tip the scales back in our favor?

It's Not About Software

The first step is to realize that software is more than features, more than looking beautiful, more than a test suite, more than a backlog. It's more than all of the things we could do.

To quote Jeff Patton again, "Software isn't the point."

So what is?

Solve Someone's Actual Problem

The point of software is to solve someone's actual problem.
As it turns out this is really hard to do.

Many teams make it even harder by diving in head first and building. They start with the most expensive activities without ever validating whether or not they're solving the right problems, in the right way, for their users and customers.

Your hope – and I'm purposefully being presumptuous here – is that people will use your product because it solves their problem better than any other tool.

Before that can happen you need to validate that the problem exists. Not only does it have to exist it has to be a something people want solved.

Too many products and new tech are solutions looking for problems. Just look at practically any Internet of Things product that has been launched. Solutions looking for problems have a harder time finding success than solutions that solve actual problems.

You only expose yourself to more risk and uncertainty when the problem you think your product solves goes unchecked.

A Few Tips You Can Use, Starting Today

If you find yourself or your team producing too much output and not enough outcome, here are a few tips to take with you:

Understand the problem you think you're solving. Everyone on the team should understand the problem you're aiming to solve. If you're not sure that's the case; gather everyone around, start a conversation, find out.

Understand the problem you're actually solving. Your product should not aim to solve a hypothetical problem, but an actual problem your customers and users have. You won't know until you talk to them, or, more importantly, until you listen to them.

There's more to software than code. Sure code is important, but it's also really expensive. There are faster and cheaper ways of determining if you're heading in the right, or wrong, direction; user research, usability testing, and feature stubs to name just a few.

It's futile to go full steam ahead solving an artificial problem.

Build only what you need, i.e, beware of "featuritis." Building features for the sake of features is pointless. They clutter up UIs, take time and money to build and maintain, distract the user from accomplishing their goals, and divert the team away from building more meaningful things.

Sure they sound great, but more doesn't necessarily mean better. Focus on what brings value to your users and make sure you continually learn and test what that is.

Iterate. An iterative process gives you freedom from the shackles of perfection because you know you'll have an opportunity to refine. Iteration is about successive refinement and having a continuous feedback loop.

This loop allows you to inject learning every time you iterate. It lets you make mini course-corrections along the way, which improve your product and strengthen the team building it.

Closing Thoughts

Producing output for the sake of being productive is an easy trap to fall into. In fact, it's incredibly tempting; being productive feels good.

The problem is, that feel-good feeling generally just delays the heart-dropping disappointment we feel when our product fails, miserably.

There are enough circumstances, out of our own control, that may cause our product to fail; we should be striving to eliminate the ones we can. We can do this by understanding our users, the problem we're helping them solve, and the goal they wish to achieve.

When we fail to do that we get stuck with a mess of output instead of the beautiful outcome we desire.

Header image from woodleywonderworks.