How to stay customer-centric in the AI era?

Why customer-centric thinking gets harder in the AI era, not easier

Every time a transformative technology becomes available, organizations make the same mistake. They start with the technology. They ask how can we use this? before asking who needs what we are about to build?

AI has supercharged this pattern. The technology is more capable, more accessible, and more hyped than anything in the last twenty years. Product teams now have the means to prototype AI features in days. The temptation to start with the model and work backwards toward a problem is enormous.

The pattern is not new. It has been killing well-funded products for decades.

The difference now is speed: AI lets teams build the wrong thing faster than ever, with more conviction, on bigger budgets.

This article is for product, innovation, and digital leaders who own AI projects with real budget on the line and a deadline ahead of them. It comes from a webinar we delivered at Design Sprint Academy in 2024, expanded with the methods we now use with clients running AI initiatives across product, operations, and digital teams.

What is a tech-first approach, and why does it keep failing?

A tech-first approach is when a team builds around a technology's capabilities rather than around a customer's problem. The team starts with what the technology can do, then searches for places to apply it. The customer is an afterthought, often arriving in the process only after major design decisions have been made.

The Segway Personal Transporter is the textbook case.

Launched in 2001, the Segway was a remarkable piece of engineering. Self-balancing. Patented technology. Decent range. Reasonable speed. Steve Jobs reportedly compared it to the PC. Jeff Bezos was an early backer. The development team called the project Ginger and kept it under wraps. Roughly $100 million was spent before launch — an enormous sum at the time for a single product.

It failed.

The reasons are instructive because almost none of them were technological:

• Price — nearly $5,000, far above the average consumer's reach.
• Form factor — 96 pounds, bulky, hard to store and transport.
• Aesthetics — it didn't look like something people wanted to be seen riding.
• Use cases — unclear who needed it, when, and for what.
• Safety — the battery sometimes died without warning, with predictable consequences.
• Regulation — unclear whether it belonged on sidewalks, roads, or somewhere else, and rules varied by jurisdiction.

A British businessman who acquired the company died in 2010 riding one off a cliff into a river. Ninebot acquired it for $75 million in 2015. The product line was discontinued in 2020. Twenty years and roughly $175 million in capital, ending in a niche market for tourist rentals and security guards.

Look at the failure list again. Five of the six reasons are about humans — their wallets, bodies, social status, daily routines, and safety. The technology worked. The technology was never the problem.

The Segway story is not unique. Google maintains an unofficial graveyard of discontinued products — Jamboard, Dropcam, Glass, Stadia, dozens more. Most of them shipped working technology that did not solve a problem anyone urgently needed solved.

What questions should every AI initiative answer before development?

Two questions, before any prototyping:

Does this technology solve a real customer problem?

Not a problem the team has imagined the customer might have. A problem you have evidence the customer is actually trying to solve, today, with whatever inadequate tools they currently have.

Can it make the job easier, faster, or better?

The second question deserves more attention than it usually gets. Easier and faster describe how customers currently do the work. They are useful but limited — they make AI a more efficient version of the existing system. Better is the more interesting word. It asks: with this new capability, what becomes possible that wasn't possible before? What can be reimagined from the ground up?

Most AI projects optimize for easier and faster and miss better. That is fine if your goal is incremental productivity. It is a missed opportunity if your goal is differentiation.

Why is staying customer-centric so difficult inside large organizations?

Because the people making decisions about customers are the most removed from them.

A CEO typically spends about 3% of their working time directly with customers. The rest is internal: meetings, reviews, board work, leadership coordination. Senior product, engineering, and innovation leaders are not far behind. The further up you go in the organization, the more the customer becomes a slide in a deck rather than a person you have spent time observing.

‍

Layer two of the problem: silos. Most enterprises are organized into functional groups that do not share context.

• Technology and engineering teams know what the technology can do. They are usually furthest from the customer.
• Sales and marketing teams know what customers complain about and what they buy. They usually have the weakest sense of what is technically possible.
• Product teams sit in the middle and inherit assumptions from both sides.

When these groups operate in isolation, the people who understand the technology design solutions disconnected from real customer needs, and the people who understand the customer cannot evaluate which technologies are worth investing in. The result is a steady stream of features that are either technically impressive and customer-irrelevant, or customer-relevant and technically infeasible.

Fixing this is not a culture problem to be solved with a values poster. It is a process problem. The fix is structured: bring the right people into the same room at the same moment, with the right data, working on the right decision.

What is the five-step process that keeps AI development customer-centric?

A repeatable five-step process — Discover, Decide, Experiment, Learn, Decide and Execute — that takes a team from customer research to a validated AI prototype in roughly four weeks.

The constraints make it work in real organizations:

• About two days of total time from subject matter experts (engineers, AI specialists, technical leads).
• About one day of total time from senior decision-makers across the whole process.
• Four weeks end-to-end from start to validated prototype with real customer feedback.
• Plug-and-play with whatever way of working the organization already uses — Agile, Waterfall, Stage-Gate, none of the above.

The time math is what makes this possible inside enterprises. Senior leaders rarely have multi-day blocks free. Subject matter experts rarely get permission to leave their delivery work for weeks. The process is designed around the actual constraints these people operate under, not around an idealized version where everyone can drop everything for a month.

‍

Step 1: Discover

Start with the customer, not the technology.

Large organizations serve multiple customer audiences. The first move is to prioritize — not because other audiences do not matter, but because solutions cannot be designed for everyone simultaneously.

Once a primary audience is chosen, gather both qualitative and quantitative data:

• Qualitative: user interviews, ethnographic research, observation sessions.
• Quantitative: analytics, usage data, surveys.

Most large organizations are excellent at gathering this data. They are much weaker at using it. Research findings end up in long PDFs no one reads, or in spreadsheets no one queries. The data exists. The understanding does not.

The step that converts data into understanding is visualization — typically as a customer journey or experience map. A morning routine, plotted from alarm clock to leaving the house, exposes the moments where people struggle, the moments they would happily pay to skip, and the moments where their current tools fail them. The same technique applied to a real product or service surfaces the same insight: where customers are spending energy, where they are stuck, where they are frustrated.

A good customer experience map aligns the perspectives of subject matter experts, leadership, and frontline teams around a single shared view of reality. Decisions made on top of that view are dramatically better than decisions made on top of fragmented internal anecdote.

Step 2: Decide

A Problem Framing workshop with the right decision-makers in the room.

The Problem Framing workshop is a one-day session that takes the customer data from Discover and combines it with the business context senior leaders carry. The goal is alignment on which opportunity is worth investing in next — with explicit commitment from the people who own the budget.

The people in the room matter. The right participants are decision-makers with three qualities: influence over the relevant area of the business, genuine interest in solving this type of problem, and access to the resources required to act on the decision. Without all three, the workshop produces opinions instead of commitments.

The output of this stage is not a solution. It is a prioritized list of opportunities and a clear go-ahead from leadership for the team to start exploring the top one. This sounds incremental. In practice, it is the step that prevents the most expensive failure mode in product development: building something the organization will not actually back when it is time to ship.

Step 3: Experiment

A structured sprint with a cross-functional team.

This is where the AI Workflow Sprint comes in. A focused four-day workshop that takes the prioritized opportunity from Step 2 and produces a working AI prototype with real customer feedback by the end of the week.

The team composition is what makes the sprint work:

• Engineers and AI specialists who can build.
• People who understand the customer — customer support, UX, frontline staff.
• Business stakeholders — marketing, sales, strategy.

This is the silo-breaking moment. For four days, the people who usually argue about each other in their absence sit in the same room and design together.

The sprint structure:

• Day 1: the cross-functional team aligns on the problem. Everyone brings what they know. The team agrees on what success looks like.
• Day 2: individual ideation followed by group convergence. Solutions are designed, then narrowed to a single concept worth prototyping.
• Day 3: a small build team produces a realistic prototype. For digital products with AI, the prototype is increasingly built using AI itself — modern tools make it possible to produce convincing, functional prototypes in a single day.
• Day 4: the prototype goes in front of five real customers. Feedback is captured, patterns are identified, and the team produces a recommendation: build, kill, or iterate.

Four days, from prioritized opportunity to validated prototype. The numbers matter because they are tractable for product leaders working under quarterly deadlines.

Step 4: Learn

Real customer feedback, fast.

Most product organizations build out elaborate business cases, financial projections, and feature plans before testing whether the underlying idea actually works for users. The output of Step 3 makes that approach unnecessary. The team has a working prototype and direct feedback from real customers within a week of the Problem Framing workshop.

The feedback is not a substitute for full validation. Five interviews are not statistically significant. They are diagnostic. They tell the team whether the concept is broadly on track, missing critical context, or fundamentally misaligned with what customers want. That diagnostic is enough to make the next decision well.

Step 5: Decide and Execute

Return to leadership with evidence.

The same decision-makers who attended Problem Framing are reconvened. They are presented with three things: the prototype the team built, the customer feedback on that prototype, and a clear next step — build, kill, or iterate.

This is the moment when budget gets approved or denied based on real evidence rather than imagined business cases. Leaders make better decisions in this conversation than in any other product investment conversation, because the question is no longer should we build this? It is here is what users said about a working version, what should we do next?

If the answer is build, the team has commitment, budget, and direction — secured in roughly four weeks of elapsed time, with a fraction of the political work normally required.

A real example: a traffic management AI that wasted a year, then validated in four days

A technology company building AI for city traffic management approached us with a familiar problem. They had a strong technical team — deep AI expertise, video processing capabilities, real engineering capacity. They wanted to build an AI solution that combined live video with multiple data sources to help cities optimize traffic flow.

They had been at it for roughly a year. The product lead was a senior AI engineer with serious technical credibility, and the team had been writing real code: building features, training models, prototyping the actual product. After twelve months they were stuck. The MVP was not converging. The team did not know which features mattered. Costs were mounting and there was no validated demand to point to.

The pattern was textbook tech-first. The team had started with what the technology could do — video plus AI plus traffic data — and worked outward toward an application. Customer interviews had been done, but the product decisions were being driven by the model's capabilities, not by what traffic engineers actually needed.

The core question we used to reframe the project was: "What is something every city in the world will buy?" Not what is technically possible. Not what is impressive. What is something a real city, with real budget pressure and real political constraints, will sign a check for.

A second insight changed the trajectory: no matter how good the AI, traffic engineers would not use a system they did not trust. The user is not a casual consumer. A traffic engineer is a domain professional whose decisions affect public safety and city operations. If the AI is a black box, they reject it. If they cannot understand why a recommendation is being made, they will not act on it. The trust gap is a primary risk in AI products with professional users — separate from the technical performance of the model.

What the four weeks looked like

Discover (one to two weeks). All existing data was gathered: sensor feeds, traffic light data, camera streams, the full list of available signals. In parallel, the team interviewed traffic engineers to understand how they actually navigate their work — what they monitor, what they ignore, how they make decisions, what overwhelms them. The output was a complex but readable map showing the data sources alongside the human workflow that uses them. The empathy point was hard to miss once the data was visualized: traffic engineers were operating across ten to twenty screens of dashboards, with phones ringing, while trying to spot a broken-down car on a roadside camera.

Decide (one day). A Problem Framing workshop with the client's senior decision-makers. The customer journey map and traffic engineer interview insights were on the walls. The leadership team identified several business opportunities, then narrowed to a single use case worth building an AI solution around. The decision was made with full leadership commitment to back the work that followed.

Experiment (four days). An AI Workflow Sprint with the cross-functional team — traffic experts, AI engineers, product, design. By the end of the week, they had a working prototype that mimicked how the AI would behave in a real traffic operations center.

Learn (in the same week). The prototype was tested with traffic engineers. The questions answered were the trust questions identified in the framing: did they understand it, did they trust it, did it make their job faster, easier, and better? The answer was yes.

Decide and Execute. With validation in hand, the client moved to development. The product launched roughly a year later and is now in operation.

The outcome the team wanted in twelve months happened. The validation that should have come first arrived eleven months late — but it arrived. Had the same process been used at the start, the product would have been on the market a year earlier. That year is the cost of starting with the technology.

‍

Where to start

If an AI project is on your plate this quarter and the team is already deep in technology decisions, the first move is not to redirect the technology. It is to pause and ask whether the customer side of the work is real.

A simple test: can a member of the team describe, in concrete terms, the moment in a real customer's day when the AI feature would change something for them — and is that description based on having watched or talked with that customer recently? If yes, keep going. If not, the project is in tech-first territory and the cost of continuing without correcting is the year that the traffic management team spent building the wrong thing.

The correction is not expensive. It is one Problem Framing day, two days of subject matter expert time over four weeks, and a single sprint cycle. The output is a validated direction backed by real customer feedback and explicit leadership commitment. That foundation is what every successful AI product is built on. The teams that skip it are not moving faster — they are just losing the year more quietly.