When product progress outpaces validation
A founder conversation about traction, product, and risk.
The situation
I spoke with a hardware founder recently who is building a telemedicine device for remote care.
They’ve made progress. There’s a working prototype, it integrates with a range of medical devices, and they’re exploring a couple different directions - one for maritime use and another for home healthcare. They’ve also started having conversations with hospitals.
Most of the discussion was centered on raising money to finish the product.
The plan
The plan was to improve the hardware, work through FCC requirements, refine the design, and get the product to a place where it could be manufactured at volume. The assumption was that once the product was ready, selling and fundraising would follow.
At the same time, a few things were still unclear. The initial maritime market wasn’t converting. The healthcare direction was newer and still being explored. And while there was interest, there wasn’t yet clear evidence that anyone was ready to pay.
So the product was progressing, but the business itself was still uncertain.
Where riks compounds
At one point, the situation was described as needing more capital to make the hardware “good enough” to sell.
That framing comes up often in hardware - it puts the focus on finishing the product, when the underlying business question hasn’t fully been answered yet.
As more work goes into the product, constraints start to compound - around design, cost, and time. Each step makes the path forward a bit more fixed, even if some of the earlier assumptions are still being worked through.
What needed to be proven first
The conversation gradually shifted toward a different question.
Instead of focusing on what it would take to finish the product, it became more about what it would take to see someone actually use it and pay for it, even in a simpler form.
That opens up different possibilities. In some cases, that might look like running a pilot with a stripped down version, using off-the-shelf components, or testing the core experience without fully committing to custom hardware. In other cases, it might be conversations that lead to LOIs or some form of early commitment.
None of that replaces the need to eventually build the product. It just changes what needs to be proven first.
The pattern
This situation shows up fairly often.
There’s a pull to make the product more complete before putting it in front of customers. In hardware especially it can feel necessary.
At the same time, it can lead to a lot of progress on the product while some of the core questions about the business are still being figured out.
If you're in a similar spot
If you’re working through something like this, it can be useful to step back and look at what actually needs to be proven next.
In some cases, that ends up being less about finishing the product, and more about understanding how it’s going to be used, who is going to pay for it, and under what conditions.
That doesn’t always require the final version of the product to be in place.