In conventional software development, progress is relatively easy to measure. Features ship, backlogs shrink, and velocity gives teams a rough idea of how quickly they’re moving.
R&D doesn’t work that way.
When you’re building something new, the most important question often isn’t what should we build next?
Instead, it’s:
What do we need to learn before we can justify building anything else?
I’ve seen this firsthand. At Sparkade, I led an 11-person engineering team through Investment Committee gates. Later, I helped establish a 5-person incubator at Koda. Working across those environments changed how I think about technical leadership.
The job isn’t simply to keep engineers busy.
It’s to make sure the team’s effort is buying down the most important risk.
Build Around Questions, Not Backlogs
An incubator roadmap has a fundamentally different purpose from a product roadmap.
A product roadmap answers:
What are we going to ship?
An R&D roadmap should answer:
What are we going to prove?
I found a simple progression useful:
Venture Thesis → Technical Risk → Binary Deliverable → Investment Decision
Start with the broad business hypothesis, identify the technical assumption most likely to invalidate it, and design an experiment that can produce a meaningful answer.
For example, “build real-time collaboration” isn’t a particularly useful R&D milestone.
“Maintain synchronization latency below 50ms over WebRTC with 15% packet loss” is.
The second can be tested. It can succeed or fail. Most importantly, either outcome tells you something about whether the larger idea is viable.
Make Failure Cheap
The most expensive R&D projects aren’t necessarily the ones that fail.
They’re the ones that fail slowly.
Experimental approaches need explicit stop criteria. Give an architecture a defined amount of time to produce evidence. If it isn’t materially reducing the risk, stop and reassess rather than allowing sunk cost to determine the next sprint.
The same applies to dependencies. If an external service is critical to the architecture, identify alternatives before you’re trapped by it.
This doesn’t require heavy process.
A two-sprint experiment and a fifteen-minute decision meeting can save months of engineering work.
The objective is not to prevent failure.
It’s to discover failure while it’s still cheap.
Investment Gates Should Change Engineering
Investment Committee reviews are more than presentations.
They are decision points.
That means engineering milestones should exist to produce evidence for those decisions, not simply to create something impressive to demonstrate.
A useful deliverable might be a working prototype, a benchmark, a technical spike, or even a documented failure. If the experiment proves that the core assumption is wrong, that’s valuable information.
The team has still moved the project forward.
The unit of progress in R&D is not code. It’s reduced uncertainty.
When the Answer Is “Stop”
Eventually, some projects need to change direction or end.
When conditions forced a strategy shift at Sparkade, engineering stopped optimizing for new features and started optimizing for preservation.
Repositories needed to be organized. Intellectual property needed to be secured. Licenses and deployment systems needed to be documented. The remaining work needed a clear timeline.
Just as importantly, the team needed honest communication about what was happening. A project ending is already disruptive. Making people guess about the financial situation, timeline, or expectations only adds unnecessary uncertainty.
That transition also demonstrated something I hadn’t fully appreciated at the time: trust is an engineering asset. Several of the engineers who worked together at Sparkade eventually continued working together at Koda. The project ended, but the team’s ability to execute didn’t have to end with it.
The Principle of Fast Learning
Good R&D leadership isn’t about creating more process around uncertainty.
It’s about absorbing uncertainty so engineers can focus on the technical questions that actually matter.
Identify the biggest unknown. Turn it into a measurable experiment. Give the experiment a clear stopping point. Use the result to decide whether to continue, pivot, or stop. Then do it again.
When things get messy, the instinct is often to add more planning, more meetings, and more tracking. Sometimes the better answer is the opposite.
Cut the work down to the question that matters.
Early-stage engineering doesn’t need to move fast by building faster.
It needs to move fast by learning faster.