AndPlus acquired by expert technology adviser and managed service provider, Ensono. Read the full announcement

How to Develop A Product Strategy for Connected Devices

Mar 23, 2022 12:42:45 PM

The emerging connected-devices marketplace is huge, and growing rapidly. Estimates abound, and have been revised by the pandemic, but it’s in the region of $540 billion this year — up from $490 billion last year, and $290 billion in 2017.

While many IoT nets can be built from existing devices quickly and easily, it isn’t always the case. There’s a significant market for function-specific connected devices. Developing, building, and marketing these requires significant investment in product strategy to ensure good outcomes. In this post, we’ll talk about what product strategy is and why you need it, as well as how to create a product strategy specifically for connected devices and how we can help.

What is product strategy?

Product strategy is the process of determining what you want your product to achieve, and how you plan to achieve it. It ties business and vision goals to technical requirements and an understanding of the marketplace and ecosystem.

Product strategy should start with the ‘why.’ What is the reason your product needs to exist? Why do you care about it, and why should anyone else?

It also needs to include an understanding of how you’ll match your product’s features with users’ needs, via a business model such as lean canvas, Porter's 5 forces, or the 10Ps marketing matrix.

Consider positioning, competitor analysis, and goals. Then lay out the ‘jobs to be done’ to achieve those goals.

A fully-functioning product strategy should enable you to take a product to market knowing it has users waiting and is technically adequate to meet their needs.

Why do connected devices need a product strategy?

The Internet of Things has reached a tipping point, one where merely being technically able to participate isn’t going to be enough anymore. We’ve seen industry-standard hardware become increasingly commodified, a familiar experience from the IT revolution.

As the process continues, we’ll find that the companies that dominate or thrive in the IoT era are those with deep, long-term strategic vision. Connected devices will need a product strategy that centers on the needs, lifecycle, and processes of the user.

That will include a focus on user value, not customer journeys — getting people and organizations to success, not purchase. (SaaS and mobile application companies are already very familiar with this.)

IoT businesses that create products without a strategy may have the occasional lucky break. But there will be no reliable way to generate success without preparation and informed choices. These are only made possible by a comprehensive product strategy.

We can see this in the wider business world with the success of $6 billion unicorn Canva. Entering a marketplace dominated by Adobe’s graphics tools, Canva created a whole user demographic by being much simpler to use than its competitors. The vision — ‘just simple enough,’ in the words of Canva’s Cameron Adams — is backed by AI-enabled template recommendations.

Templates themselves are emphasized based on Canva’s own research, which shows that users are many times more likely to publish a Canva image if they’ve built it from a template. In other words, the vision is supported by feature choices and backed by data. Canva can show you six billion reasons why that’s how it’s done.

How to develop an effective connected device product strategy

Connected devices are more sensitive than non-connected products to the consequences of poor development decisions. Therefore, it’s necessary to plan and manage their development even more carefully. These vital considerations and decisions form that process.

Value first

Newly-launched connected devices face a challenging marketplace, one in which 75% of new IoT projects fail30% in the Proof of Concept stage. It’s imperative to create product strategies that center the user’s experience of value, especially if that value is unique. It’s crucial to consider that IoT devices aren’t used the way older, non-smart products are: in relative isolation. Instead, they’re constantly connected; that’s the point. It also accelerates the effects that any change in the network can produce. IoT customers will be looking for positive changes early. Product strategy for connected devices should therefore incorporate consideration of how these devices can demonstrate value convincingly and quickly.

IoT customer/user roles are even more telescoped than in SaaS: the route to purchase often includes labs and trials, and full-scale adoption will be determined in territory conventionally owned by success and support, not sales. Product strategy should be preparing for this from the beginning. Data acquisition should focus on it, seeking feedback from these crucial decision-making stages.

Test early

Just as users will test early, so should you. Testing shouldn’t be confined to technical elements, but should incorporate tests of assumptions and testing to failure. It’s common to focus on the process of actually building a product, and view testing as a way to check it works. But you should proceed the opposite way: testing is how each feature and iteration earns the right to exist. Those 30% of IoT projects that fail in proof of concept? They saved companies millions. Consider testing features on testbed platforms, imitating them on extant hardware, or virtualizing them. And don’t hesitate to invite comment, critique and analysis from people outside the organization.

Don’t build an MVP that tests things you know will work. Test your solution in terms of technical feasibility, business viability, and user need and usage patterns, and expect to be surprised.

Work together

Demolish internal silos and orient the whole organization or at least the whole team around the task. The traditional way of structuring a company is designed to support and maintain production and distribution of an already-understood product or service. It doesn’t work for novel processes. It’s common to give control of different stages of the project to different departments whose goals and incentives differ from each other, the company and the user base. This is a recipe for confusion, stagnation and failure. Instead, a team should be assembled from multiple departments with their focus on the project, rather than on departmental goals or interests.

A classic example of this, sadly common, is a major disconnect between marketing and product. Marketing wants a product they can sell; product wants marketing they can live up to. The result is a tug-of-war between people who should all be pulling in the same direction. The same can happen even on small teams if you’re not careful.

Iterative data strategy


You don’t get the benefits of an agile approach by treating it as ‘waterfall, but in little stages.’ The point is to use data to improve. That should include feedback from users, used to improve the product. It should also include feedback from staff, used to improve the development process. So there should be an iterative data strategy in place from day one. Most modern software companies know this, and since the knowledge is general throughout the development world, it’s increasingly the normal approach.

But product companies are sometimes not so clear on it, so it makes sense to lay it out here. It’s a three-stage process:

1: Identify useful data

It’s a truism that we used to struggle to get data, and now we struggle to get insights from it. The solution is to work back from what decisions we want to make, then identify what data would support those decisions. Once we know that we can either retrieve and organize historical data or begin collection and analysis.

2: Collect and manage data

Once an MVP version of your product is up and running you can start collecting data and storing it for analysis. If you’re collecting data on the development process you can start before the MVP is even launched.

3: Organize and analyze data

This is the stage many businesses never get to, product companies or not. In large part that’s because they don’t take stage 1 seriously enough. If you’re getting data that bears on decisions you’ve already identified as important it’s much easier to draw usable insights from it. When that’s done, those insights need to be fed back upstream to inform decisions about product features and development.

When we helped Alerton create a control portal for their Building Automation and Control (BAC), we had to build user paths for the product — and select and modify hardware too. Using two-week sprints let us feed data from code reviews and tests back into the development process. The result, running on a custom tablet that boots straight to the application, is being used to manage building climate across the US. (Learn more: read the case study.)

How AndPlus can help

AndPlus has been working with product businesses to build new tools and systems since our earliest days as a company. We know how product companies differ from software businesses, and the pressures that come with creating physical products. And we know how to bring the tools and techniques of modern development to bear on the creation of new physical tools as well as the software required to operate them.

Crucially, our team of experts has experience building the kinds of data feedback loops that let you get the advantages of the agile development process in product development. We know how to choose the right data points from the start; how to craft prototypes, Proof of Concept, and MVPs that actually tell you what you need to know; and how to build, consult with, or contribute to teams that can work effectively on successful product development projects.


  • Connected-device product development relies on careful data selection, organization and analysis.
  • Teams working on development projects can be seriously hampered by the silos that often separate departments in more conventionally-structured product businesses.
  • A majority of connected device projects don’t make it to market; a third don’t make it out of proof of concept. Validate early and thoroughly to cut losses and focus efforts effectively.
  • IoT purchase cycles are often differently shaped to traditional products and involve more trial and test-use; sales, support and success can all be working with the same people.
  • Creating a successful connected device is often easier with an experienced development partner to offer consultation, guidance and technical skills where needed.

Featured Image Source

Brian Geary

Written by Brian Geary

Brian is a true believer in the Agile process. He often assists the development process by performing the product owner role. In addition to his technical background, he is an experienced account manager with a background in design and marketing.

Get in touch