top of page

Value Engine — How to empower teams to create business value fast

Are we delivering the right value to our customers?

Do any of the statements above resonate with you?

Many leaders and Product Managers are tired of the lack of value being delivered by their teams. It seems that in most companies it always boils down to endless (re)prioritization discussions, missing transparency on what is going on, slow delivery, unstructured discovery and even lack of feature adoption.

The Value Engine brings a solution on how to deal with those challenges. It is a step-by-step guideline to organize the discovery & delivery work of any number of product teams with the goal to generate more value with less effort.

Dual Track

The first important message is that the Value Engine is a DUAL TRACK process. This means: We do not only care about how to deal with the requirements that are already in the product backlog, but we care equally about how to fill the product backlog with the right things. Both tracks (discovery & delivery) run in parallel with the whole product team being responsible for both. Let’s keep this in mind when diving into each step.


The Value Engine is a funnel. Every step aims for reducing the amount of things we execute that do not have enough business value. We want to explore many potential initiatives in the beginning, throw away those with insufficient value as early as possible and only take the effort of the next step if we are still confident in the value of the initiative.

It is important to have a skeptical mindset here. Good experiments need to be designed in a way that they can prove our assumptions wrong. Do not try to validate the potential business value, aim for falsification. Ask yourself why it could go wrong.

Ideas Intake

Organizations are usually never short of ideas and we believe you should not limit the idea inflow. It should be very easy for anyone to come up with an idea to leverage the creativity of the full organization. There is no need to have a full business case yet, but it is important that we have a brief and precise description of the pain or gain of the idea to make it easy to understand for others.

Let us imagine that we are starting with 100 ideas. Now we need to prioritize which ones are the most promising to dig deeper. Keep in mind, we do not prioritize which ones will be executed, only which ones are worth further exploring.

There are many different ways how organizations approach prioritization, such as dot voting, management meetings, OKRs based and quarterly goals, etc. It does not really matter how exactly you do this, but four things are important here:

  • Screen incoming initiative ideas frequently, ideally every week and decide which ones are worth digging deeper and which are not.

  • The rejected ideas need to be removed from the list (good ideas come back anyway).

  • Assign a lead that has the necessary capacity and skills to each initiative that you want to take to the next step.

  • Do not look for perfection yet. The target is not to improve the selection here, but rather to become faster in evaluating the potential of the ideas in the next step.

The “Definition of Done” at this step is to have the Pain or Gain of the initiative described in a short and precise way and a lead assigned that can drive the initiative forward. If these requirements are met the initiative can be moved into the next step called SELECTED. All others need to be discarded already right here and should drop out of the funnel.

Selecting Ideas

Let us imagine 30 initiative ideas made to this stage. Now the assigned initiative lead needs to gather a team that has all skills needed and time to work on this idea. Make sure to balance the tradeoff between having diverse skills in the team and still keeping the team as small as possible, we recommend something between 5 to 9 people.

Give people an idea of how long deep diving into the initiative will take and avoid adding people to your initiative team that cannot commit to freeing up their calendars to make time for working together on the initiative. Otherwise you will struggle to find free common time for the initiative team and end up only pushing your initiative forward every Friday for one hour.

The “Definition of Done” of this phase is to assemble a cross department team to deep dive into the initiative in the next phase. Bring decision makers, creative professionals and engineers to the team! Do not start before everyone has time. Remember: Stop starting, start finishing!

Drafting an Initiative

Let us imagine again that only 20 out of 30 selected initiatives can be pulled into the next step, as for the others the assembled team simply does not have capacity to really focus. This step is called DRAFT and is all about reducing uncertainty. The assembled cross department team now needs to figure out if the idea is:

  • Valuable: Is it something that matches a demand?

  • Usable: Will people figure out how to use it?

  • Feasible: Can we build it with the skills we have in reasonable time?

  • Viable: Does it also work for our other departments (like customer care or the legal department)?

Maybe you know these four types of uncertainty from the famous product consultant Marty Cagan. We like it, so we copied it from him.

So how do we “draft”? There are many different possible discovery methods we can use, like a design sprint, lean inception, workshops, storyboarding, prototyping, and so on. Whatever we use, we should first understand and roughly quantify the pain or the gain we are addressing, then elaborate many different potential solutions and only finally go into details of the most promising solution that we selected. We should at least always consider the following sources of insight:

  • Does it fit the vision & strategy? If not, let’s drop the idea right here!

  • What do our competitors do? Make sure you benchmark relevant other services and get inspired. If nobody is doing it yet, there is probably a reason for it.

  • Deep dive into the data you already have! How many customers are affected?

  • Generate qualitative insights, for example by creating prototypes and showing them to real customers.

Make sure you farm for dissent. Try to find people that have problems understanding your solution design or have improvements ideas.

The “Definition of Done” for this step is to have a clear concept available. You also need to know your dependencies. Who is needed to implement your solution design? Last but not least, you have aligned on key business metrics that will determine the success or failure of the initiative! Make sure you express quantitatively why we are doing this initiative and also which metrics need to be watched to make sure that we do not create damaging side effects.

Hacking a minimum measurable product

Again a share of initiatives should drop out and get discarded during the DRAFT step. Let’s say only 10 make it to the next step as the others turned out to be less valuable or simply not viable. For the rest we now enter the so-called HACK phase.

The goal here is not to create a fully viable product yet, but just something that allows us to see and to measure how our users behave. This could for example be a painted door test or a fake feature on the website.

Keep this phase super short, we are basically preparing our experiment setup here, so we are not learning anything while we are building this hack. We call it “hack” on purpose, because we are willing to create technical debt here and make a lot of tradeoffs to get insights early and cheaply. And as experiments can potentially be dangerous, we need to make sure that we limit their blast radius before we start executing them. Three thing are important here:

  • We need to be able to roll out gradually to only a certain share of users. By this, if something goes wrong, only a small number of users will be affected.

  • Releasing needs to be easy, fast and frequent. If we need to fix something or have insights for improvements, we do not want to wait days or even weeks to release a change. We want to release multiple times a day if necessary.

  • We need to be able to measure the impact of what we are doing — otherwise we do not even know if we create value or damage the company.

The “Definition of Done” of the Hack Phase is what we call a Minimum Measurable Product (MMP):

  • We established a limited blast radius as described above.

  • We are able to track user behavior in the defined metrics.

  • We released an experiment able to prove our initial hypothesis wrong.

Shipping a Minimum Viable Product

In the HACK phase hopefully more initiatives get discarded and potentially only 5 out of 10 initiatives make it to the next step that is called SHIP. Now it is all about improving our Minimum Measurable Product (MMP) step by step into a Minimum Viable Product (MVP). We measure and learn how we impact our users, significantly reducing the uncertainty we had.

In this phase we are willing to produce even more technical debt and improve gradually according to the user behavior. Step by step we can also increase the share of users and with enough users we can also segment into further user groups like new vs. existing or mobile vs. web users.

The “Definition of Done” of the SHIP phase is when we rolled out for 100% of our defined users and our metrics are performing as expected.

Turning your MVP into a Maximum Lovable Product

Maybe only 3 out of 5 from the SHIP phase are not killed and reach the next phase: TUNE. Our initiative does not only need to be viable, but also maintainable, extensible, scalable, secure and compliant. As our engineers already learned a lot about the solution during the previous phases, they now should be able to estimate much better how much effort is still necessary to achieve this. So we can start this phase by making an informed decision if we want to invest this effort to make the solution to a state it needs to have to be considered done. We only want to invest into these aspects as late as possible, after being sure that our initiative really generates the assumed business value.

The “Definition of Done” of this phase is accomplished when we created something that users, developers and other colleagues want to have long-term in our platform and do not see the need anymore for further improvements. This is what we call the Maximum Loveable Product (MLP).


As a result of following these guidelines, we now have developed only the 3 most valuable initiatives into a Maximum Lovable Product and saved the company from making bad investments on the other 97. Finally let’s add some more operational guidelines:

  • Make sure you slice your initiatives right! Each initiative needs to have an individual value contribution. Do not set up initiatives that are just enablers for other initiatives.

  • Value contribution needs to be reachable in a reasonable time. Initiatives that run longer than 3–4 months are problematic and should probably be splitted into smaller ones.

  • While the engineers of a team deal with one initiative in SHIP or TUNE, the product manager and designer should (with engineering support of course) already prepare the next candidates in DRAFT and HACK. (Dual track!)

  • Every team also has some “keep the lights on” work to do. It is ok, if a share of the team’s capacity is distributed to things that are not contributing to any company level initiative as long as this is not exceeding about roughly 30%.

  • We have developed the Value Engine based on our own experience and worked with it already in many different companies to organize product departments with dozens of teams. Trust us: It is a mindset shift and a great tool for coaching that can really create a difference in organizations of any size and complexity. But do not take it too easy. Implementing the Value Engine is not just establishing another kanban board as the one below, it is a major cultural change project for most organizations!

And that’s all about it! Please leave your feedback in the comments or get in touch with us if you want to know more. We would love to get your opinion or experience with these guidelines!


bottom of page