[Product Development Series — Part III] Value engineering: designing products that sell

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 | Part III (this one).

Product teams (as well as ExComs) often forget what makes a great product. They tend to stick to the idea that value comes from the number of features that are stacked in a given product.

The reality is fairly simple: great products are the ones that sell, not necessarily the ones with tons of features.

As a consequence, a great way to understand how to design a successful product must begin with understanding how customers decide how to buy, retain and renew their products. At Qonto, we qualify customer engagement along these axes:

1. The product seems awesome! (love at first sight)
2. The product works as expected
3. The product does not require heavy/frequent maintenance
4. The product creates a bond (with me) over time
5. It offers good value for money (price)

It seems clear that there’s a lot more to designing a product than finding a solution that satisfies a great variety of requirements and features. Indeed, while the product team might draft a viable functional solution, it will only be that: a barely satisfying solution. Drawing on the lessons acquired through Value Analysis, Product Managers proceed to Value Engineering: designing and building the next generation of the product. 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

Design for value

Along the learning process of Value Analysis, Product Managers acquire a critical view of how customers choose a product over another — what we call customer preferences e.g. “I want my laptop to be powerful enough so I can surf on the Internet and work on Office documents”. The next step consists in learning how to translate those preferences into product characteristics.

80 points + alpha

Let’s take an example: some time ago, we revisited our RIB (i.e. a PDF with standardised format for bank account details/data systematically used in France).

With Value Analysis, we learnt that customers would care about a document that should be:

• Reassuring, that looks like a RIB of traditional banks’ heritage
• Easy to use for the one who is actually using it (i.e. the one wiring the money), i.e. in the correct language and that can be entered rapidly in the bank’s online transfer form
• Accessible to download when the user needs it
• Enriched with information to avoid mispayment

Having a closer look at what a RIB should include, we can break down the information into 2 categories:

• Core information: e.g. IBAN, BIC, Account owner
• Handy information: e.g. IBAN in the French format but also SLA on how fast money will arrive

Example used to organise the information

This first step is about learning how to make sure requirements translate preferences along the customer engagement journey. In other words what makes possible those affirmations: “the product seems awesome! (love at first sight)”, “the product works as expected” and “the product creates a bond (with me) over time”.

The core information is the sum of mandatory elements and functional requirements that are crucial to make the product work as expected. In other words, this data is not only necessary to establish credibility with customers but also to ensure the product is built right the first time. We call these core elements the “80 points” characteristics, in the sense that having a 80 percent performance in regard to the state of the art is sufficient — being above that level would be overkill.

Let’s go back to our example: what we defined as the handy information is usually not on a typical RIB since it is not required to execute a transfer; it however brings a tremendous amount of value for users, related to familiarity, trust, efficiency and delight. Those are the non measurable factors we care about at Qonto. Providing an answer to functional needs is not enough for us: our internal mission is to create a bank that customers are excited to use, and this is how we want to make Qonto products special. Both the handy and core information are translated in what we call the 80 points + alpha, where “+ alpha” expresses the “je ne sais quoi” or the thoughtful extra touch that will make the product special and unique.

This “80 points + alpha” framework is key to deciding where to put our efforts in an optimal way: building a solution that sparks joy along the customer engagement journey, and that sells, while avoiding unnecessary costs.

Mapping preferences and technologies

Now, let’s push the reasoning a little further and see how we can get closer to a viable solution. The overall idea is to understand what technologies can be used to ensure that preferences and 80 points + alpha are properly translated in the end product.

To go back to our RIB example, what would it mean to have the IBAN presented on a PDF in a handy way, and how would that be possible technically? Here is what we came up with:

• The IBAN is an important core information composed of 15+ characters and which requires spaces for readability purposes. It’s a heritage coming from traditional banks and we want to preserve it as both handy and with the look and feel of “tradition”
• However, we also learnt that IBANs are sometimes not presented with spaces. Why? Because it’s easier for the ones copying-pasting to an interface composed of a unique text field for the IBAN. And that’s a pretty handy one we would be keen to keep.
• So now, what are the technologies available to make that happen? Well, we could generate a PDF from a HTML file to offer a clean and controlled UI, with the IBAN presented with space but copyable in one block to fit traditional banks’ text fields. And several other solutions pop-up along the discussion.

As we move along our engineering process of the whole RIB, we can add up more learning and reasoning along the process.

Example on how solutions are built breaking down our systems and mapping them to preferences

At this stage, the product team, along with engineers, would have learned and framed solutions that outline what the customer would expect; and come up with a first prototype to share a same source of truth. But is the solution implementable efficiently?

Design for built-in quality

Not considering time and cost, all the effort spent on adding value to the product is ultimately offset by quality issues that arise in production. A common reaction to quality issues boils down to:

• Setting aside development bandwidth for the fixes
• Increasing the test effort — either by checking all developer increments through pull request reviews or performing more manual and automated tests.

These are expensive and not very effective ways to manage quality. Quality issues are less expensive when caught early, which means that a major focus should be put on learning how to prevent defects in the first place.

This requires a deliberate approach from every member of the product team, with each individual:

• Developing their own theory of how to avoid defects in their job, using specific control points, in order to avoid passing defects to the next person in the process;
• Analyzing all defects to improve their theory and practice over time.

Learning from conflicting components

Front-loading the design process is a first step in improving quality, by making sure that the development teams receive clear instructions for designing a product that will fulfil customer expectations while respecting the overall cost targets.

The Product Manager, for instance, checks the integrity of its design using a tool like the Quality Function Deployment (QFD) matrix.

This helps our design teams check the main elements of their solution:

• Are customer expectations covered?
• Where does the solution stand compared to the competition?
• What is the current cost of each subsystem, compared to the target cost?
• What is the impact of the changes on a given subsystem?

At Qonto, we like to think through the QFD as a starting point to highlight dependencies (positive or negative) between preferences, functional characteristics, technologies and solutions. For instance, how does “powerful” impact “affordable”? What are the available technologies to overcome this impossible trade-off?

Overcoming the “hard points”

Successful products come from Product Managers overcoming seemingly incompatible characteristics or requirements through innovation and that means facing head-on the hard points. How to create a global coffee-based product that also sells locally? How to increase the range of electric cars without adding more batteries (i.e. weight)? How to eat healthy with no time to cook?

Learning how to tackle hard points is probably the most valuable (and hardest) piece to make a company successful. That’s the reason why we have so many examples of Product Managers falling-back to a technically feasible solution, forgetting what customers cared about in the first place. A good way to approach that problem is to think through it by seeing the hard points as trade-off curves and to learn how to move them.

Let’s take an example: Qonto has followed direct debit market practice to avoid unwanted rejections due to low balance. Banks typically advance the cash if they know that the money is on its way. As a consequence, the likelihood of acceptance is correlated to the amount of working capital banks allocate to that. We can represent the situation with trade-off curves.

Example of “hard points” represented with trade-off curves

An efficient way to look at the problem would be to think about how direct debit acceptance rate could increase without higher working capital requirements. In other words, what do we need to learn to move the trade-off curve instead of moving along it?

The team’s engineering work starts when she finds an efficient way of diverging from the norm. I’m not telling you what we ended-up doing and if we “cracked” the trade-off (while complying with the regulatory framework). The important point here is that the team used this model to think about the problem from a different angle to try to innovate and build further knowledge.

You would think that to be inconceivable. However, as we like to say at Qonto, “it’s impossible until it’s done”.

Design for profit with target costing

Now let’s reintroduce the dimension of cost: a product cannot become a success in the long term until it is profitable. The price of a product is mostly driven by the market, which sets a price accepted for a given amount of value. This means that for a company to make a profit, it must carefully manage the overall costs of delivering products and servicing customers. For this reason, total cost must be an input of the product development effort, not an output.

With this perspective in mind, the role of the product team is to find the right mix of technologies and systems that deliver the expected performance characteristics of the product while respecting the overall expected cost. This activity, called Target Costing, is an exercise of teamwork (negotiating with peers) and creativity. It rises from thinking out of the box to find cost-effective solutions without compromising performance.

This approach covers both fixed, one-off development costs, and variable costs, which depend on the number of users and maintenance.

Every product manager knows that the more changes in a given version, the higher the cost and the higher the risk of introducing defects or disgruntling loyal customers. A main focus of learning for the product team is defining precisely what must be kept unchanged, not just what needs to evolve. As such, part of the success in controlling costs is having a very clear reuse strategy. This requires a deep understanding of value from the perspective of the customers, and of the many technologies involved in the product.

In a sense, cost control is the core element of a successful product management strategy. Done well, it drives the need to deeply understand value in the eyes of customers, and how this value is built into the product. It is a powerful way to drive learning and teamwork in the product organization.

Building a practice of product development is an endless journey: it requires technical skills, hard work, practice but most importantly the passion to learn and get better at a craft.

So, to our amazing product and tech team and future product candidates: never, never, never give up on learning. Get used to it, invest the time and effort in growing your craft, in training your cortex, in learning methodically from your mistakes. The job is not (only) about user stories and wireframes, it is about learning everyday.

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