FEATURE – The authors explain why putting value at the heart of customer discussions is key to developing a successful, resilient tech firm.

Words: Michael Ballé, Céleste Dhellemmes and Woody Rousseau

56% year on year growth is fantastic – and a blessing. To achieve such a result is exhilarating, but it also brings its share of headaches: where do we find the developers? Once we’ve convinced them to join us, how do we find cool projects to keep them interested – and their teams staffed? How do we create a convivial environment in such difficult times? In the every-day work, it is easy to get swamped with the endless sales and operations problems and shift into reactive mode.

With co-founder Rodolphe Darves-Bornoz, we’re very aware that we are lucky to be in a market where demand well outstrips supply, and glad that we chose FinTech for our tech start-up. There’s plenty of work and fascinating projects. We’re really proud to have helped Bpifrance, the French public investment bank, to promote innovation and finance among entrepreneurs, respond to the Covid-19 pandemic, and scale their offer to struggling businesses in times of dire need. But we also realize how easy it is to slip into a “deliver whatever” mindset to keep clients happy and move on.

Measuring Net Promoter Score throughout our projects is part of the company’s DNA, so we have a good sense of how the project is going and whether customers are happy with our teams. We know when we’re doing things right or wrong. But NPS doesn’t tell us whether we’re doing the right things! A few years ago, we started wondering about the quality of the systems we build – the fundamental quality, beyond fewer bugs as possible and delivering on time. We needed to build a reputation for smart software to create a lasting business and become the “go-to place” for useful and elegant systems. This is what led us to explore lean.

One of us (Céleste) joined the Lean Engineering Academy (hosted by Michael) and started wondering how lean engineering concepts would apply to software products. Starting from Quality Function Deployment tools, she realized that product architecture could equally apply to software systems: developers and engineers thought the same way about how to deliver functionalities to customers. Céleste broke down a product in three parts: jobs to be done, systems and technologies.

• Jobs to be done are customer needs at a certain level of performance, such as how easy it is to log in, how fast does the system respond, and with what level of failures;
• Systems are the code blocks behind the interface that do the job for the user;
• Technologies are about choosing the right tech to code the system as smartly as possible. We’re looking at security (low risk of hacking), speed (response time), and stability (risk of outage or of burdening other systems with cumbersome interfaces).

Céleste worked on a systems diagram to represent these three aspects of our products, first trying her hand at existing products, where hindsight was available to understand technical choices, good or bad, and is now working with architects to get them to clarify their choices as they design new products or features for clients.

Looking at these architecture diagrams has given us a unique insight into performance – we can measure whether the final product delivered are good, average, or poor, based on “jobs to be done” once they are in the hands of users.

But it is also leading us to ask a deeper question about customer value: did we get the “jobs to be done” right? As we all know, software providers keep adding functionalities to their systems to satisfy this or that so-called “user need” to the point that the software is so complex that it becomes unusable for the casual user and requires real expertise to navigate through menus and functionalities. As we also know, what makes a software friendlier than another is often hard to determine: why would you prefer Whatsapp to Messenger? There are many hypotheses – warmer colours, robustness (always available), trust (encoded), response time, ease of search, ease of archiving etc. – but who knows? Users certainly can’t tell us. To them, choosing one over the other is a matter of pure instinct.

Clarifying the jobs to be done as we see them is the key to asking ourselves the really deep question about value: are we doing the jobs that users really need or enjoy but can’t tell us because it’s intuitive more than reasoned? We don’t know the answers to these deeper questions but we’re investigating ways of better measuring actual user behavior and going back to user complaint tickets to try and figure out likes and dislikes.

Benefit to users, however, is only one side of the value equation. The other aspect is the total cost to users – their cost of ownership and our cost of development. Their cost of ownership will appear in bugs they need us to fix or extra features they need us to develop. Our cost of development appears in two forms, work plus rework: the necessary cost of development (coding hours as well as cost of other suppliers, such as the cloud provider) plus the unnecessary cost of development (hours of debugging and recoding).

Following through on his lean reading, one of us (Woody) came across Dantotsu, an approach leading to a radical quality improvement popularized by Toyota veteran Sadao Nomura. From that book, Woody took to heart the notion of weak point management: how to isolate recurring quality problems and resolve them until they no longer come up.

_{Visual management in the open space of the team showing how many bugs were detected by the user and during the software acceptance phase.}

_{A bug analysis produced by the tech lead, the team leader of a development team. It is one of the many bugs matching a weak point in software development, defective assembly with external systems, called APIs in software.}

As founder and Chief Technical Officer of the company, Woody invested in systems to track bugs real-time (surprisingly difficult to do in a software house), understand the nature of these bugs, and start an in-depth analysis of recurring ones of with the developers themselves.

_{The system shows bugs on all products that Sipios develops for its customers, and it is displayed in the entrance of the company.}

The hurdles are daunting as this needs to happen in a context of rush to deliver every project, chronic staff shortages due to ferocious competition to recruit developers, and the ongoing pressure from customers who are often changing the cope of projects once the coding is already on the way. Usual life in software development! Yet, early results are promising and we’re learning fast about typical problems linked to typical technologies.

And what we’ve now come to realize during our founders’ gemba walk is that we need to dovetail the two approaches to develop a more consistent vision of value: real benefit to users / total cost of service.

Early positive results already show in both parts of the equation:

• we discuss value more and more with our customers, while traditional discussions with IT suppliers tend to concern day rates and software estimates. This in turns changes the nature of the relationship away from dickering on price and deadline and towards customer outcomes.
• tech leaders have a more hands-on understanding of our zero-bug strategy – less of a company’s slogan and more focused on clear activities they can carry out and discuss.

Hard-nosed financiers may well ask how this will translate into growth and profitability numbers and, so far, we have answer other than our belief that placing value at the heart of our customer discussions is the key to growing a different kind of firm. One where technology delivers better outcomes, not just outputs. This is what gives meaning to our work!

_{THE AUTHORS}

‍