What is Outcome-based software development?

Reading Time: 5 minutes

Free: Outcome-based design template.

This article describes how Outcome-based software development can provide the desired result for all the stakeholders compared to the traditional feature-based product development.

With this methodology, the designer focuses on how they want the consumer behavior to change while using the product.

What is the difference?

In traditional waterfall or sprint-based software development, the emphasis is on churning out features as quickly as possible to meet market demands. Productivity gains are achieved by following a well-defined methodology to develop, test, and release product changes.

Most companies plan software development based on the released features in quarters, months, or weeks (based on sprint). In the end, it is often difficult to predict whether users will use these features when presented to them. In contrast, Outcome-based design is a different way of collecting, testing, and implementing the requirements to make a successful product.

Fig: The traditional way to feature-based product development

An outcome is defined as the change in human behavior caused by the change in a product or service – Josh Seiden

The product designer does not write a list of features to implement; instead, it creates a list of desired results based on changing consumer interaction with the product.

Fig: Outcome-based product planning and development

Let’s take an example of an e-commerce company that finds that most of its customers are not completing the payment pages’ checkout process. Feature-based development methodology will ask to make the user interface more friendly or add more steps. In contrast, outcome-based development will look into all the possible options to make more users take the desired action. For example, it may include providing workarounds or on-screen help, thereby eliminating the need for expensive development.

The outcome-based design takes advantage of the idea of Lateral Thinking popularized by Edward De Bono. It shows there are more straightforward ways to solve problems if one is willing to bend the rules.

Fig: Lateral thinking enables you to find a new path by bending the rules

Advantages of Outcome-based planning

How do you know which of the features you implement will be liked and embraced by the customer without knowing the future?

With traditional waterfall/scrum-based programming, the implemented features depend on the product manager, company owner, or senior developer’s feedback. In addition, marketing and other stakeholders come into the process after the product implementation. Unfortunately, this often does not provide the desired result.

Here are some of the steps on how you can do outcome-based planning:

Team involvement

From the onset, involve all the product stakeholders, for example, by basing the requirements on user behavior changes that increase the organization’s revenue instead of product features. In this process, all the involved stakeholders will have their input.

The outcome makes it easy to communicate with people with different backgrounds as each stakeholder is somehow involved in the results. In contrast, some teams like sales and marketing may not get interested in feature-based planning until some version of the product is released.

All the people involved with product planning, development, marketing, and customers can be the stakeholders. At this stage, it is helpful to get representatives from every area.

There are many ways to involve the stakeholders at this stage, for example,  brainstorming, storyboard, card sorting, etc. For a good article on how to do this, see: Focus Session: defining design requirements with stakeholders

Measurable outputs

Each cycle of development in outcome-based planning is created with a minimal development approach. It means implementing the simplest deliverables that can be tested for the outcome metrics previously set by the stakeholders. Thus, it keeps the development in control and maximizes the acceptance of the product.

Low cost of design and development

Outcome-based planning avoids going into the numerous cycle of feature releases. Instead, only relevant features are implemented by testing each development iteration and comparing it with the desired outcome. It is also possible to find some results that can be met by simple user education.

Fewer features and more satisfied stakeholders

Outcome-driven planning implements fewer features that satisfy the initial outcome goal. As a result, it leads to bringing a usable product into the market faster.

How to do Outcome-based planning

• Write down the short and long time vision of the product. This vision should be written in terms of outcomes and not by the future features we will implement. The creation of the product vision can be done using a shared document. You can also use a shared product board, as explained by Roman Pichler, on his blog.

• This kind of structure can easily be created in a spreadsheet-like Google Sheet and shared with the stakeholders. Once done, this will provide input to create an Outcome-Based Roadmap. Let’s take a short example to illustrate this. Suppose you are working on improving an e-commerce site. Your top-level outcome could be the following:
  1. Make changes to the customer portal to get 20% more uses from our users over the next month.
  2. Increase the conversion rate of the e-commerce page by 10%.
  3. Make 15% more users who visit the free version of the product sign up with the paid version. Long term goals could be:
  4. Increase the number of times the new users log into the system by 50%.

• Involve all the stakeholders to provide input on what they want to see as outcomes of the product.

• Make a list of all possible outcomes that you want to see in the product. Then filter the outcomes that agree with the product’s long-term goals and those which are profitable. Also, note down what product feature changes you need to make to achieve these outcomes.

• Brainstorm and analyze how realistic the relationship is between product changes outcomes and profitability. In most cases, you will find it hard to predict the profitability and outcome at this stage. Divide the outcome into small parts and take the simplest ones whose outcome is measurable and implement them. Put together all the outcomes and prioritize them in terms of the ones that have more revenue opportunities and user delight.

• Implement the outcomes and measure their effectiveness.

• This measurement and understanding enhance the relationship between the outcome and product changes and implement the next measurable outcomes. Be ready to change the direction of the outcomes that do not match the expectations.

• Continuing this process will reshape the product that will satisfy all the goals of outcome and profitability.

• If necessary, create sprints and OKR for the product development based on the above iterations.

At OfficeClip, we have started using outcome-based product planning and development. In the future article, we plan to provide a case study with measurable results.

What to avoid

1. Do not make assumptions on the viability of an idea that is expected to create an outcome. The basic tenet of outcome-based development is to measure and validate each outcome to make a complete product.
2. Do not complete the whole product planning first; instead, get to the outcome cycle, planning, implementation, and measurement.
3. Do not always let the deadline control the development of the final product. In outcome-based development, each iteration needs to be measured and validated. The time taken by this is usually compensated by the quality and efficacy of the intermediate release.
4. Do not focus too much on technology while planning outcome-based product development. Find the simplest path to reach your profitable outcomes.

Slides