Internet of Things (IoT) developers are on the cutting edge of technology design and implementation. As such, there are fewer “tried and true” methods that have been proven to work, time after time, for companies building new IoT projects. Instead, entrepreneurs in the industry often have to wade through a field of trial and error before stumbling onto a formula that can get their product to market while the technology they’ve built is still relevant.
This can be difficult because IoT companies are still using principles that originated with other forms of technology development. However, many IoT companies are beginning to switch to an adaptable, customer-oriented mindset that is better suited to the rapidly changing IoT world.
Proof of Concept in IoT Doesn’t Necessarily Work Like It Does in Other Industries
A proof of concept (POC) is a bare-minimum prototype that proves that an idea would be feasible if it were scaled up to a useful size. By definition, it should be a lightweight, easily developed version of the more complex and robust final product. It’s a quick way to establish that your idea works and to satisfy investors and other stakeholders that you have the resources to build a final product.
The problem is that IoT projects often use massive amounts of data and require in-depth AI analysis in order to generate insights. When you’re dealing with huge data sets and the end product requires an advanced algorithm to make any sense of the numbers, scaling it down into an IoT proof of concept prototype is very difficult, if not impossible.
To prove its functionality and feasibility, a product would have to be nearly the scale of its final, releasable version. Any attempts to demonstrate a smaller-scale POC would not contain enough data to be usable.
When IoT businesses build proof-of-concept prototypes, they find it hard to get past this stage. They often get stuck because they have two choices: developing a mostly useless but small-scale project, or developing a fully fledged version that could demonstrate its worth to customers. The second choice is risky because the resources invested are wasted if the concept does not actually work or serve its intended purpose in the market.
This complicated choice is magnified when companies have to contend with quickly evolving chipsets, unexpected security issues, and other pitfalls that commonly occur during the POC stage.
Human-Centered Design Is Often a Better Option
Human-Centered Design (HCD) focuses on developing a product that solves problems that human customers are experiencing. This differs from the traditional approach that first examines the capability of the technology and the developers, rather than starting out asking how consumers might interact with the product after it is built.
Companies that prioritize an HCD way of thinking are often able to bring products to market faster than companies that still rely on developing proofs of concept. Rather than spending time designing and redesigning a POC that might not work and may not demonstrate a valuable business idea, companies can focus on developing products their customers are asking for. It can provide a way to bypass some (but not all) of the initial product development stages that require proof that a product will eventually have a valid place in a wider market.
Because HCD is centered around the needs of customers rather than the ideas of developers, companies using this design principle are likely to outperform companies still stuck on traditional POC processes. In fact, they may perform as much as 228% better on the S&P Index compared to companies using design principles other than HCD.
Implementing HCD Prioritizes User Feedback
Go to your customers and see how they are using your technology and compare it with how they use competing products.
- Which product is the most intuitive?
- Do customers keep using the product over the long term, or do they simply try it for a few months and give up?
- Do customers wish there were a product that had a feature that doesn’t exist yet?
Think of as many questions as you can that may be relevant to your field. Then ask your customers to answer those questions. Put together a comprehensive analysis of what your customers think about your current product and what they want from future products, to understand where there is a gap in the market that your business has an opportunity to fill.
Knowing exactly what your customers want and don’t want also serves another valuable purpose. In most IoT projects, different departments may have disparate priorities for the project.
When customer needs are the highest priority, it’s much easier to keep all of the separate teams on the same page. Rather than finance caring only about the budget, engineering caring only about the functionality, and executives caring only about the business ramifications of a successful product, the whole company stays aligned behind the concept of delighting customers with the best possible user experience.
To Establish Proof of Value, Aim for Minimum Viable Products Over Proofs of Concept
Ultimately, IoT product developers must prove to customers that their services will hold real value and evolve to meet changing customer needs. For enterprise customers, this means delivering results in terms of data usage, security, positive business outcomes, and other noticeable improvements to their business model. After all, if a product doesn’t solve an existing need, why would an enterprise spend thousands or potentially millions of dollars setting up an IoT solution that isn’t likely to result in noticeable improvements?
This Proof of Value stage is critical to the success of an IoT solution. For the businesses developing those solutions, there are a couple of ways to make this happen.
One way is to use the established proof-of-concept model. For all the reasons discussed above, this strategy may not be the best choice. If the company has invested the time to learn and implement a solid Human-Centered Design principle, however, they may be able to get a leg up on the competition by bringing a Minimum Viable Product (MVP) to market before competing businesses have even built their first POC.
While MVP and POC sound like the same thing, they have a few key differences.
A POC aims to answer the question of whether a market exists for a potential product. When developing a POC, a company wants to know if an idea will actually solve a given problem if a product were built for that purpose. Additionally, it helps a team understand whether they have the capabilities and resources necessary to develop the product.
An MVP, on the other hand, answers the question of whether people will be interested in buying a product and how that product should be built to provide the most benefit.
In the traditional product design process, a business leader may have an idea for a product, build a POC prototype, and conduct research to see whether enough customers have a certain problem that requires the proposed solution. With software and IoT projects, this process is not viable, because you must go through a years-long development process to see whether the product you’ve developed is actually useful.
If your company is using HCD principles, you already know what problems your customer base wants to solve by the time you’re ready to develop a product as the solution. You don’t need to build a full-fledged prototype for testing purposes if there is an existing market for the solution you’ve come up with.
Instead, you can build a barebones prototype—an MVP—and release it to a small segment of your target market. Then, you can move directly to establishing how customers react and interact with your solution. If your first segment of customers seems happy with your product and continues to use it beyond the demo phase, it’s probably safe to widen your test market and see how the product does in a slightly larger pool.
If, however, customers have unforeseen issues with your product, you’ll be immediately aware of them because HCD principles keep you plugged into the experiences and feedback your customers provide. You can use that customer feedback to iteratively improve your product’s features and establish product market fit before you release a complete version.
By following these customer-oriented design principles, you’ll know exactly which features need to be fine-tuned and redesigned in order to make the most impact for your customers. When your final product goes on sale, you can be confident that you have maximized its chances of success.
