When does an initiative become innovation?

**Skill and decision.** Portfolio reports often collapse four different states into one number: a recorded idea, a tested prototype, a service made available to intended users, and a process actually brought into organizational use. Reporting all four as “innovations delivered” makes it impossible for a board to tell what has been achieved and what remains a bet. This lesson builds an evidence register that ties an innovation claim to the changed product or process, the difference from previous practice, and proof of availability or use. The Oslo Manual does not require commercial success before a qualifying implemented change can be recorded as an innovation. But an idea, patent, or internal demonstration by itself does not prove implementation.

First specify the **comparison unit**. An internal calculation tool can be compared with the firm's previous process; it need not be new to the world. A service offered to buyers is compared with the firm's prior offer. The substantial change may concern a product, a business process, or both. A technology label is not evidence. Saying “AI powered” does not tell the board what changed for users, operators, or decisions. Describe the old function, the new function, and the source used to check the difference. Separate **innovation activities**, including search and trials, from an **implemented innovation outcome**. Both matter to portfolio management, but they should be measured differently. A count of controlled experiments describes learning activity; a count of changes brought into use describes output. Neither count, by itself, demonstrates realized benefit.

An evidence register can use seven fields: initiative identifier, prior state, improvement, recipient or operating user, date of first availability or use, reviewable proof, and a separate status for measured effects. A release record and aggregated access sample can support the availability of a service. An operating instruction and transaction sample can support the use of a new process. A note that a team approved an idea is not proof of availability. The board need not receive personal data: a restricted link or aggregated sample can make the claim reviewable while protecting users. Where a field trial covered only one branch, say “in one branch” rather than “across the organization.”

Resolve a predictable disagreement. Marketing wants to announce four innovations; operations wants to wait for company-wide rollout. A defensible report shows all four in a pipeline with their distinct states, counts only the two qualifying implemented outcomes within their limited scopes, and schedules separate effect measurement. If the interface in C merely changed color without a significant functional difference, it fails the change test and should not be counted as an innovation merely because it was released. Maintain the same definition across initiatives, including the favored one.

**Source limit.** The distinction between product and process innovation and the requirement for availability or actual use follow chapter 3 of the Oslo Manual 2018. The company, dates, and numbers are authored instructional examples, not data attributed to the source. This statistical definition also does not replace an investment decision, which needs evidence on benefit, cost, uncertainty, and risk. [OECD/Eurostat, Oslo Manual 2018, chapter 3](https://www.oecd.org/en/publications/oslo-manual-2018_9789264304604-en/full-report/component-9.html).

**Using the register in a live portfolio.** Never present an “innovation rate” without naming its denominator and time period. Suppose the company has 20 initiatives under consideration, five have started trials, and two have introduced a qualifying change into use. The ratio 2/20 = 10% describes the share of registered initiatives that reached an implemented state under the reporting convention. It is not a general “success rate for innovation.” Some initiatives may have entered the portfolio only recently, while others are still performing valuable learning work. Record entry and exit dates for each stage so the report does not treat an immature initiative as failed. Show transition time, cost of learning, and the reason for stopping beside counts; otherwise teams may be rewarded for announcing fast launches with no sustained use.

When classification is disputed, apply a reversal test: what single piece of evidence would change the classification? For B, documented real use by drivers might move the initiative beyond simulation, provided the new process differs significantly from prior practice. For C, absent access by intended users or a purely cosmetic change could defeat a product-innovation claim. Do not collapse C and D into one outcome solely because they share a project number, and do not automatically count twice if they are two descriptions of one implemented result. State the unit of counting in the report and link related components. An independent reader of the evidence register should be able to retrace the decision without accepting the project owner's enthusiasm as proof.

**The boundary of “made available.”** A button appearing in an internal test environment does not show that an intended user could access a product. Name the intended user group, enablement date, and any conditions that still block access. Two customers may have active accounts yet never receive the credentials needed for the feature; a release record alone would then be incomplete evidence. Conversely, a service can be available while some users choose not to use it. Availability and adoption are different measures. For an internal process, seek evidence that the procedure actually entered the workflow, not merely that management issued an instruction. Keep three evidence layers distinct: availability, use, and benefit.

Suppose a firm sends an interface update to five hundred customers, but two hundred run a version that does not display the feature. “Sent to five hundred” is not the denominator of those who could use it. Check activation and access logs by customer group. If the new interface only moves buttons without a significant functional improvement, do not automatically report a substantial innovation. Describe whether the difference matters for the function or benefit compared with the firm's earlier offer. “Significant difference” needs an explained comparison, not simply a count of releases. Smaller adjustments may still be operationally worthwhile without each becoming a separate innovation outcome in the register.

Do not erase an initiative stopped after a useful trial from the pipeline merely to improve the apparent implementation rate. Create distinct reports: implemented outputs under the Oslo Manual definition, and portfolio learning that records stopped tests, reasons, and cost. If stopped initiatives disappear from the denominator, a calculated rate might rise from 2/20 to 2/10 without any new output. State the inclusion and exclusion rule and date. A single ratio cannot evaluate learning culture, selection quality, and delivered innovation at once; each question needs its own measure.