---
title: "A technology roadmap for a new product: from prototype to market | R&D COPILOT"
lang: en
canonical: https://rdcopilot.com/insights/technology-roadmap-new-product/
content_version: 9817d06280c44c892f70475e3a8f11f54b934660c6a507ba27e216eeb3a526e9
contact: https://rdcopilot.com/contact/
---

[RDC](https://rdcopilot.com/) [Insights](https://rdcopilot.com/insights/)Product and technology advisory

Product and technology advisoryHow-to guide

# A technology roadmap for a new product: from prototype to market

Most new products stall in the space between a promising prototype and something a customer can buy. The engineering is rarely the only gap: the team is unsure which parts are genuinely new, which standards apply, what is worth protecting and who decides when a stage is finished. A technology roadmap closes that gap when it is written as a working document with owners, evidence and dates, not as a slide with arrows. This guide shows how we build one with a product team and how it becomes work the company can actually track.

By R&D COPILOT7 October 20265 min read

In this guide

1.  [Separate what is new from what is standard](https://rdcopilot.com/insights/technology-roadmap-new-product/#guide-section-1)
2.  [Use maturity levels as a shared vocabulary](https://rdcopilot.com/insights/technology-roadmap-new-product/#guide-section-2)
3.  [Name the evidence before the work starts](https://rdcopilot.com/insights/technology-roadmap-new-product/#guide-section-3)
4.  [Map standards and certifications early](https://rdcopilot.com/insights/technology-roadmap-new-product/#guide-section-4)
5.  [Decide how each part makes money](https://rdcopilot.com/insights/technology-roadmap-new-product/#guide-section-5)
6.  [Give every item an owner and a review date](https://rdcopilot.com/insights/technology-roadmap-new-product/#guide-section-6)
7.  [Turn the roadmap into tracked work](https://rdcopilot.com/insights/technology-roadmap-new-product/#guide-section-7)
8.  [How we run this with your team](https://rdcopilot.com/insights/technology-roadmap-new-product/#guide-section-8)

[Sources & inspiration](https://rdcopilot.com/insights/technology-roadmap-new-product/#guide-sources)

## Separate what is new from what is standard

Start by listing every component of the product and marking each one as new, adapted or standard. A sensor enclosure bought from a catalogue, a login screen and a reporting dashboard are usually standard. A detection method, a calibration procedure or a labelled dataset built in-house may be new. The split matters because new components carry the technical risk, the protection questions and most of the evidence work, while standard components mainly need good engineering and sensible suppliers.

Be honest about “adapted” components. Taking a known algorithm and tuning it for a specific material or environment can be valuable, but the roadmap should describe exactly what changed and why it matters. That description later feeds the protection discussion and the product’s positioning, so it is worth writing carefully once. A first search in public patent databases such as Espacenet is a cheap way to check that “new” really is new before the team builds plans around it.

## Use maturity levels as a shared vocabulary

Technology readiness levels, the nine-step scale popularised by NASA, give engineers, managers and partners the same words for how far a component has progressed. You do not need to adopt the scale formally; grouping it into four bands is usually enough for a product roadmap. What matters is that each new component has a current level, a target level and a clear statement of what would prove the move between them.

Use maturity levels as a shared vocabulary
| Band | What exists | Evidence to collect |
| --- | --- | --- |
| Levels 1–3: concept | Principle described, first analysis or bench experiment | Calculations, experiment notes, a short feasibility memo |
| Levels 4–5: validated parts | Components tested in the lab, then in conditions close to real use | Test protocol, measurements, known limits |
| Levels 6–7: working prototype | Integrated prototype demonstrated in a relevant or real environment | Pilot report: passed, failed and open items |
| Levels 8–9: product | Qualified system, then proven in regular operation | Conformity evidence, user documentation, support process |

## Name the evidence before the work starts

A stage is finished when its evidence exists, not when the calendar says so. For every step on the roadmap, write down the measurement, test or document that will prove it, the acceptance threshold and who signs it off. This prevents the familiar situation where a prototype “works” in a demo but nobody can say under which conditions, with which data or with what failure rate.

Keep the evidence where it can be found again: protocols, raw measurements, photos, code versions and reviewer comments in one structured project space. A research workspace with search and page-level citations makes the later steps, from the standards map to the technical file for protection, much faster.

## Map standards and certifications early

Standards shape design decisions, so discovering them at the end is expensive. List the markets you plan to sell in, then the standards (European ones are published through CEN and CENELEC, international ones through ISO and IEC), regulations and certifications that apply in each one, and compare where they overlap and where they differ. Note the edition and the date you checked each source. Where a requirement affects hardware, data handling or software updates, link it directly to the component it constrains.

The same exercise shows where the team lacks experience. If nobody has worked with a particular safety standard or data rule before, the roadmap should include a learning step: a workshop, a written procedure and a named person who becomes the internal reference.

## Decide how each part makes money

Not every new component has to be sold as a product. Some are best used internally to lower costs or raise quality. Some are better licensed to a company that already reaches the right customers. Others belong in a partnership where each side brings what the other lacks. Decide this per component, because the choice changes what you protect, what you publish and which evidence a partner will ask to see.

Write a short business outline next to each route: who pays, for what, how often and what it costs to deliver. It does not need to be a full plan, but it should be specific enough to reject routes that do not add up.

## Give every item an owner and a review date

A roadmap without owners decays within a quarter. Before calling it finished, check each line against this list:

-   Component, its current and target maturity level
-   Evidence that proves the next step, with an acceptance threshold
-   Applicable standards and the date each source was checked
-   Protection option under consideration and whether anything has been disclosed
-   How the component makes money and the person responsible for it
-   Next review date and what would trigger an earlier review

## Turn the roadmap into tracked work

The roadmap becomes useful when its steps appear where the team already plans work. In practice we turn each stage into projects and tasks in ERP, with hours and costs recorded against them, so progress and spending are visible in the same reports management already reads. Partner and customer conversations about licensing or pilots live in CRM next to the opportunity. Pilots run in separate cloud test environments, and if the product includes devices, sensor data flows into IoT monitoring dashboards instead of spreadsheets.

Team training works the same way. Procedures written during the roadmap become short courses in eLearning, with completion records, so new team members learn the standards and methods without depending on one expert’s memory.

## How we run this with your team

We work in short, documented stages: component inventory, maturity and evidence plan, standards map, protection options and how each part makes money, then handover with training. Each stage ends with written outputs your team owns. Consulting is priced per stage, and anything outside the agreed scope is billed at a fixed hourly rate. When the roadmap calls for software, the same team builds and operates it, from ERP and CRM to AI, mobile apps and IoT monitoring, with a one-off setup fee and a monthly licence that covers EU hosting, updates and support.

Follow the references

## Sources & inspiration

### [Product Roadmap Generator](https://devpost.com/software/product-roadmap-generator)

Devpost project by Viet Dao

A roadmap tool that turns product ideas into features, epics, user stories and acceptance criteria, viewed across Now, Next and Later horizons.

This independently created project is credited as inspiration. The workflow and implementation guidance in this article are RDC’s analysis.

-   [NASA: Technology Readiness Levels](https://www.nasa.gov/directorates/somd/space-communications-navigation-program/technology-readiness-levels/)
-   [CEN-CENELEC: European standardization organizations](https://www.cencenelec.eu/)
-   [EPO: Espacenet patent search](https://www.epo.org/en/searching-for-patents/technical/espacenet)

Put the guide to work

## Start with your workflow.

Tell us what your team needs to do, which systems are involved and where the current process slows down.

[Discuss your project](https://rdcopilot.com/contact/?service=innovation-consulting) [Explore Product and technology advisory](https://rdcopilot.com/services/innovation-consulting/)

Product and technology advisory

## Keep exploring.

[All guides](https://rdcopilot.com/insights/)

Decision guide

### [Protecting software, algorithms and datasets: a practical checklist](https://rdcopilot.com/insights/software-ip-protection-checklist/)

Which protection fits code, algorithms, models and datasets, how to build the asset inventory and what to hand your IP counsel before anything is published.

[Read guide](https://rdcopilot.com/insights/software-ip-protection-checklist/)