What is value optimised development?

At Legl we try to be purposeful with the decisions we make when it comes to what we build and how we build our product. One practice we’ve adopted to help us to do this is something we call Value Optimised Development (VOD).

This refers to the process of developing software or a feature in a way that maximises business value in the shortest possible time.

It is not just about writing code, but also about thinking through the necessary steps to deliver value to the customer.

The initial value delivered may not be a complete product, but it is working software. Think of it in regards to the Pareto principle. We prioritise the part that solves the main problem we need to solve. Most of the later increments focus on improving that experience but that doesn’t mean the initial increment is of low quality. 

By focussing on solving the main problem first, we can assess whether we’ve built a good solution. We can then monitor its use remotely, or even better, get direct customer feedback from our cohorts. This approach gives us the best possible opportunity to change direction and ensure we build the right product, with the least amount of effort.

Why we decided to follow VOD

Every company will always have long-running projects, the solutions, features, and products that they want to deliver to improve useability, expand functionality, or to upgrade systems and services. By focussing on the most valuable part of those projects — what the user wants and expects — Legl maximises our time and resources by focussing on the things that matter, our clients. 

For instance, the Beta phase of our latest GenAI feature, Legl Assist — being such a novel and groundbreaking approach to client due diligence — helped us attract new customers interested in staying ahead of the AI curve. That, in turn, helped us to gather enhanced feedback that improved the feature before it was rolled  out to the entire platform and customer base. This approach also means we don’t spend unnecessary time over-analysing our assumptions and debating features — we rely instead on value.

The power of this approach is the flexibility it offers whilst banking value as early and frequently as possible. This is not an MVP within the classic definition of that term — something that emerges at the beginning of a project — but rather a new type of MVP that emerges during the process of building a product. 

Benefits of following VOD

Being value optimised comes with some assumptions. When we don't actively optimise for value or some other attribute, our individual/team/cultural biases will optimise things for us. For engineers, that typically means we optimise for the convenient delivery of the technical solution. Here is a set of assumptions and how they differ when we are actively value optimised.

How do we follow VOD

Before we can start to optimise for value, we need to have some understanding of what behaviours we’re going to build. We use a variant of example mapping to collaboratively discover these behaviours.

Once we have a good idea of the behaviours we want to build, we can determine how we're going to build them.

We’ll try to illustrate the process with an example.

Value optimised development for a to do list app

Here we’ve listed the behaviours we’re going to build for a personal ‘to do list’ app. The behaviours we want are:

The list of technical tasks needed to build that app might be as below, split into Front End, Back End and DevOps groups, ready for people to pick up and complete.

This is what we used to do, picking up the tasks as the team wanted, building them in the order that was suitable for each engineer.

However with VOD, that changes.

Phase mapping

In this exercise, we divide the project into phases and outline high-level tasks. The first phase typically involves delivering the most valuable feature for the customer. However, in some cases, it may prioritise working on the most difficult or high-risk components. As a result, we proactively address the most important or impactful risks to the project.

Subsequent phases would typically focus on the following, in an appropriate order for the project:

• Developing the capability to better manage the consequences of phase 1.
• Adding secondary and tertiary increments of value.
• Addressing error states.
• Managing other technical risks.

How we determine what is valuable and what goes in the first phase is different depending on how the value is measured for the business.

Using our to do List app as an example

In its most basic form, a value optimised plan for delivering the to do list app might look like this:

In this example, the team has determined that the ability to mark tasks as completed is the most valuable feature. All subsequent phases are designed to make it easier or more effective for users to accomplish this.

Before VOD, if people were to pick up FE/BE/DevOps tasks in the way they believed to be a logical order for building, there would be no guarantee of building any genuine value until everything was completed.

By prioritising value first, even after identifying all the tasks, we can align the tasks with the phases. This prevents us from building too much at once and can help create the following valuable opportunities:

1. We can choose to launch the app at any point after delivering the first phase.
2. We can regularly test useful behaviour throughout the process and make adaptations or change direction as needed.
3. We have a meaningful and easy way to share progress, keeping the rest of the team updated. This can be measured in working software rather than completed tasks.
4. By making useful increments, we have clearer points in the process to pause and make adaptations. This is particularly helpful for managing any known technical debt we've accumulated by optimising in this manner.

The team  also gives an idea when each phase could be launched and how. This is a great way to further the conversation and be more value focussed. It’s amazing the difference dropping a ‘Beta’ or ‘Soft Launch’ sticky note on the board can have to the conversation. Simply dragging the sticky note left and right along the ‘timeline’ and asking “can we launch when ‘this’ phase is done?” and “how should we launch this phase?” can really bring out the concerns people have if it’s too soon (not enough value) or too late (too much technical / product risk).

Does it live up to the hype?

So we’ve all heard about following the Spotify model and how that might transform things for the better and this is no different. So the question you’re all probably asking is… did it really help?

Yes it did!

When building out our first GenAI product, we followed the practice and that allowed us to:

1. Understand very quickly whether we could actually build something useful, focussing on bringing immediate value  to our customers.
2.  Launch an incredibly useful product within a short timeframe, confident it would provide that value. 
3. to pivot when necessary and appropriate both quickly and easily and know almost straight away whether it worked

This is one example, there have been more before and since.

Recommended capabilities to support a move to VOD

In order to make any transition to something like VOD, we’d recommend having the following practices as core parts of how you work:

1. Create feature switching / flags to help make progress without impacting users once code is released or behaviours are launched.
2. Focus on one valuable deliverable at a time.
3. Embed good design principles to allow for changes based on feedback.
4. Observe how the product is behaving when used, from a user, business and technical perspective.

If you’d like to talk to us about how we’re continuing to iterate and improve product design, feel free to reach out to us here: Stuart Crocker.

‍

‍