Start with a problem worth connecting
Connected-product strategy works best when it begins with a customer problem and a viable reason to solve it. Technology matters, but it should enter the discussion after the team understands who the product is for, what behaviour or operational problem should change, and where value will be created.
That sequence matters because connected products combine several risk domains at once: customer experience, hardware, software, connectivity, data, operations, support and commercial model. Choosing a preferred technology too early can lock the team into constraints before the most important use cases are understood.
Customer discovery can change the strategy
Customer discovery is therefore not a preliminary marketing exercise. It is a way to test which problems are important enough to justify the cost and complexity of a connected solution.
In one connected-product strategy engagement, the work combined analysis of sales information with interviews of more than 50 existing and prospective customers. The purpose was to understand use cases and demand before narrowing the technology direction. That evidence changed priorities and helped focus the product strategy on specific customer needs.
The useful lesson is not that every project needs the same number of interviews. It is that direct customer evidence can challenge internal assumptions. Interviews, observed workflows, support data, sales patterns and operational evidence can reveal that the most technically interesting feature is not the feature customers will adopt or pay for.
Test the commercial and operating model
A connected-product proposition also needs a commercial model that survives contact with operations. The hardware price is only one part of the economics. Connectivity, cloud services, installation, maintenance, support, returns, device replacement, security work and ongoing software updates can all affect lifetime cost.
For that reason, teams should test who pays, when they pay, what recurring value is delivered and what operating obligations the product creates. A use case that looks attractive at prototype stage may be weak if the service cost is high or if deployment creates more friction than the customer value justifies.
UX extends beyond the screen
User experience extends beyond the screen. A connected product may include physical setup, pairing, connectivity, permissions, notifications, account recovery, device behaviour, support and eventual replacement. A technically successful product can still fail commercially if those moments are confusing or unreliable.
UX work should therefore cover the full service journey. Product decisions about onboarding, failure states and support should be made alongside hardware and software decisions, not after engineering is largely complete.
Plan hardware and software as one delivery system
Connected products also create delivery dependencies that ordinary software teams may not encounter. Hardware lead times, certification, firmware, mobile applications, backend services, integration partners and network availability can all sit on the critical path.
The practical response is integrated planning. Teams need to see how a change in hardware, connectivity or platform choice affects the user experience, schedule, operating model and commercial case. Delivery leadership is especially important when different suppliers own different parts of the stack.
Choose platforms and ecosystems against the use case
Platform and ecosystem choices deserve the same discipline. Connectivity technologies, cloud platforms and device ecosystems should be selected against the use case, coverage, power, data, security, integration and operating requirements.
In that engagement, network technology options were evaluated only after the customer and use-case work clarified what the product needed to achieve. The exact technologies involved are less important than the decision sequence: customer evidence first, technical narrowing second.
Connect product-market fit to operations
The strongest teams keep product-market and operational questions connected. They ask not only “Can we build it?” but also “Will customers use it?”, “Can we support it?”, “Can we operate it economically?” and “What happens when something fails in the field?”
This is where connected-product work benefits from combined Product Management, Project Management and technology judgement. Product leadership keeps the customer and commercial proposition coherent. Delivery leadership keeps the cross-functional dependencies, suppliers and decisions visible. Technical specialists test feasibility and constraints.
Connected-product experience is a specialist strength within Milcane’s broader project, product and technology work; it is not the boundary of the consultancy. The same customer-led and decision-led principles apply to digital products and complex technology initiatives more generally. See Connected Products capability and Project & Product capability.
Matthew Tati
Matthew leads Milcane and has more than 20 years of experience shaping, delivering and recovering digital and technology-enabled projects and products. His connected-product work spans customer discovery, product and commercial strategy, technology evaluation, supplier management and delivery leadership.