Research vs. Experiment: What's the Difference in an Innovation Lab?

Two people on the same project can ask what sounds like one question and need two different answers. One wants to know whether anyone has solved this before. The other wants to know whether their version of it works. The first needs research. The second needs an experiment. Mixing them up is one of the quieter ways a lab loses a fortnight — usually by reading when it should be building, or building when the answer was sitting in a standards document.

The difference in one line

Research reduces uncertainty about what is already known. An experiment reduces uncertainty about what happens when you do something.

Research looks outward: prior art, published work, standards, supplier data, internal archives, and the experience of people who have already tried. It is how you find out what the constraints are and which options are still open. An experiment looks inward at your own build. You change one thing, hold the rest steady, and watch what the material, system, or person in front of you actually does.

A quick test that works most of the time: could the answer already exist somewhere, in a document, a data set, or someone's memory? Then research. Can the answer only come into existence after you make something and observe it? Then experiment.

When research is the right move

Research wins when the answer is cheaper to find than to generate. Some signals:

• The question is factual and someone else has already measured it: a material's tolerance, a known failure mode, a requirement your customer's procurement team will ask about.
• The test would be slow, expensive or unsafe to set up, and you want to narrow the field before spending anything.
• You need to know what has already been tried, so you avoid repeating a dead end or recognise a genuinely new angle.
• You are choosing between approaches and need criteria before committing to one.
• You suspect the real constraint is not technical at all — a contract, a supply chain, a habit — and want to confirm that early.

Good research in a lab rarely means reading alone. Twenty minutes with someone who ran a similar trial two years ago can save a month. Teardowns of a competing product, a walk through your own support tickets, or an afternoon in the archive of previous projects all count. The output should be a decision or a sharper question, not a longer reading list.

What makes something an experiment

An experiment has four parts. If any is missing, you are probably doing a demonstration instead.

1. A hypothesis, stated in advance, with a direction: "If we reduce the wall thickness to 1.2 mm, the part will still pass the drop test."
2. A single variable you are deliberately changing.
3. A measure agreed before you start, and a way of capturing it.
4. A decision rule: what result would make you stop, change course, or scale up.

Prototypes, pilots, bench rigs, A/B tests on a live service and task-based user sessions can all be experiments — but only if they are set up to answer something. "Let's put it in front of some users and see what happens" is a reasonable thing to do. It is not an experiment, and it will not settle an argument between two sensible colleagues.

Where the two get muddled

Three patterns show up again and again.

Research as avoidance. Reading is comfortable and always justifiable, so it expands to fill the time available. If a week of research has not produced a sharper question, stop.

Experiment as theatre. Building a demo for a stakeholder review feels like progress, but answers nothing if no measure and no decision rule were agreed first.

Using the wrong one for the question. A datasheet can tell you a sensor's operating range; it cannot tell you whether your users will trust the readings. Interviews can tell you what people say about a barrier; they cannot tell you whether they will push through it when a real screen is in front of them.

Muddles are usually a sign that the question was never written down. Vague questions invite whichever method feels most comfortable, rather than the one that would actually answer them.

A short sequence for deciding

1. Write the question in one sentence. If you cannot, you are not ready to choose a method.
2. Ask where the answer could live: in existing knowledge, in existing data, or only in something you build.
3. Estimate the cost of each route in time and materials, including setup.
4. Pick the cheaper route that can genuinely answer the question. If research narrows the field but cannot close it, plan both, in order.
5. Timebox it, and name the decision the result will feed.
6. Write down what you learned, whichever way it went. A test that fails is still an answer if it was set up properly.

Two examples from the bench

Suppose you are designing an enclosure for a sensor that will sit outdoors near the coast. The question is whether water and salt will get in. Research comes first: what an IP rating does and does not cover, material compatibility with salt spray, field reports from similar installations. That work narrows the design to two sealing methods. Now the question has changed into something research cannot settle: which of these two survives a spray and thermal cycling rig in your own workshop? That is an experiment, with a pass mark agreed before anyone switches the rig on.

Now take a different project: an internal tool people are supposed to use weekly. The question is whether they will. Reading about adoption will tell you about patterns in other organisations, not about your team. Here the useful first move is a small experiment — a two-week pilot with ten people, a measure of whether they come back in week two, and a decision rule about whether to build the full version.

Notice that in both cases the two methods worked in sequence rather than in competition. Research narrowed the options. The experiment decided between what was left.

Start with the question, not the method

A simple habit keeps projects honest. Before anyone books a user session or opens a browser tab, write the question on a whiteboard and ask two things: could this answer already exist somewhere, and what would we do differently depending on the result?

If the second question has no answer, neither research nor an experiment will help. If the answer already exists, go and find it. If it can only exist once you have built something, build the smallest version that can tell you — and agree the pass mark before you look at the results.

Labs rarely suffer from a shortage of activity. They suffer from activity aimed at the wrong question. Research and experiments are both ways of buying certainty; the skill is knowing which one you are actually shopping for.

Photo: Artem Podrez / Pexels