When Convex works with clients, we frequently talk about the differences between outcomes and outputs, because focusing engineering and product teams only on outputs severely hampers their effectiveness. Why? Instead of hiring smart, talented people and letting them tackle problems and run at high speed, you are narrowly prescribing the solutions on which they should work. This is problematic for two reasons:

– They are always waiting on leadership
– It assumes that leadership knows best how to solve problems

Let’s suppose your company allows users to create and send invitations to events. Further, let’s suppose you have good numbers of users creating invites, but the vast majority of users who visit the site never send one.

Leadership quickly decides that the issue is the recipient list upload function: users likely don’t have a CSV of recipients readily available, so they must be allowed to connect their address book. You give the engineering team the directive to make this change, and they dutifully vanish for a few weeks before reappearing and releasing the new feature.

After the feature is live, however, the hoped-for increase never comes. In fact, the percentage of users sending invites goes down. Frustrated, leadership decides on another solution and asks the engineering team to try yet again.

As you can imagine, the above scenario results in boatloads of wasted effort, and in many cases the company doesn’t have much runway to play with, so insolvency creeps ever closer.

This is a common result when a company focuses on outputs. [Aside: there are circumstances in which it’s helpful for a business to focus their engineering team on outputs, but those circumstances are very narrow and don’t apply in most cases.]

What happens when we instead focus on outcomes?

Instead of leadership deciding that they know the best solution to the problem, let’s suppose they focus the product team on an outcome: increasing the number of sent invitations 10X.

This gives the product team direction while allowing them the freedom to experiment with various means of achieving the outcome. Product teams with good discovery habits (the subject of another post) will have deep context of user needs, so the team will be in an excellent position to experiment and iterate rapidly to achieve the desired outcome.

Leadership can then monitor the team with regular standups to check on the experiments that have been conducted so far, what has been learned, and which experiments are planned next. This can be taken a step further by using OKR’s, which align your product team to the desired outcomes and make weekly or biweekly check-ins straightforward.

This allows your product team to leverage their deep knowledge of users to move quickly and unencumbered to business-beneficial outcomes.

Instead of handing your teams outputs to produce, give them outcomes to pursue, and you’ll be rewarded with faster progress, much better results, and a more manageable runway.