Move in With Customer experiment

We're building a comprehensive knowledge library about product development as part of our mission. The library is for anyone looking to make better decisions — primarily decisions about product development. Whether you're an inventor, a product manager, or a Chief Product Officer, using the right research methods and experiments increases your chances of building the right things for the right audience. Today we'll introduce the Move in With the Customer validation method.

When to Use This Experiment?

The Move in With the Customer method is a good fit when access to real users is hard to come by and you need to understand the product in its actual environment. The goal is to grasp the customer's problems as fully as possible and iterate with customers right on the spot where the problem is.

It works well when:

• the team is building a product for business (B2B) customers, where direct access to users is rare and quality feedback even rarer.

• you need to understand the context of the environment, the connected tools, and operational constraints.

• several stakeholders shape the buying decision and need to be uncovered.

• there's a customer willing to host the team and for whom the collaboration makes sense.

Basic Experiment Principles

The heart of the experiment is to literally move in with the customer — move the the product team right inside customer's office or plant operation and, for a set period, watch customer's day-to-day processes from the inside. Instead of surveys and controlled tests, you rely on everyday observation in the natural environment.

1. Pick a partner. Find a customer willing to host the product team and for whom close collaboration has value. The willingness to grant access is itself the first signal of interest.

2. Agree on mutual benefit. Set up the partnership so both sides gain — the customer gets faster solutions to their problems, the team gets access to reality. Define the scope, the length of the stay, and the expectations clearly.

3. Move the team onto the customer's site. Place one or more product managers directly at the customer office or plant operations — whether at several companies in parallel or one after another. The point is to be in the heart of the action, observe the processes, and the decisions, not to watch them from a distance.

4. Observe and collect data. Systematically record how the customer works, which tasks they tackle, and what slows them down. It pays to track the job-to-be-done ranking, the order of needs, wants, and pains and user stories, plus your own observations. A strong signal to standardize a solution into the product is the moment the same pains and tasks occur across several host customers — one and the same problem confirmed at two or more independent companies.

5. Identify the risks. The method carries several significant limitations. The sample is small, so the findings are directional, not statistically robust. There's a risk of tailoring the product to a single customer instead of finding the common core. The team's mere presence can distort the customer's behavior. The method is also costly, slow, and pulls the team away from regular work. And deep understanding of needs doesn't guarantee the whole business model will succeed — it confirms desirability, not viability.

Real-World Experiment Example

Link to research: Inside Tesco's US nightmare

In 2006 the British chain Tesco was preparing to enter the US market. Before launching its new Fresh & Easy format, Tesco sent 50 senior managers to live with American families — picked by a market research firm — for two weeks. The aim was to understand up close how Americans live and shop.

In parallel, the team built a fully functioning mock store in a Santa Monica warehouse — passers-by were told it was a film studio — and invited more than 200 focus groups inside. Direct observation surfaced concrete differences from European habits: American shoppers preferred to stock up on long-lasting goods rather than buy fresh food daily, and they disliked self-service checkouts.

What Can Be Tested With This Experiment?

The method is strongest exactly where ordinary research falls short — it reveals how the customer actually behaves, not how they describe their behavior. It's especially suited to validating the following:

• Customers' real motivations: what the customer truly "hires" the product for (jobs-to-be-done), observed in the context of their work. The signal is the same task recurring across several observed users.

• Context and conditions of use: the environment, connected tools, and constraints (legacy systems or established procedures, for example). It's confirmed by friction points that show up repeatedly.

• Stakeholders and the decision process: who in the company influences or blocks the purchase. The signal is uncovering hidden decision-makers a standard survey can't reach.

• Priority of pain points: which user problems are the most acute and most frequent, and therefore belong at the top of the product roadmap.

• Common patterns across customers: needs shared by several host companies, from which a standardized product — often B2B — can be built. It's confirmed by the same need at two or more independent customers.