Finding the customer
The prototype was working. The customer was still being discovered.
The situation
I spoke recently with a founder building an AI voice product. The founder shared this story because they thought other hardware founders in the network might learn from it.
The original idea came from a personal experience and a belief that voice would become a more natural way for people to interact with computers.
The first product was a Bluetooth microphone button that allowed users to capture speech and use AI tools without constantly reaching for a keyboard or screen.
At the time, the founder wasn't focused on a specific customer segment. The goal was to get the product into people's hands and better understand who found it useful and how they were using it.
The plan
Early on, the founder found himself constantly debating what needed to be included in the first version. Local storage was considered. WiFi was considered. A more complex architecture was possible.
Through customer conversations, the scope gradually narrowed. The focus became building the simplest version possible and seeing whether people would actually use it.
Rather than spending heavily on custom hardware, the founder assembled the devices himself and started putting them in the hands of users. Over time, roughly 40 to 50 people tested the product.
The feedback was encouraging. People were using the product for dictation, note taking, and capturing ideas throughout the day. The hardware was inexpensive to build, easy to assemble, and quick to iterate.
The expectation was that continued usage and customer feedback would gradually clarify where the product fit best.
Where uncertainty remained
One of the more interesting parts of the conversation was that the product itself appeared to be working.
Users generally liked it and many were actively using it. But over time, some of them started drifting back toward software only solutions.
Small sources of friction kept showing up. The device needed to stay charged. Bluetooth occasionally needed to be reconnected. People would leave the device behind and fall back to the tools they already had available.
The founder described reaching a point where it became difficult to tell whether the next step was improving the product or better understanding the customer.
At the same time, there were plenty of additional features that could be built. More integrations. More functionality. More ways to improve the device itself.
Every next step required more engineering effort. The challenge was deciding whether another feature would create clarity, or simply build more product for questions that still hadn't been answered.
What needed to be proven first
Rather than continuing to improve the button, the founder started spending more time asking a different question:
Who actually experiences this problem every day?
That shifted the conversations toward construction crews, retail operations, hospitality teams, and data centers, all environments where voice communication was already part of the workflow.
Instead of discussing how people wanted to interact with AI, the discussion became more about how information moved through an organization and where communication delays created operational friction.
Those conversations led to a different product direction.
Today, the company is deploying systems that connect two way radios with software tools and operational systems across several pilot environments.
The pattern
This kind of situation comes up fairly often in hardware.
A prototype begins as a way to validate a product idea. Along the way, it starts revealing information about the customer instead.
The challenge is that product progress can continue while important questions about the customer, workflow, and use case are still being answered.
If you're in a similar spot
If you're building an early product, it can be useful to step back and ask whether the next engineering effort is helping verify the solution - or validate who the solution is for.
In many cases, the answer changes what gets built next.