We’ve all been groomed to measure our work by output. That means defining success as shipping a product, feature or bug fix to customers. To ship more frequently, many of us have adopted agile methodologies.

But for many teams, practices of releasing software to customers are still about a decade behind. Saddled with yesteryear’s labor-intensive process, it’s no wonder many companies are shipping updates to customers only once a week at best.

The disruptors of today gather analytics on customer behavior one day and ship changes to capitalize on those insights the next. They focus on a new definition of “done” that has nothing to do with coding output and everything to do with making a significant impact for the customer.

Welcome to the brave new world of outcome-driven development. Here, “done” means delivering measurable value, not simply completing user stories.

Take a page from Tesla
Sure, shipping features and fixes makes us feel accomplished. But if what we shipped doesn’t make an impact for the customer or the business, then what’s the point? It’s important to listen and respond to feedback until the desired outcome is achieved.

When Tesla first went to market, its cars didn’t exhibit the familiar stuttering motion when the anti-lock brakes kicked in. Customers called to complain, thinking their brakes were defective. Overnight (literally), Tesla’s engineers deployed a software update that made the anti-lock brakes stutter. The complaints disappeared and customers were happy.

Without a tight loop from concept to code to customer, plus mechanisms to get realtime feedback and usage statistics, development teams can’t keep up with customer expectations. Teams must be able to release, measure and make decisions fast enough to inform what they’re working on next week – not next quarter.

Outcome-driven development is inherently agile
The outcome-driven team works from a roadmap expressed as a series of goals, rather than a set of features. It is prioritized and punctuated with milestones just like a traditional roadmap, but the difference is that nobody knows how many releases it will take to reach those milestones. The path to reducing churn by 3% might include shipping a dozen experimental updates before finding the one that moves the needle. Or, it might happen in one fell swoop.

At a high level, the process looks like this: Teams ship new code to production constantly, using feature flags that let them silently toggle new functionality on or off to control what customers see. They progressively roll out new functionality to customers, monitoring how the change affects user behavior and impacts relevant metrics. That feedback then determines the team’s next steps.

Plan, build, deploy, listen, repeat. Sound familiar? It’s classic agile.

Effectiveness is the new efficiency
Like most changes, culture presents a bigger hurdle than technology.

Executives traditionally measure productivity by what’s been completed, shipped or done. But in a world where customers will drop companies like a bad habit, satisfying customer demand better than anyone else is where competitive advantage lays.

Instead of measuring outputs of effort (hours worked, user stories shipped, etc.), the outcome-driven development team sets goals measured in results: reduced churn, improved Apdex score, more users returning each day, etc.

Not only do outcome-oriented goals speak to business value, there’s room for the responsible teams to decide exactly what work should be done. Shipping a new feature might be the best way to reduce churn, but then again, improving the existing onboarding flow might be even more effective and potentially cheaper.

So what’s the catch?
The key to outcome-driven development is being able to make a relatively small change, see if it makes a positive impact, then double- down on it if it does.

It’s impossible to do this fast enough if deploying to production takes a full day. So while the cultural shift is harder than the technical evolution, both are necessary for success.

On the culture front, teams should start by re-articulating their quarterly goals in terms of measurable results (not outputs of effort). The objectives and key results (OKRs) framework for goal setting is really useful for this: we have been using this at Atlassian for a few years, and it’s definitely helped re-orient us toward outcomes.

Then re-frame the roadmap as a series of measurable outcomes instead of features. Think about customers in terms of their “jobs to be done,” and figure out ways to meet their needs.

On the technical side, moving to outcome-driven development means investing in the continuous delivery loop:
Optimize it until deployments happen daily (or better).
Implement feature flags to introduce change to a fraction of customers before rolling to everyone.
Add analytics to surface customer feedback programmatically.
Incorporate that feedback regularly as part of decision-making process.

It’s a massive leap of faith (but worth it)
The technical transformation that outcome-driven development requires means putting some features on the back burner, and the cultural shift from measuring user stories shipped to measuring results achieved can be scary.

This is where trust comes in. Managers have hired great people and now need to push them out of the nest. Teams with the autonomy to find the best solution will pursue it passionately and take pride in their results.