R&D Roadmap: 12-Month Template With TRL Gates, Example and Metrics
9 min read ยท 2026-10-25
An R&D roadmap is a plan that shows which research and development projects your team will run over the next one to three years, why each one matters to the business, and when each should reach a decision point or move into product development. It links three layers: what the market and the business need, which products will meet those needs, and which technologies the R&D team must mature to make those products possible.
The template below covers 12 months in six phases, from setting R&D priorities to handing mature technology to product teams. It uses technology readiness levels (TRL) as gates, so every project has a clear next decision. It is written for heads of R&D, CTOs, research program managers and engineering leads who must plan R&D work and defend it in budget reviews. You will also find a filled-in example, who owns what, the metrics to track and the traps that let research drift away from the business.
The roadmap at a glance
Goal: By month 12, every R&D project is tied to a product or business need, has a current readiness level and a next gate date, and at least one technology has been handed to a product team with an agreed plan. Duration: 12 months
Strategy and needs (Weeks 1-6)
Agree on the business and product needs R&D must serve.
- Collect the product roadmap, business plan and key customer requirements for the next three years.
- Interview product managers, sales engineers and key customers about the capabilities they lack today.
- List external drivers: competitor moves, regulation changes, cost pressure and new materials or methods.
- Turn the input into 4 to 6 R&D themes, such as lower power use or faster test cycles.
Milestone: A one-page list of R&D themes, each tied to a product line or business goal, approved by the CTO and product leadership.
Portfolio review (Weeks 5-10)
Decide which current and proposed projects deserve funding.
- List every active and proposed project with its theme, team, budget and current readiness level.
- Score each one on strategic fit, technical risk, size of benefit and time to impact.
- Stop or merge projects that fit no theme, and record the reason.
- Balance the portfolio between near-term improvements and longer-term research.
Milestone: An approved project portfolio with a score, a theme and a funding decision for each project, recorded in the portfolio log.
Project charters and gate plan (Weeks 9-14)
Give each funded project a clear goal, plan and next decision.
- Write a short charter per project: hypothesis, target readiness level, deliverables, team and budget.
- Set the next gate for each project, such as proof of concept in the lab (around TRL 3 or 4) or prototype in a relevant environment (around TRL 5 or 6).
- Define the evidence needed to pass each gate before the work starts.
- Map capacity: people, lab time, equipment and outside partners per quarter.
Milestone: A charter and a dated next gate for every funded project, and a capacity plan with no team booked above its available time.
Research execution (Weeks 12-36)
Run the work in short cycles and report progress against evidence.
- Plan work in 6 to 8 week cycles with a demo or data review at the end of each.
- Keep a lab notebook or electronic record for every experiment, as your IP and quality rules require.
- Review IP with legal before publishing or sharing results with partners.
- Escalate blockers, such as missing equipment or supplier samples, at a monthly R&D review.
Milestone: End-of-cycle reviews held for every project, with results logged and readiness levels updated in the portfolio log.
Stage gates (Weeks 24-44)
Make go, pivot or stop decisions based on evidence.
- Hold gates with the CTO, the R&D lead and a product leader who would receive the technology.
- Review the evidence against the criteria set in the charter, not against hopes.
- For projects that pass, plan the next readiness step and its budget.
- For projects that stop, write a short close-out note so the knowledge is kept.
Milestone: Gate decisions recorded for every project that reached its gate date, with budget moved from stopped projects to the ones that passed.
Transfer and next-year plan (Weeks 40-52)
Hand mature technology to product teams and plan the next year.
- Agree a transfer plan for each technology ready for product development: team, documents, prototypes and support period.
- Add transferred technologies to the product roadmap with a target product or release.
- Review results for the year: gates passed, projects stopped, patents filed, transfers done.
- Update themes and the portfolio for next year with product leadership.
Milestone: At least one technology formally handed to a product team, and next year's R&D roadmap approved in the budget cycle.
R&D roadmap vs technology roadmap vs product roadmap
These three are often mixed up. A product roadmap shows which products and features ship and when. A technology roadmap shows which technologies the company will adopt or build, and how they support products. An R&D roadmap is the work plan for the research team: which projects, at which readiness level, with which gates and resources.
In practice, a strong R&D roadmap sits between the other two. Each R&D project should point up to a product or business need and point forward to the date it will be ready for product teams. A simple way to show this is a layered chart: market needs at the top, products in the middle and R&D projects at the bottom, with lines that link them.
Example: an R&D roadmap for a battery pack maker
Picture a company that designs battery packs for light electric vehicles. Customers want longer range and faster charging, and a new safety regulation is coming. The head of R&D has a team of 25 engineers and must show the board how R&D spending supports the next product generation.
The lines below show how the template could map to that situation, with an owner and a milestone for each block.
- Q1, strategy and portfolio (owner: head of R&D): four themes chosen, range, charging speed, safety compliance and cost. Twelve active projects reviewed, three stopped, two merged.
- Q2, charters (owner: project leads): a new cooling design aims for a lab proof of concept, a cell supplier test aims for prototype validation in a vehicle-like test rig.
- Q2-Q3, execution (owner: project leads): six-week cycles with data reviews, a patent filing for the cooling design reviewed by legal before a conference talk.
- Q3, gates (owner: CTO with product director): cooling design passes its gate, one cell chemistry project stops because test results miss the target.
- Q4, transfer (owner: head of R&D and product engineering lead): cooling design handed to the next-generation pack program with two engineers on loan for three months.
Who owns what
R&D projects can run for years without a decision if nobody owns the gates. Name a portfolio owner, and make sure each project has a lead and a product sponsor who will receive the result.
Write the roles down in the R&D charter and review them each year. If product leaders never attend gates, the technologies you develop will not have a home.
- CTO or VP R&D: owns the themes, portfolio and budget, chairs gate reviews.
- R&D program manager: owns the roadmap, the portfolio log, capacity plan and reporting.
- Project leads: own charters, experiments, results and readiness updates.
- Product sponsors: state the need, attend gates, plan the transfer.
- Finance partner: tracks spend per project and supports capitalization or tax credit questions with your advisors.
- Legal and IP counsel: reviews invention disclosures, patents and partner agreements.
Metrics to track
R&D results take time, so measure progress and quality of decisions, not only products launched. Report per project and for the whole portfolio, and keep the definitions the same from year to year.
Avoid counting activity alone, like the number of experiments run. A team can run many experiments and still not move a project closer to a decision.
- Readiness progress: readiness level per project at the start and end of each quarter.
- Gate outcomes: number of projects passed, pivoted and stopped at each gate.
- Time to gate: months from charter to each gate, compared with plan.
- Portfolio fit: share of budget spent on projects tied to an approved theme.
- Transfers: technologies handed to product teams and later used in a product.
- IP output: invention disclosures and patent filings, where IP matters to your business.
- Capacity use: planned vs actual time per team, to spot overload.
How to present it to leadership
Executives and boards want to know that R&D spending supports the business plan. Show the layered view on one slide: business goals, product lines and R&D projects, linked by lines. Add one slide with the portfolio by theme, readiness level and next gate date.
For each project, be ready to answer three questions: what problem it solves for which product, what evidence you have so far, and when the next decision will be made. Keep technical detail in the appendix. Show stopped projects openly, with the reason and what was learned. It shows the gates work and that budget moves to the best ideas.
How to adapt it
A startup with a small engineering team can use a lighter version: one theme or two, a simple spreadsheet portfolio and gates held in the founders meeting. Keep the habit of writing the evidence needed before each experiment starts.
In regulated fields such as medical devices, aerospace or automotive, R&D must connect to your quality system and design control process. Add document control, traceability and supplier qualification to the plan, and confirm the exact requirements with your quality and regulatory teams before you set gate criteria. In publicly funded or partnered research, add partner milestones and reporting dates from the grant or contract.
Common mistakes to avoid
- Funding projects with no link to a product or business need lets research drift, so tie every project to an approved theme and a product sponsor.
- Setting gates without written criteria turns decisions into opinions, so define the evidence needed in the charter before work starts.
- Never stopping projects drains budget from better ideas, so treat a stop decision as a good outcome and move the budget at each gate.
- Booking engineers above their real capacity delays every project at once, so build a quarterly capacity plan and leave room for support work.
- Sharing results before an IP review can block a patent, so route every publication and partner disclosure through legal first.
- Handing over a prototype with no support makes product teams restart, so agree a transfer plan with people, documents and a support period.
Frequently asked questions
What is an R&D roadmap?
It is a plan that shows which research and development projects a company will run, how they link to product and business needs, and when each will reach a decision or move into product development. It usually covers one to three years. It is reviewed at least once a year in the budget cycle.
How do you create an R&D roadmap?
Start from the business plan and product roadmap, and turn their needs into a few R&D themes. Review and score current and proposed projects, then fund the best fits. Give each a charter, a target readiness level and a gate date, and review the portfolio each quarter.
What are technology readiness levels?
Technology readiness levels are a scale, usually from 1 to 9, that describe how mature a technology is, from basic principles observed to a system proven in real operation. The scale was developed at NASA and is widely used in R&D planning. Many companies adapt the definitions to their own field.
How long should an R&D roadmap cover?
Many companies plan one year in detail and two to five years at the theme level. The right span depends on how long your development cycles are. Fields with long cycles, like energy or pharmaceuticals, often look further ahead.
How do you prioritize R&D projects?
Score each project on strategic fit, size of benefit, technical risk, time to impact and resources needed. Discuss the scores with product leadership rather than relying on the numbers alone. Keep a balance between near-term improvements and longer-term research.