Why Innovation Needs Room to Wander?

I feel weirded out when people speak about innovation frameworks.

Especially when there is a timeline attached to it. Define the problem, run a workshop, test a few ideas and present the answer 28 days later.

I understand why we do this. Engineering time costs money, and somebody has to decide which ideas are worth pursuing. But then how do you put a deadline on finding an answer when the team is still trying to understand the question?

An engineer might spend a week following something odd in the data and come back with a rather different view of the problem. On the project tracker, that week looks like a delay. Yet the detour could change what the team needs to build.

I call this scatterbrain innovation because sometimes a team has to go all over the place before it figures out what the problem actually is.

An adhesive looking for a problem

In 1968, Spencer Silver was working on adhesives at 3M. He ended up with something unusual. It stuck lightly to a surface and could be peeled away again. The company had been looking for stronger adhesives. Silver had an interesting material and no clear product to put it into.

He kept sharing it with colleagues. In 1974, Art Fry, who also worked at 3M, was frustrated with the bookmarks that kept slipping out of the hymnal he used while singing in his church choir. He remembered Silver’s adhesive, tried it on paper and found that it could hold a bookmark in place without damaging the page.

Fry’s idea still had a long way to go before anyone could buy it. There were questions of manufacturing, product design and whether customers would use the notes. The product was tested in four cities in 1977 and launched across the US as Post-it Notes in 1980.

How would Silver’s experiment have fared in a review at the end of its first month? 3M had been trying to develop stronger adhesives. He had come back with one that could be peeled off. Try putting that on a status report without a rather long explanation.

Of course, the original adhesive was only the beginning. People at 3M had to work out how to produce it consistently, make it useful and get it into customers’ hands. That took years. A team working against a customer deadline may only have weeks, and I wouldn’t suggest copying 3M’s timeline. Still, I wonder whether Silver would have had those years if somebody had decided that the first experiment had failed and should be shut down.

What a 28-day report can miss

Consider a team trying to measure parcels in a warehouse using cameras. The system needs images clear enough to identify a parcel and calculate its dimensions. Comparing cameras and improving the software seems like a sensible place to start.

Then the warehouse gets in the way. A shadow hides a parcel’s edge, or a reflective surface makes the image hard to interpret. You can spend another month tuning the algorithm, but you could also move the camera or change the lighting. At some point, you may have to question the measurement setup itself.

That kind of work is going to look scattered on a weekly report. Experiments pull in people from different functions, and by Friday even the camera specification may have changed. But the questions have a sequence: which part of the system is failing, what can we change, and what does the next test tell us?

I’d be careful about defending every detour, though. A team can spend a month playing with cameras and come back with a wonderful collection of trials but no explanation of what it has learnt.

Teams can keep improving a process that already works or spend resources testing an approach whose value is uncertain. Improving an established process usually gives you feedback sooner. With exploration, you may have to accept weeks of work before you know whether anything useful is coming out of it.

At the 28-day review, I’d still expect an explanation if the team promised a working system and hasn’t delivered one. Perhaps it has ruled out the camera it intended to buy or discovered that the warehouse environment makes the initial setup unworkable. Fine. What changed because of that finding, and what does the team propose to try next?

If nobody can answer, I’d hesitate before giving the team another month. An experiment that teaches us nothing is a poor use of time, however interesting it was to run.

I also wouldn’t assume that people who describe themselves as scatterbrained are naturally more creative. I’d give an unexpected result a fair test and use what the team learns to decide whether it’s worth pursuing.

I’d still ask for a plan and a shipping date. But I wonder if our insistence on a neat short-term answer sometimes stops people from finding out whether the original plan made sense.

If a team spends 28 days proving that its first plan was wrong, what exactly should the review say? I’d like to have that discussion before marking the whole month red on the status report.