Innovation management

Answer in brief

Innovation management is the deliberate work of choosing opportunities, testing possible responses and organizing their implementation. For a practitioner, its central question is: what should we learn or commit to next, and what evidence would justify that decision?

The OECD/Eurostat definition requires a product or process to differ significantly from the relevant unit’s previous products or processes and to be implemented. A promising idea alone is therefore insufficient, and implementation does not automatically mean success. This distinction helps separate activity from results. Oslo Manual 2018

What the discipline includes

Innovation management extends beyond generating ideas. It includes deciding where to search, allocating time and money, assessing uncertainty, helping teams learn, and arranging ownership once something enters everyday use. This article uses that broad working definition; it is an editorial synthesis rather than the wording of a single standard.

ISO 56002:2019 supplies guidance for establishing and improving an innovation management system across different kinds of organizations and innovations. Its public abstract explicitly avoids prescribing particular tools. The standard should therefore not be treated as a mandatory funnel or workshop recipe. ISO 56002 overview

There is no single origin story offered here for the whole discipline. The sources serve different purposes: OECD defines terms for measurement, ISO organizes management guidance, and design practice provides approaches to exploring and testing possibilities. These are complementary perspectives, not interchangeable proofs.

Management question	Useful output	Decision it supports
Where should we look?	A bounded opportunity brief	Whether the problem merits attention
What remains uncertain?	A ranked assumption list	Which question to test first
What have we learned?	Evidence and limitations	Continue, change direction or stop
Can this operate reliably?	An implementation agreement	Whether to expand use
Is it creating worthwhile value?	Outcome measures and costs	Whether to sustain investment

The table and the sequence below are editorial practice guidance. They are intended to make decisions visible, not to promise a particular return on investment.

A CLOSER LOOK

Different uncertainties. Different decisions.

1. 01
   UnderstandWhat problem matters, and to whom?
2. 02
   ExploreWhich responses deserve a test?
3. 03
   ImplementWhat makes a useful response workable?

Revisit earlier questions when the evidence changes.

Begin with a useful boundary

Write an opportunity brief before asking for ideas. Name the people affected, the situation to improve, the strategic reason for attention and the constraints that cannot be ignored. “Explore AI” is a technology interest; “reduce the time service agents spend finding an approved answer” is a problem that can be investigated.

Keep the brief open to different solutions. If leadership has already selected a technology, record that as a constraint or hypothesis. Calling it a discovered user need would obscure the real decision.

Set a boundary around the first investigation: which service, which group and which part of the journey? Include dependencies outside that boundary. An apparently local delay might originate in another department’s approval policy.

Government Digital Service discovery guidance similarly asks teams to understand user context and wider journeys, including alternatives to building a new service. That is useful institutional guidance for this step, although it was written for government services rather than every innovation setting. Discovery guidance

Investigate before selecting a solution

Use several kinds of evidence. Observe the work, speak with people who experience it, inspect available records and check what previous teams tried. Each provides a different view. Interview statements can reveal a concern; a transaction record may indicate how often it occurs. Neither should silently stand in for the other.

Keep a small evidence log with three columns: observation, interpretation and unanswered question. For example, “six observed requests required clarification” is an observation within a specific sample. “The form is confusing” is an interpretation. “Which questions cause the clarification?” is a useful next inquiry.

Seek people whose experience differs from the easiest group to recruit. Include occasional users, operational staff and those who abandon the process. Explain where the sample is incomplete.

The Double Diamond is one way to organize this work. Its distinction between expanding exploration and narrowing a decision can help a team notice premature commitment. The Design Council describes the process as iterative. Framework for Innovation

Turn options into testable assumptions

Generate several responses to the same problem. An answer might involve information, workflow, a product, a partnership or stopping an unnecessary activity. For each option, write down what would have to be true for it to work.

Separate questions about usefulness from feasibility and operating economics. A solution can be technically possible while asking too much effort of its users. It can be attractive to users while remaining unaffordable to maintain.

Choose the uncertainty that could invalidate the next expensive commitment. Then specify a test:

1. State the assumption in concrete language.
2. Identify an observation that would support or challenge it.
3. Choose the least elaborate credible way to obtain that observation.
4. Set a time and resource boundary.
5. Agree who will interpret the result and make the next decision.

“People like the concept” is usually too vague. “A first-time user can complete the essential task with no facilitator intervention” is more observable. It is still only a test of that task in those conditions.

ISO’s innovation principles explicitly include managing uncertainty through experimentation and iterative learning within a portfolio of opportunities. The test format above is our practical interpretation, not an ISO-mandated template. Innovation management principles

Fund learning and implementation differently

An early investigation needs a budget sufficient to answer a question. A deployment needs credible provision for operation, support, training and ongoing maintenance. Asking an exploratory team for a highly precise long-term forecast may produce numbers that exceed the available evidence.

At a review, ask what has changed in the team’s understanding and what commitment it now seeks. Record four possible decisions: continue the current test, modify the approach, expand investment, or stop. Attach the reason and unresolved questions.

Look across initiatives as well as within them. Are several teams testing the same assumption? Does the portfolio depend on a scarce capability? Are small improvements crowding out exploration, or are speculative projects consuming capacity needed for current services? There is no universal allocation ratio recommended here. The appropriate balance depends on obligations, strategy and uncertainty.

Give stopped initiatives a short learning record. A documented disconfirming result can inform later decisions; an unexplained cancellation cannot.

Hypothetical example: a repair service

Imagine a manufacturer considering an app to reduce missed repair appointments. This is a fictional teaching example, not a reported company case.

The team initially assumes customers need better reminders. Discovery reveals three possible sources of missed visits: unclear arrival windows, difficult rescheduling and parts that are not ready. The team records these as hypotheses rather than declaring a single root cause.

It tests a simple rescheduling message and separately investigates the parts handoff. A prototype app would not answer the warehouse question. The next review compares customer effort, scheduling workload and operational feasibility.

Suppose the rescheduling trial appears promising in one region. The team still needs to examine what happens during peak demand, who handles exceptions and whether the scheduling system can support the change. A favorable trial warrants another decision; it does not establish national scalability.

Before expansion, operations accepts ownership, staff practice the revised workflow and the team defines how to monitor missed appointments and unintended delays. The innovation effort now overlaps with change management.

Measure value without hiding uncertainty

Build a baseline before implementation where possible. Track the intended outcome alongside operating cost and a measure that could reveal harm. For the repair example, fewer missed appointments should not conceal longer waits or an inaccessible rescheduling channel.

Government guidance on service benefits recommends establishing a baseline and updating estimates with evidence as delivery progresses. It also distinguishes projected benefits from observed performance. Measuring service benefits

As editorial guidance, pair measures rather than hunting for one universal innovation score. Count experiments only to understand work in progress; assess what those experiments resolved. Count launches only alongside use and outcomes. Examine benefits for different groups, especially when an average could conceal a worse experience for a smaller group.

Limitations and next steps

A process cannot make a weak opportunity valuable. Nor can experimentation remove every uncertainty before a decision. Rare events, long-term effects and changes in context may remain difficult to observe. Explicitly record those limits and who accepts them.

The sources here establish definitions and offer management guidance; they do not prove that this article’s sequence will outperform all alternatives. Use it as a starting structure and adjust it to the stakes.

For a first step, choose one current initiative and write its next decision, largest uncertainty and smallest credible test on a single page. Use a premortem to examine implementation risks, and revisit innovation versus invention if the team is treating technical novelty as evidence of value.