All news

Why Growth Conversations Drift Towards Technology — and Away From the Customer

Viewpoint Article

When a new industrial product or digital service struggles to gain traction, the discussion often turns to technology. Perhaps it needs more data, a better interface, another integration or more advanced analytics.

Sometimes it does. But there is another possibility: the team has become very good at discussing the parts it knows how to solve, while the harder questions about customers and value remain open.

This article explores why that happens and how to bring those questions back into the development conversation.

The Meeting Where Everyone Has Something to Say

Picture a meeting about a new industrial digital service.

The team starts discussing architecture. Then connectivity. Then dashboards, integrations, data storage and the potential use of AI.

The conversation is active. People ask detailed questions. Decisions are made.

Then someone asks: “Who exactly needs this enough to pay for it?”

The discussion slows down.

There are suggestions, but fewer clear answers. Someone mentions a customer who once requested something similar. Someone else proposes collecting feedback after the first version is ready.

Soon, the conversation returns to the technical roadmap.

This is an understandable response. Technical questions offer familiar ground, established methods and visible progress. Customer and commercial questions can feel much harder to bring under control.

Why the Details Feel Safer

A technical problem often comes with a recognizable way forward.

You can test a connection, measure response times, inspect a dataset or compare implementation options. The work requires expertise, but the team usually knows how to begin.

Customer value is less predictable.

People may describe their needs inconsistently. Users and buyers may disagree. A recurring frustration may still be too minor to justify a purchase. A valuable improvement may be difficult to fit into an existing budget.

Answering these questions requires conversations beyond the project team. It may also require hearing that an idea people care about has limited appeal.

So the team keeps working where it feels capable.

That response is human. The problem appears when the unresolved customer questions quietly become assumptions in the development plan.

You Can Build a Mechanical Masterpiece That Nobody Wants to Drive

Imagine a car with an extraordinary engine, beautifully engineered components and an ingenious transmission.

From a mechanical perspective, it is a masterpiece.

But it is also butt-ugly, uncomfortable and unpleasant to drive. The controls are confusing, and you feel embarrassed every time you sit behind the wheel.

Would you call it a good product?

The engineering achievement is real. So is the disappointing experience of owning and using it.

Industrial products and services deserve the same scrutiny.

A monitoring platform can process huge amounts of data while making it difficult for a maintenance manager to decide what to do next.

A dashboard can contain dozens of indicators while leaving the user to interpret which ones require action.

A service can offer an impressive list of capabilities while giving the buyer little confidence that implementation will be manageable.

Customers experience the complete offer. They live with the effort, uncertainty and consequences of using it.

What Does “Better” Mean to the Customer?

Improvements are often described through capabilities.

More accurate predictions. More data points. Faster processing. Additional functionality.

For a customer, the relevant question is what changes in practice.

Does the maintenance team have more time to plan? Can a service technician arrive with the right spare part? Can an operator complete a task with fewer interruptions? Can a manager explain the investment to the person approving the budget?

These questions make the intended value more concrete.

They also expose trade-offs.

An earlier warning may be valuable only if someone can act on it. A highly detailed report may save analysis time for one person while creating extra work for another. A useful application may struggle to gain adoption if it adds another daily login and duplicates existing work.

Understanding those conditions helps the team define a better product.

The User, Buyer and Beneficiary May Be Different People

Let’s think about a visual remote diagnostics service.

A service technician uses it to investigate faults. A maintenance manager decides whether it fits the operating process. Procurement negotiates the contract. A production leader benefits if interruptions become shorter.

Each sees the service differently.

The technician may care about finding the right information quickly. The maintenance manager needs confidence in how responsibility and escalation work. Procurement needs a clear scope and understandable terms. The production leader wants evidence of operational improvement.

A product discussion that focuses only on the interface or data pipeline can miss these relationships.

The technical solution has to work within a buying and operating situation involving several people.

That is why “the customer liked the demo” is a useful starting point for further questions: Who liked it? What did they find useful? What would they need to change? Who else must support the purchase?

More Features Can Leave the Main Objection Untouched

When an offer struggles to sell, adding functionality can feel constructive.

But imagine that the buyer’s main concern is the effort required to introduce the service across several sites.

Adding analytics may increase the list of benefits. It may also make the implementation appear more complicated.

Or suppose users already have the information they need, but nobody has agreed who should act on it. Another dashboard will leave the responsibility question unresolved.

Before expanding the roadmap, investigate what is preventing the desired customer action.

Sometimes the answer calls for development. It may also call for a simpler service, clearer responsibilities, different pricing or a more credible introduction plan.

The Remion Growth Library offers a framework for connecting these customer and business questions with solution development.

How to Bring the Difficult Questions Back Into the Room

A practical change is to give customer uncertainty the same discipline as technical uncertainty.

1. Name the customer and the situation

Describe who faces the problem, when it occurs and what they are trying to accomplish. Avoid treating a broad industry category as a sufficiently precise customer definition.

2. Examine what happens today

Ask how the work is currently done. Look at recent examples, existing alternatives and the consequences of the problem.

A concrete incident often reveals more than a general discussion about future features.

3. Define the improvement

Describe what would become easier, faster, more reliable or less costly. Make the outcome specific enough to investigate.

4. Test the whole experience

Explore how someone would discover, evaluate, purchase, introduce and use the offer.

Include the work required from the customer. That effort is part of the proposition.

5. Connect development to the evidence

Use what you learn to decide which technical work deserves priority. Give unresolved questions an owner and an agreed next step.

The Growth Guides provide a starting point for taking that discussion further with your team.

My Key Takeaways

I understand why we return to technology when questions become uncomfortable.

Technical work makes problems tangible. It gives skilled people a way to contribute and creates visible progress.

But the questions about who needs the offer, why they would change and how they would benefit need equally serious attention.

Leaving them open has consequences. Development priorities begin to reflect internal preferences. New features accumulate. The team becomes more invested in a solution without necessarily understanding its place in the customer’s business.

The strongest product discussions make room for both engineering detail and the realities of buying and using the result.

A customer should be able to recognize the improvement in their own work. That is a demanding standard, and a useful one.

Are You Solving the Questions That Matter Most?

Remion’s Industrial B2B Growth Advisory helps industrial technology teams examine customer value, commercial choices and technical possibilities together.

If your roadmap is detailed but the customer case is still difficult to explain, that is a useful place to begin the conversation.

If want to move at you own pace – checkout our free guides.

Related guide · Guide 02, chapter 2

From Machine Data to a Service Customers Will Buy

The guide starts from the job and the outcome, not from the signal or the technology, and shows how to turn data into a service a customer will buy.

Read the guide →

About the Author – Jussi Rajamäki

Jussi helps companies unlock the value of machine data. Supported by a team of experienced experts and his practical experience in IoT platforms, data analytics, and digital services, he focuses on enabling scalable data-driven solutions and building new digital services.