If business units only ask your open innovation team for suppliers, they are showing you what they think your team is for. Changing that starts with which requests you take on, and what you ask after you deliver.

“I need to find a new supplier for a grinding wheel. Can you find it?”

Requests like this keep reaching the open innovation team of a global precision manufacturer. The team has one person, an Open Innovation Specialist, who launched its services this year. Other units ask her for a humanoid robot supplier, or a machine that produces tubes.

The requests make sense. The business units develop 80 to 90% of their work in-house, and before the team existed, outside help usually meant a local supplier someone already knew. But the partnerships the team exists for, with startups and universities, start from problems the business can’t solve alone. Few of those reach her.

In a Novum challenge call, she asked five open innovation peers how to change that.

Separate supplier requests from problems worth a partner

The team offers five services: monitoring emerging technology, mapping new fields, analyzing competitors’ innovation, scouting for partners and supporting pilots. Her manager, the company’s Head of Innovation and Technology, sees them as one process. It starts with a problem the business wants to solve, works through the options, and ends with a partner and a pilot. A supplier request skips that process. The unit already knows what it wants, such as a grinding wheel, and only needs someone to sell it.

One peer questioned the list itself: “If five things are important, none are important.” Another, who had run a similar small team across many business units, saw the same risk. “It sounds a little bit like you’re trying to be everything for everyone,” he said. His advice was to state clearly what counts as open innovation and what falls outside it.

Checklist: is this a problem worth a partner?

Run a request through these questions before taking it on.

  • Does the request tie to the unit’s goals, such as saving money, making money or growing market share?

  • Does the unit’s own R&D find the problem hard to solve, so an outside partner brings a clear advantage?

  • Did the unit already try to solve it internally, without success, while the problem still matters?

  • Could the solution build a capability other divisions can reuse?

Deliver the supplier, then ask about the problem

A new team still needs proof points, so turning requests down is hard. One peer offered a fallback “if you absolutely can’t” say no: deliver what the unit asked for, then open a wider conversation.

❝

“You want a grinder? Sure, here’s a grinder, but what’s the real problem you’re trying to solve?” The unit gets its supplier and starts to see the value of the team’s bigger offer.

Another peer has seen this approach work with a three-person open innovation unit at an industrial and chemical manufacturer of about 30,000 people. When the unit looked for water filtering technology, it scouted for options the business could put in place quickly. It also brought an engineer or a department head into each call. With every call, the business units grew more involved and shared more relevant problems. That let the unit set more ambitious goals.

Collect problems in short windows

Most requests reach the team in a burst right after she gives a 15-minute introduction at a management meeting, even though the team takes requests all year. In her experience, people come through the open door only after the team knocks on theirs.

One peer suggested planning those bursts: two weeks of taking requests, with the week before spent explaining how to submit one. To the objection that problems come up any day, he answered that companies struggling with outside innovation often take two months to decide whether to work with a startup, and three more to embed the solution. Next to that timeline, a few weeks’ wait costs little. The team can also compare requests that arrive together and pick the strongest.

Spend unsponsored time on a problem the business already tried to solve

Even for a quick pilot, the team needs a business unit to sponsor the work. One peer called that a catch-22, because the team has to wait for a business case before it can explore anything. He recommends keeping 30 to 50% of time and budget free for the team’s own ideas. Her manager agreed, and the team is already close to that: setting its strategy took 30 to 40% of its time this year, unsponsored. In the manager’s experience, a team that only takes requests ends up working on “the next incremental thing.”

For that free time, the same peer pointed to the central innovation team of a global conglomerate with dozens of divisions. That team’s outside ideas kept losing to internal projects, so it changed its timing. It waits until an important project fails internally. About six months later, it checks whether the problem still matters, and then runs an open innovation program on it. The business welcomes those programs, because it knows it lacks an internal solution.

At another company, he saw that kind of free work win a team its budget. The team spent about six months quietly on one cost-cutting challenge, then showed the savings to the CEO. “Where did that come from?” the CEO asked. The budget followed.

The first partners are inside

By the end of the call, the Open Innovation Specialist had three next steps: say more no’s than yes, take requests in windows, and find champions in the business units. Her manager called the champions a possible game changer.

Those champions are where the partnerships start. Before a one-person team can bring in startups or universities, it needs people inside the business who will share their hard problems with it. The three-person unit at the chemical manufacturer built exactly that. It brought champions from the business units into its scouting calls, and their trust in the unit grew one call at a time.

“They didn’t win it on the first time,” the peer said, “and they really built partnerships.”

Reply

Avatar

or to participate

Keep Reading