[Product Development Series — Part II] Value analysis: starting development later to deliver sooner

This article has been co-written by Steve Anavi, Co-founder and President at Qonto, and Regis Medina, a hands-on executive coach and lean researcher (his new book Learning to Scale is out), who has been working with Steve for the last 18 months. It is part of the Product Development Series composed of 3 articles: Part I | Part II (this one) | Part III.

In present day startups and scale-ups, product development is geared towards building the product as soon as possible, with the idea that learning will come once the product is in the hands of customers. We often hear from Product Managers “I like to iterate”. Let’s see now why that would be a major problem.

The corresponding approach usually boils down to the following:

1. Analyze a few user personas and design the sequence of steps for the main use cases
2. Draw a list of features to add to the product backlog
3. Estimate the corresponding workload and negotiate with stakeholders to decide which features to implement first
4. Develop a first iteration of the product
5. Gather and analyze user feedback, develop another set of features, and repeat

While in theory such an approach may in the end converge on something that covers users needs, it is an expensive strategy because it requires building the product, with three common problems:

• Designing features with no consideration on what aspect triggers the sale (the “how”), leading to no business impact
• Adding features until the product is bloated and turns customers away
• Discovering functional or technical difficulties late in the process, which break havoc on the development teams

Better to be lucky than good? A much better and stimulating approach consists in learning what will drive customers to a purchase, and uncovering all major technical problems, before investing in building the product.

This requires putting more effort in framing the product through learning before developing, and starting development a bit later to deliver much sooner and better. This approach is called “front-loading the design process” and is the way we operate at Qonto.

A cadence of learning cycles

Expertise is the result of repeating a skill in different contexts, time and again. In the case of product development, this means seeing each product not as a one-time event, but a periodic series of product evolutions. This is pretty much what Apple does for instance with its iPhone line, alternating minor and major evolutions announced every autumn.

The time between two versions is called the takt, a German word referring to the beat of the metronome. The takt of a given product depends mostly on its target market. When releases are too frequent, customers lose track of the changes. When releases are too distant, the company risks being outpaced by competitors.

Following a takt of product evolutions creates a steady cadence which helps align the whole company including marketing, sales, operations or support.

The takt sets a speed for the learning, through a 2-step cycle called Value Analysis / Value Engineering:

• Value Analysis is when the product team studies existing products to get a deep understanding of how they could create or destroy value for customers.
• Value Engineering is about leveraging lessons acquired through Value Analysis for Product Managers and engineers to design and build the next generation of the product.

Front-loading the design process

The biggest waste in product development would be to build features that customers do not want to pay for. For this reason, learning starts with spending a lot of energy understanding the current situation and uncovering customer preferences from a wide range of aspects, and this what the front-loading is for.

Framing the situation

As an archaeologist would search for artefacts, the Product Manager’s role is about exploring what should be the next move on the product to increase sales, reduce costs or improve customer satisfaction. This means building a theory around a given case, supported by findings not only coming from data but also from observation, feeling and experience. We like to cover the following:

• Observing how people use products to highlight where they support or fail them. We would usually engage with clients, draw/mock-up what they go through and make problems visible along the flow
• Gathering and analysing usage data to dig further into underlying causes
• Reading public verbatims from unhappy clients to reveal the most important blocking points; but also promoters’ to understand what they really care about
• Identifying on which criteria users assess performance
• Building a State-of-the-Art based on experts’ books and articles
• Tearing down competitor products to understand what they do, how they do it and most importantly why they do it in such ways
• Understanding the value structure considering price and cost in regards to how we anticipate the market to move in the mid-term

Example of A3 of a small improvement — some parts are blurred to respect confidentiality

At Qonto, the exercise of framing the situation is called Scoping. Each Product Manager is advised to consider using an A3 sheet to think through a given case.

Our Product Managers make their A3s visible and engage with stakeholders at each step of the way. Most importantly, they start discussing with C-Levels on their theories and what they have learnt that could benefit the clients and thus the company. The interaction usually starts with the CEO and/or CPO asking “what have you learned?” followed by a suggestion to push the thinking a little further and stimulate the thinking from a different angle.

Example of A3 of a bigger product — you can see that PMs can go with either handwritten or digital to accommodate remote

The above A3 is available to be discussed on our walls — some PMs decide to go with fully digital walls (e.g. using Miro) to accommodate remote

As you can understand from the example above, Product Managers can do a self-assessment on the quality of their learning by clearly stating the problem, the causes, the success and the performance. It’s not so much about having the blocks filled for reporting purposes but more the act of filling them that will lead Product Managers to think deeply on whether their learnings make sense. You are never sure of what you know until you have to explain it, right?

• The problem statement provides a short yet impactful description of the value opportunity as the gap between what currently happens and what should be happening
• The causes (of the Problem) provide more colours on what are the levers that should be considered to solve the Problem i.e. how to create value
• The definition of success helps frame the goal in a qualified way, to be reached within a given timeframe. The act of defining success is an important piece in the sense that it teaches Product Managers to broaden their perspective and see their part from the point of view of the CEO: will I impact quality, lead-time and/or cost? Consequently, will I impact revenue, cost or both, and when? Will it help my quarterly company goals?

The last piece, the performance (through preference analysis), is probably the most important step before thinking about solutions. From our experience, it is also the most overlooked. That’s why the following section will focus extensively on that subject.

Performance Before Features

Designing a product in terms of features is the same as proposing solutions without having fully identified the problem we want to solve.

A better approach consists of thinking in terms of value and product performance: what is the customer trying to achieve, and how does she evaluate one product over another? You can think about performance as the way a salesman would ask what you care about when buying a computer: powerful for what? Transportable to what extent?

One of the main learning objectives of Value Analysis is to uncover the range of customer preferences for the product, and then translate them into product characteristics, obtained through specific features. Let’s take an example.

Apple released the MacBook Air in 2008 to answer a growing demand of “a computer for the growing number of commuters”. Let’s break it down:

This translates into equally important preferences:

• I want a computer that is easily transportable
• I want a computer that can sustain long commuting time
• I want a computer powerful enough to work on office software and access Internet content when needed
• I need a price that fits my lifestyle
• I want no compromise on Apple’s signature: simplicity, elegance and design

These preferences translate into product characteristics such as:

• Processing speed
• Battery life
• Weight
• Price
• Screen size

These product characteristics can be linked to modules/parts of the product, for instance:

• Processor and RAM to run web browser and MS office suite, with low energy consumption
• USB only, Wifi over RJ45
• Batteries, and the battery management system,
• Screen
• Casing

A new product evolution is thus defined as an improvement along a few well-selected performance characteristics. Features are just solutions to achieve these improvements.

Example of Preferences analysis

A Compelling Concept to Frame the Learning

With a good understanding of customer preferences and target product characteristics, the Product Manager needs to frame what she will need to explore and learn before starting to build the product. This means establishing a theory of how the product will bring value for customers and earn money for the company, even before development actually starts.

This is called the product concept, and is usually detailed in a document called the Concept Paper. At Qonto, we would put together a Concept Paper for rather large products but would use a single A3 for smaller improvements. Regardless of that, the following questions should be covered:

• For whom will the product create value? In what context?
• What is the product concept? The concept is a short sentence describing the vision of the product, meant to align everybody on the project.
• What are customers’ preferences?
• What are the expected performance characteristics?
• What are the target sales volumes?
• What is the target cost?
• What is the timeline? What are the main milestones of the project?
• What key knowledge is missing to succeed?
• What needs to change in the version? What must remain untouched?

The product concept allows the Product Managers to establish the best vision for the product in order to secure the buy-in from people she is going to work with.

Value Engineering

Drawing on the lessons acquired through Value Analysis, Product Managers design and build the next generation of products. The goal of Value Engineering is to discover the optimal design that at the same time:

• Increases value for customers to drive more sales
• Reduces development and operations costs to drive profitability

The learning in this phase is all about exploring this trade-off in greater detail. Want to learn more about our way to dig into Value Engineering? Read the next article here.

🔥If you want to join our amazing Product team, see job openings here.