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. It is based on how the designer wants the consumer behavior to change while using the product.
What is the difference?
In traditional waterfall or sprint-based software development, the emphasis is put 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 features that are going to be released 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.
The traditional way to feature-based product development
According to Josh Seiden, an outcome is defined as the change in human behavior caused by the change in a product or services. The product designer does not write a list of features to be implemented; instead, it creates a list of desired results based on changing consumer interaction with the product.
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. This 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.
Lateral thinking enables you to find a new path by bending the rules
Advantages of Outcome-based planning
Without knowing the future, how do you know which of the features you implement will be liked and embraced by the customer?
With traditional waterfall/scrum-based programming, the feature that needs to be implemented depends on the product manager, company owner, or senior developer's feedback. Marketing and other stakeholders come into the process after the product is implemented. This often does not provide the desired result.
Here are some of the steps on how you can do outcome-based planning:
From the onset, involve all the stakeholders of the product. Instead of product features, the requirements are now based on user behavior changes that will increase the organization's revenue. 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 outcomes. 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 any stage of product planning, development, marketing, and customers can be the stakeholders. At this stage, it is useful to get representatives from every area.
There are many ways to involve the stakeholders at this stage. This involves brainstorming, storyboard, card sorting, etc. For a good article on how to do this see: Focus Session: defining design requirements with stakeholders
Each cycle of development in outcome-based planning is created with a minimal development approach. This means implementing the simplest deliverables that can be tested for the outcome metrics previously set by the stakeholders. This 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. By testing each iteration of development and comparing it with the desired outcome, only relevant features are implemented. It is also possible to find some outcomes 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 goals. This lead 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 as an 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:
- Make changes to the customer portal to get 20% more uses from our users over the next month.
- Increase the conversion rate of the e-commerce page by 10%.
- Make 15% more users who visit the free version of the product signs up with the paid version. Long term goals could be:
- 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 is the relationship 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 does 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.
We also created an Outcome-based design template to provide a starting point for your Outcome-based design.
What to avoid
- 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.
- Do not complete the whole product planning first; instead, get to the outcome cycle, planning, implementation, and measurement.
- 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.
- Do not focus too much on technology while planning outcome-based product development. Find the simplest path to reach your profitable outcomes.