Before you fund development
The roadmap changed when we stopped asking what to build and started asking what the next investment needed to prove.
The situation
I recently started working with a product designer starting his first hardware venture.
He had spent years helping other companies bring software and hardware products to market, and had now developed a concept of his own: a new creative technology product for children. He had already built early prototypes, worked through much of the product experience, and started assembling an investor deck.
He was also beginning to think seriously about how much money he would need to raise to get the product to market. The product would require meaningful hardware, software, content, and manufacturing investment, so one of the questions on his mind was how much money he would need to raise to get it to market.
The plan
His initial thinking was fairly logical - raise enough money to continue prototyping, develop the product, get it ready for manufacturing, and eventually produce the first meaningful run of units.
He had seen other consumer hardware companies require significant capital to get the product right, and he didn't want to raise most of what was needed only to run out of money before reaching the next milestone.
When we started working together, part of our job was to help connect the pieces behind that plan. We worked through the product definition, customer needs, business model, financial assumptions, development roadmap, and fundraising story so they could be evaluated together.
Where uncertainty remained
As we worked through those pieces, the biggest question became less about how much it would cost to build the product. The harder question was what the company needed to learn before committing that money.
The founder had a strong product vision and a long list of things that would eventually need to happen: technical architecture, industrial design, software development, content, DFM, manufacturing, go-to-market, and production.
But moving through that list wasn't necessarily the same as reducing the most important risks.
A product could become much closer to production while the company still had open questions around who would buy it, how much they would pay, whether they would keep paying for additional content, and how the company would acquire them.
What needed to be proven first
That changed how we started thinking about the development roadmap.
Rather than treating the first phase as a smaller version of the full development program, we began organizing it around what the company needed to prove before earning the right to invest in the next phase.
One of the founder's ideas was to eventually put prototypes into roughly 20 families. That became a useful anchor.
What would those prototypes need to do to test the product with users? What could the company learn about willingness to pay, engagement, the business model, and customer acquisition before investing in production-ready design?
The hardware work still mattered - technical architecture, industrial design, software, and content all had to advance. But those activities now supported a specific business milestone: getting a useful product into customers' hands and learning whether the assumptions behind the business were holding up.
That also changed the fundraising conversation. Instead of only asking how much capital would be required to reach production, the founder began considering a smaller first raise tied to reaching that validation milestone.
The pattern
One thing I found interesting about this project is how easy it is for a development roadmap and a fundraising roadmap to become the same list of activities.
Build the prototype. Finish the design. Do DFM. Tool the product. Manufacture it.
Those are necessary steps, but they don't necessarily tell you when you've learned enough to justify the next one.
In this case, the roadmap became clearer once the milestones were framed around reducing uncertainty in the product, customer, and business model. Development became the mechanism for reaching those milestones rather than the milestone itself.
If you're in a similar spot
If you're raising money to develop a hardware product, it can be useful to ask what the next round of capital is supposed to prove.
The smallest useful milestone may not be getting closer to production. It may be getting enough of the product into the hands of the right customers to know whether the next investment is worth making.