We Explained Every Feature. But What Is the Customer Trying to Do?

I recently watched a video from 理性避難所 about jobs to be done. The milkshake and banana example stayed with me most.

The video describes people buying a milkshake on their way to work. They are not only looking for a particular taste. They want something easy to hold, something they can sip during the drive, and something that keeps hunger away for a while. In that situation, the alternative might be a banana or a doughnut—not necessarily another company's milkshake.

What initially looks like a study of a drink turns out, when you look at everyday life, to be about different things people need to get done. The milkshake example comes from this video.

I take one idea from it: customers hire a product to get something done.

That is what I most want to keep from the video. It makes me ask whether, when we introduce metabiz, we start with the customer's work or with our products.

We can give a complete explanation of membership, reporting, integrations, and AI. But afterwards, does the customer still have to work out how any of it will help?

For example, when information passes from sales to the next colleague, that person needs the current status, the commitments already made, and the next step. Without those things, adding somewhere to store documents may still leave the work stuck.

This is a work scenario I use for comparison. It is not a story from the video or a verified customer result.

I want to move needs discussions and quotations in this direction: first agree with the customer whose work we are helping with, and which part we need to complete. That changes the order in which we introduce products.

Previously, I might first have considered which of our capabilities fit a request. Now I want to ask an earlier question: at what moment did this person realize they needed help?

If a colleague looking for information always has to wait for the same experienced person to answer, another search feature might help. But what they really want may be for the task to stop depending on whether that person is available.

If data has moved from one system to another, but someone still needs to reconcile it, send notifications, and chase progress, our definition of a completed integration may remain some distance from their definition of completed work.

These are scenarios, not descriptions of every customer. I do not want to mistake a better-sounding phrase for actually knowing what customers want.

So another question follows: without us, how do they do it today?

Perhaps with Excel, by asking a colleague, or by spending more time. They may even find the inconvenience tolerable enough to continue.

That answer affects whether they want to change.

We may think a new tool is convenient. For them, it also means organizing data, teaching colleagues, and changing habits. If the result is simply another system to look after, reluctance to buy does not necessarily mean they do not understand technology.

They may simply not believe their current work will become easier.

At this point, the first thing I want to change is not to produce a more complete product presentation.

It is to consider, in the next needs discussion, what we can put in front of the customer that will make the situation easier to assess—not just listen to what they say.

Customers sometimes know only that every day is exhausting and things keep going wrong. They cannot explain where the work gets stuck. Some do not want another round of questions; they want us to tell them what we can help them do.

I think that response deserves to be heard.

They may have approached us precisely because they want someone to help make sense of the situation. If we finish a round of questions by asking them to organize the requirements themselves, we have handed the difficult part back.

We understand systems, but a feature list alone cannot tell us which exceptions they encounter every day. Still, not knowing everything does not mean we can only keep asking.

If they mention repeatedly reconciling data, we can propose a starting point: examine the handoff, identify which fields get re-entered in different places, and which still need human judgment. This is a direction to check, not a claim that we have already found the problem.

They should not have to draw the entire workflow first. With permission, one suitable piece of data or a view of an actual operation may let us move forward. When that is not possible, we can select a de-identified sample together. Illustrative data can support discussion, but cannot prove an effect in the workplace.

We should do the organization and analysis, then bring what we found and our recommendations back for confirmation. The process owner and the people doing the work help fill in context we cannot see; they should not have to complete the whole diagnosis for us.

Some things still need clear answers: who can authorize access, which data cannot be used, and how far this engagement goes. We should explain how those answers affect the work, rather than make it feel like more homework.

That gives us a more concrete basis for deciding which features matter and which can wait. We also need to distinguish an initial assessment from a deliverable we can commit to. A customer's urgency is not a reason to turn an unconfirmed idea into a guarantee.

metabiz has membership, CRM, ecommerce, and workflow integration capabilities, and we are also bringing people's experience and AI into the work. I want those capabilities to have a purpose customers can recognize, without requiring them to learn every product name first.

I will still introduce products.

But I do not want to wait until customers can describe the problem perfectly before beginning to help.

Helping them find somewhere to start is part of our work too.

— Adam｜metabiz Founder

Further viewing: 理性避難所｜Jobs to be done. Read the Chinese original.