This center section of the VDL is meant to be continuously updated as the product team discovers new information. Product Teams should first start with defining the problem statement. One statement for the business problem the team wants to tackle and another for the customer/user problem if known. 

Product teams need to keep track their assumptions for business outcomes they want to define including what success looks like, what do they specifically want to measure and how will they measure it. In addition, assumptions around customer/users outcomes and benefits need to be defined.  Product teams will use these assumptions to create focused Hypotheses statements to test. 

Product teams can leverage an existing canvas such as the Lean UX Canvas from Jeff Gothelf.

Product-Market Fit

This is the purpose for creating products as we as product people strive to achieve this product-market fit. Product teams must build a product that creates significant customer value, meet real customer needs and do it in a way that is better than the next best alternatives. One of key goals of VDL is to create the smallest possible experience that meets the needs of a specific market of customers. As part of the Product-Market fit, product teams need to identify target customers as well as the users and buyers to focus on first, so they are clear on who they are solving for as they go through the VDL.

Discovery

Discovery is at the heart of the VDL. This is where a cross-functional product team typically consisting of a product management, user experience design, and engineering work collaboratively to discover solutions that customers will love, but also work for the business. Strong product teams are empowered and accountable to solve hard problems. These empowered Product Teams act as missionaries to find new opportunities, Jobs To Be Done (JTBD), new ideas and real customer problems to solve. They behave with an open mind, have empathy for their users, think of themselves as Explorers & Scientists, and are always trying to improve their learning velocity. The overall goal of discovery is for the product team to quickly identify potential solutions and this happens concurrently and continuously with the delivery work in Design and Experiment.

Validate High Risks

As part of the broader Discovery work, product teams must validate risks upfront. This validation acts as the guardrails to keeps the product team focused on building the right solution. As the product team iterates through the Value Discovery Loop, they should be moving from doubt to clarity and should assess their confidence levels often. The key risks to validate are:

1. Value Risk -will customers buy it?

2. Usability Risk - can the users figure out how to use it?

3. Feasibility Risk - can engineering build it with the the time, skills and technology available?

4. Business Viability - does this solution also work for our business as a whole?

Design

In the Value Discovery Loop, Design happens concurrently and continuously with Discovery & Delivery.  Design is broken out separately in VDL to emphasis the critical role it plays.  The goal Design is to create the smallest possible experience with the least amount of work to solve what was discovered by the product team. 

Experiment

Experimentation is part of Delivery. The goal is to test many prototypes, product ideas and experiences every week from the work that comes out of design.  The product team will test assumptions and hypotheses during experimentation to learn as much as they can about what works and doesn’t work.

Feedback

Learning from customer interactions is one of the most important part of VDL. This is where the product team does their User Preference testing and takes a step back to see what resonates with users, determine what’s working and what is not, review key assumptions & hypothesis in order to build confidence. The product team will skip building shippable software until they are ~70-80% confident they have the right solution. 

Build

Building production quality software is the most expensive way to test ideas and should be avoided until assumptions, hypothesis, risks have been validated by the product team and ~70-80% confidence is achieved. Engineering can start to build quality shippable software once the product team has validated the product or features are worth building.

Release

The key to releasing software is to start small, then scale. Set up small pilot groups so these users can experience the software first hand. The product team will continue to loop around the Value Discovery Loop as quickly as possible to measure and learn, then ultimately moving their software to beta and finally to releasing to production as they scale the number of users who can experience their solution.

Measure 

Use both quantitative and qualitative approaches for your user confirmation testing. The entire product team is responsible for the product outcomes, not just the output of on-time delivery. Try using the HEART framework and Goals Signals-Metrics process from Google to help you get there. Remember, if you can’t measure it, you can’t improve it. HEART stands for: Happiness, Engagement, Adoption, Retention, and Task success. The biggest challenge may be getting access to the tooling needed to do the measurement.

Iterate

Iteration is the most important part of the the Value Discovery Loop. Think of launching software as just the beginning as the key to improvement & innovation is by iterating via continuous Discovery and Delivery while learning from customers.