Why Our Users Identified the Problem… But Refused Our Solution

One of the most counterintuitive lessons I learned at Marion Livraison is the following: Identifying a user problem does not guarantee the adoption of your solution. On paper, our value proposition seemed obvious.

We allow construction professionals to have their materials delivered directly to the job site.

Fewer trips.
Less time lost.
More billable time.

Rather simple. At least, that's what we thought.

An Hypothesis That Seemed Logical

When we began working on our acquisition strategy, we identified several Personas:

• suppliers wanting to offer a differentiated service to their clients;
• B2B companies;
• independent artisans;
• individuals doing their own work.

Among these segments, artisans and small B2B companies seemed particularly interesting to us. Our reasoning was simple.

An artisan who has to leave the job site to pick up materials:

• loses time;
• interrupts their work;
• sometimes immobilizes an entire team.

We were convinced that a delivery service addressed a clearly identified pain point.

The Interviews Confirmed the Problem

We therefore started talking to professionals in the industry. Very quickly, the interviews confirmed our intuition. Users regularly explained to us that they lost time picking up their materials.

They described:

• round trips between the job site and the supplier;
• interruptions to their schedule;
• potential delays generated by these trips.

The problem did indeed exist. At this stage, we thought we had validated our hypothesis. We then began to talk about the solution.

The Paradox

When we presented our delivery service, part of the users reacted in an unexpected way.

They recognized the problem. They recognized the time lost. They even sometimes recognized the associated financial cost.

But despite this, many responded:

I prefer to continue managing it myself.

This reaction surprised us. Why would someone continue performing a task they themselves consider inefficient?

Understanding What Lies Behind Habits

Over time, we realized that our reasoning was too rational. We thought:

Problem identified + better solution = adoption. Reality is more complex.

For some users, picking up their materials themselves allowed them to:

• check the order;
• control the quality;
• maintain their habits;
• keep control of the process.

Their decision was not solely guided by time or money. It was also influenced by trust and routine. And these elements are often more powerful than a theoretical gain in productivity.

What the Interviews Actually Taught Us

This experience profoundly changed how I interpret the results of a discovery phase. For a long time, I would have considered that validating the problem was sufficient. Today, I make a much clearer distinction between two questions: Does the problem exist? and Are users ready to change their behavior to adopt my solution?

The two answers are often very different. An interview may validate a need.

It does not automatically validate adoption.

Reducing Risk Rather Than Convincing

Faced with this situation, we changed our approach. Instead of trying to convince users with rational arguments, we sought to reduce perceived risk. We introduced a test offer with a first delivery included for free. The goal was no longer to sell. The goal was to let users experiment with the service in their daily lives.

Without commitment.
Without risk.
Without a permanent change.

This approach proved far more effective than any commercial argument.

What I Take Away Today

This experience taught me a lesson I now apply to all products.

Users do not adopt a solution because it is objectively better. They adopt it when it becomes simple enough to replace an existing habit.

As a Product Manager, it is therefore essential to distinguish three steps:

1. Understanding the problem.
2. Validating that the solution addresses it.
3. Understanding what prevents the user from changing their behavior.

The third step is often the most difficult.

And it is also the one that makes the difference between a product used and a product ignored.