What Actually Happens During Connected Product Discovery?
Discovery is often described as the work that happens before development begins. For connected products, it is much more than planning.
A connected product may involve hardware, firmware, cloud infrastructure, mobile software, and several specialized teams working at once. Because every component must work together, early alignment is essential.
As we explored in Why Great Connected Products Fail Before a Single Line of Code Is Written, many costly product problems begin with unclear goals, untested assumptions, and unresolved decisions. Discovery addresses those risks before separate teams begin building.
Why Discovery Is Different for Connected Products
Connected product development is several interdependent projects happening at once.
Hardware must support the intended functionality. Firmware must control the device and communicate with other systems. The cloud must process data. The application must turn that data into an intuitive experience.
A simple software change may require weeks of firmware work. One delayed component can block other teams and increase costs.
The main issue: when teams begin with different assumptions.
The application may depend on data the device cannot provide, or firmware may support one behavior while the software team expects another. Discovery identifies those dependencies early and creates agreement around how the complete system should work.
1. Understand the User’s Environment
Discovery should begin with the people using the product and the conditions in which they will use it. Consider questions like:
Who is installing the device?
Who will use the application?
Where will the product be located?
What is the user trying to accomplish?
What environmental or connectivity issues could affect the experience?
Connecting a water softener in a basement is different from connecting a sprinkler system outdoors. The person completing the setup may be a trained technician, a homeowner, or someone with little technical experience.
Those circumstances influence hardware decisions, connectivity requirements, onboarding, and interface design.
2. Identify the User’s Most Important Jobs
Once the team understands the user and the environment, discovery shifts to the customer’s “jobs to be done.”
Those jobs might include:
Connecting the device
Viewing collected data
Controlling it remotely
Receiving alerts
Monitoring performance
Troubleshooting problems
The goal is not to document everything the product could do. It is to identify what creates the greatest customer value.
A sprinkler-system user, for example, may care about more than turning the device on and off. They may want to monitor water use, identify inefficiencies, set up a schedule, or know when the system needs attention.
Discovery separates valuable capabilities from features that add complexity without improving the experience.
3. Align the Technical System
The team must then define how the product will function.
How will the systems communicate?
Will the product use Bluetooth, Wi-Fi, cellular connectivity, or another protocol?
Where does the data originate?
What can the device transmit?
What must the cloud process?
What should appear in the application?
These decisions cannot be made independently.
An application cannot display data the device does not generate. Firmware cannot support interactions the hardware was not designed to accommodate. Cloud architecture must account for the data being transmitted.
Product leaders clarify goals and requirements. UX professionals focus on the customer journey and usability. Solution architects examine hardware, firmware, connectivity, cloud infrastructure, and data.
Together, they turn a broad vision into something every delivery team can act on.
4. Make the Product Tangible
Written requirements are useful, but different people can interpret the same language differently.
A clickable prototype can make the experience tangible, though.
Stakeholders can move through the application, see how information is presented, and understand what follows each action.
This is especially valuable during device onboarding, when customers may need to activate hardware, enable Bluetooth, enter network credentials, wait for confirmation, or recover from an error.
Prototyping helps identify missing instructions, unnecessary steps, unclear terminology, and overlooked scenarios before they become code. It also gives stakeholders, designers, and developers a shared reference for how the product should behave.
5. Create a Shared Plan Before Development
Discovery is not always a single meeting with every participant in the room.
It often begins with stakeholder and user interviews. Product leaders and UX professionals gather information about the customer, business goals, intended experience, and core problem. Technical experts explore the device, architecture, data, and connectivity requirements.
Product management, design, and solution architecture then develop an initial concept and refine it through stakeholder feedback.
Questions surface. Then assumptions are tested. Requirements become more specific. The prototype evolves.
Once development begins, hardware, firmware, cloud, and software teams move into separate workstreams and often work in parallel. It is similar to building a tunnel from opposite sides. Each group performs specialized work from a different starting point, but both sides must meet at the same destination.
Discovery gives each team a common plan before they separate. It cannot eliminate every surprise, but it can prevent substantial rework and delay.
Better Development Begins With Alignment
Discovery may appear to add time before development—especially when it feels like it’d be better to hit the ground running. In practice, though, it gives hardware, firmware, cloud, software, product, and design teams a shared understanding before major investments are made.
For connected products, that alignment is what makes coordinated development possible.
The earlier teams agree on the destination, the more likely they are to meet in the middle.
Learn more about how Outside Source builds inspiring connected product apps. Contact us today.