What’s the target of any product? Create value for consumers. Seems obvious, isn’t it? And here comes the first challenge for most of the IoT projects we worked on: what is that value? This article dives into developing IoT products for different needs and different users and the pitfalls that we encountered in the process. Featuring experience from B2B & B2C projects and tips from our practice.
What’s a product?
Basically, anything we use (and what’s not a service). Yet, we don’t expect a musician to play gas chainsaw or an engineer to craft details using flute, do we? You may build super user-friendly UI, develop complex functionality behind it, but if your target audience doesn’t need your product, that’s a failure. Before we start...
Answer these three essential questions to bring the best of your idea:
- Who will use this product?
- What you want to achieve?
- How you can achieve that?
In that exact order. We’ll dive into each of them as we come across related challenges.
Why? That helps keep the product development vision clear. Which is crucial unless you want this to happen:
Always keep track of the changes you layer upon your idea including limitations and what you’re not doing. Document them, share and discuss with all stakeholders.
Check How to create a startup: IoT project from idea to production and find useful templates for your project documentation.
Specifying the buyer: B2B vs B2C
Remember the chainsaw and flute? Your product success depends on how well your product solves your customers’ problems and fits into their routine. And that is the most common challenge any product meets. With B2C audience, the end-user makes the decision, yet for B2B it’s more complicated. Business (i.e., owner, head of HR, CTO, COO, etc.) makes a decision for employees to follow.
Determining WHO will use the product. Developing with that perspective in mind.
Each step you take when developing your product is based on consumer needs. Know your audience. Walk in their shoes. Make user habits your stepping stone for creating the architecture of the software/hardware as well as their design.
Tailoring development to B2B environment
When talking about B2B and IoT, it takes ~50-60% of market structure according to Deloitte. The main challenge here lies in pinpointing the end-users and their needs and spiralling the development from that point. Also, since the primary customers are companies, each may have their own specific circumstances and requirements.
Well, each project has its own unique features. Yet, here’s an example of how studying your audience helps you to discover development priorities and vector early. The example is based on our own B2B product:
|Factors||B2B audience for iReDs||Influence on development|
|Customer business||Factories and plants that use rotary machinery, companies that maintain and repair such machinery||Have established processes, don’t embrace innovations easily, so both software and hardware have to be easily installed, configured, and operated|
Integration with other systems (if needed)
Not in the main product
Can be developed as add-on
|Clear protocols for connecting to client-specific systems|
|Network specifics||Cloud-based and/or local network compatible||Comprehensive built-in security, main emphasis on the most common network connection and tweaks for hybrid architectures|
|Area of application||
Elevators, escalators, engines, mills, generators, loaders, turbomachinery, and pipes
|Hardware must be easy to connect to different equipment types|
|Environment specifics||Areas that are subjected to high loads, indoors and outdoors||Hardware must be durable and working properly no matter the placing|
|UI attractiveness||Not really important||More attention to usability of both software and hardware, less to the UI design|
|Users (background and tech proficiency)||
Engineers, technical support, maintenance teams
|Tech slang and advanced non-UI options are appropriate|
B2C audience and development specifics
The distinguishing characteristic of any B2C product is its attractiveness. While B2B sector mostly makes decisions from sheer numbers (how it will reduce operational / maintenance / warehousing / any other costs, speed up the company processes, etc.), B2C places equal if not greater importance on emotions. Particularly, the sense of owning. And that also defines the development vector.
To illustrate the difference, we’ll study the factors that apply to B2C audience for our product UBreez:
|Factors||B2C audience for UBreez||Influence on development|
|Customers||IT specialists, young families, ecology enthusiasts, therapists||
Design of hardware must fit in to different interiors
Design of the apps has to appeal to these audiences
Integration with other systems (if needed)
|Not at the moment||Add to the “Not doing” list|
|Network specifics||Wi-Fi and Bluetooth connection||
Select hardware modules that support both communication protocols simultaneously
|Area of application||Home, office, public institutions such as schools, kindergartens, concert and conference halls, HoReCa||
Pay attention to the safety of used materials
Has to work properly with different electrical network setups
|Environment specifics||Indoors||Main charging via electrical sockets|
|UI attractiveness||Must-have. Simple, aesthetic, intuitive, not overloaded||Place great emphasis on UI design for both apps and hardware|
|Users (background and tech proficiency)||Varies from fully proficient to none tech proficiency||UI should be clear and include plain language only|
Common audience-related challenge
B2C & B2B challenge #2
It is always about simplicity. It is an obvious yet frequently neglected point.
Your product may be disrupting, important, and innovative, but if it is hard to use — you fail. If adopting new product is too hard, people tend to use simpler tools they’re used to.
Complex and non-intuitive products could have worked in the 80s and 90s, but now we simply do not have time and energy to spare for that.
Achieving the expected results
Studying your audience helps you create a roadmap and set priorities for development. Analyzing your audience helps you determine the value. Consider this inverted pyramid:
Balancing wants, needs, and costs
This is based on our own experience. When starting developing iReDs, which is solely B2B, we placed too much importance on design yet neglected the limitations that slowed and hindered the production. As a result, we spent 2 more time that was initially estimated.
B2C & B2B challenge #3
According to Cisco survey, 60% of companies underestimate the complexity of building an IoT product.
At the beginning, you establish overall IoT product development strategy, calculate risks, estimate complexity, etc. When implementing, you split the strategy into doable blocks of specific tasks. If your strategy is not on point, you have to constantly make adjustments, and the amount of blocks multiplies, and multiplies, and multiplies. As a result, you waste time, money, and resources.
Features ≠ value
Value is what using your product brings to your customers. What problem it solves. For example, consider these two requirement approaches for B2B:
A: We want to digitize mining industry by applying IoT to each part of the production line, namely <list of machinery>, using Blockchain to make it transparent for owners and investors, and also analyze and output the data on a dashboard and configure auto alerts.
B: We want to cut complexity and time our customers spend on connecting SCADA devices by half, see readings and receive alerts from everywhere.
At a glance, the approach A seems more informative whereas B seems more vague. Let’s compare them again after 3 months of development:
A: You know guys, actually, we don’t need most of the functionality for investors, but more settings for owners and managers.
Result: Change request and major changes to the overall project architecture.
B: We tested the suggested functionality with our core customers. It works well and we want to also develop mobile app for on-the-go configuration. What are your inputs on this?
Result: Web-portal for configuring and managing devices per company completed. Proceeding to mobile apps.
Why? The A approach is about HOWs of the product. B accents on WHAT the problem is, so that we figure out the HOWs (features, strategy, tools) fit best to solve it.
But most importantly, B has the customers in mind from the very start.
If you are working with development company, describe WHAT you want to achieve not HOW. Experienced team can suggest a lot of great and not time-consuming ways to deliver you what you want.
If you work in the development company, always pay attention to business context and users. Ask your customers about what and why they want to develop.
Compliance to privacy protecting laws and industry-specific regulations
Your product includes personal accounts? Then you’d better follow the regulations set in General Data Protection Regulation (GDPR). This includes storing, processing, transferring, accessing, etc. of any personal information as well as penalties if you’re not compliant. Fines up to €20 million sound terrifying, don’t they?
This impacts how you handle databases, encrypt data, set user permissions. And don’t forget to ask for permission to handle personal data and clearly inform users about your compliance!
P.S. For those who work with US market, pay attention to the California Shine the Light law.
Here’s the list of issues that slowed down the development process for B2B product:
- Buying high-precision accelerometer sensors at production scale.
Turned out that the model we chose is used for high-precision missiles and is hard to buy.
- Certifications for each country.
We didn’t predict (i.e., research) that each country has their own regulations and different certification procedures. This became an obstacle when reaching customers from foreign markets and installing the system on their equipment.
- Testing the performance.
To ascertain the quality and reliability of solution we had to imitate the working environment and extreme conditions.
At the start of the development, we were aware (and made preparations) only to the 3rd limitation. But resolving the former two took time and effort. That is why…
Forewarned is forearmed.
When you start R&D, add each limitation you come across (and can think of) to your project documentation and discuss them with stakeholders. You can’t predict everything, but the more you know of prior to implementation and production, the more you can work around or counter.
‘Not doing’ list
As the project shapes from idea to a real-life stuff, you will have tons of ideas. But implementing each of them is not made at a flick of the fingers. Review the Balancing wants, needs, and costs pyramid and critically review each idea using the following questions:
- Is it going to give product any strategic advantage?
- Is this the right approach to win my target audience?
- Does it match our other efforts/needs?
- Does the value exceed the implementation efforts?
- Is it applicable in the current hardware/software architecture?
These new features can be added later or not added at all (if they don’t fit into your general strategy). You don’t want to develop chainsaw with 48 setups for cutting trees that is automatic, self-adjusting, and plays a song while cutting, do you?
Defining SMART success criteria
Always remember that when developing a product you are juggling time, cost, and quality. And, while in a perfect world you have plenty of these, id doesn’t work in our plain reality.
That’s why prioritizing and defining success criteria is crucial. The specifications will change as the project evolves, but the end-goal, if stated clearly and communicated to all stakeholders, will be your guiding star.
From our experience, the SMART (specific, measurable, achievable, relevant, and time-bound) goals definition brings the best understanding of the success. Each SMART goal you define is, in fact, a large goal you focus on. Then, as the work starts, large goals are broken down into smaller, relatively small tasks.
How you will achieve results?
Gather insights from potential customers
It is never too early to get input from the actual users. You tailor the vector of the development to their actual needs and can establish potential customer base upfront.
Remember, the biggest challenge and the ultimate goal is translating user needs into your IoT product. Just kidding, the goal is success and prosperity, and the former is the only way to reach it.
To reach this ultimate goal, deliver the user needs to every team member. No ambiguousness, no ‘it’s obvious, everybody knows it’, because such an approach leads to misunderstanding.
B2C & B2B challenge #4
This is especially important when working with a remote team or software development company. Ensure everyone is on the same page. Remember this old but gold picture:
Discuss with stakeholders and agree on user interaction. Document it. What is not written, doesn’t exist.
Once we worked with a customer, who didn’t elaborate on the way he wanted to implement a certain feature. Developers made their judgement from best practices. And guess what? Customer wanted it to work differently. It was our mistake for not clarifying all details beforehand.
The bottom line is that no one is mentalist. And generally, the development team is your tool for achieving your IoT product goal. It is up to you, how you use it.
P.S. Beware of the teams that don’t ask questions. Unless you want to spend twice the time and costs and still get entirely not what you wanted.
Let’s talk about features
We all agree that successful features are simple, intuitive, not time-consuming, and useful. No matter the amount of logic behind them, user has to be at ease when using your product.
For example, with both our own products and numerous projects we worked on, one common challenge is security. Yet, no user will want to perform lots of actions for security’s sake.
So, here’s the challenge:
B2C & B2B challenge #5
No IoT project can function without well-thought system architecture. Here are the challenges we face with every project:
- Make registration and authorization processes centralized, controlled, multileveled yet easy to perform.
- Implement system configuration and debugging processes as simple as possible.
- Develop the most agile and functional algorithm of system configuration and maintenance.
The bottom line is that you architect the product so that the end-users don’t have to think when using it. It’s easy, it’s convenient, customers love it.
Even if your team blew their brains off to make all the fancy stuff seem like easy-breezy journey.
Focus your team’s efforts
Regardless of the methodology you’re following, prioritize the functionality that is absolutely necessary — your core solution. Any development company, which is proficient in what they do, knows that the techniques, tricks, and best practices are simply tools that allow to develop high-quality product faster and more efficiently.
We prefer agile, because it allows identifying what can be done simultaneously and core points of dependency.
For example, here’s a brief description of the approach we used when developing UBreez (B2C):
- Proof of concept
- Develop hardware electrical and mechanical design draft
- Test if it measures the readings and sends them to MQTT broker
- Test if the cross-platform app development communicates well with the broker
- Develop first working prototype for hardware and applications
- Make adjustments to app design based on the feedback
- Experiment with optimal hardware design
- Deploy cloud server and configure connectivity
- Implement core functionality
- Enhance 3D model of hardware
- Determine all the stuff needed for the product set
- Beta-test and improve based on user feedback
- Start presales
- Mass production
- Planning version 2.0
The bulleted list entries were done in parallel. Find more juicy content about MVP approach here.
Until the product goes into production, for each party involved into developing IoT project, it is a process of constant improvement. Debugging, finding more efficient ways, improving the design, testing, testing, testing…
There are always things you can’t predict from the beginning (the specifications are not set in stone, they should be updated with each however minor change).
That’s a working process and it’s fine. Just don’t forget to stick to your general concept, timeline, and budget.
Example #1 (B2B product)
When planning out the analytical dashboard for iReDs, we knew that it will comprise a whole lot of data. Three-vector analysis with chart-represented live data per machine, plant, or per region is all about that. Yet, when implemented and tested in the real-life environment, we realised that chart takes a really long time to load.
That is why we had to improve the response rate.
Example #2(B2C product)
Here comes the juggling between attractiveness and usability. After establishing initial hardware box concept, we improved it dozen or so times to:
- Make it appealing and stylish for the audience
- Ensure optimal arrangement of hardware components for precise measuring
- Design the most efficient layout of sensors inside the box and vents on the box
Though there was a lot of iteratives, thanks to 3D printing, all the interim adjustments were quite easy and not time-consuming.
3D is your new best friend
Prototyping and testing concepts for hardware design of your IoT product becomes easier is a lot more easier with 3D. The accuracy and control over 3D models is exceptional. The most awesome thing, you can use it for plastic, metal, ceramics, flexible filament, etc.
Check, check check the quality! (or how quality assurance saves you a lot of complaints from clients later)
When starting a new project, explore the competition. What your competitors excel at? What they lack? How can you distinguish your product from theirs?
In fact, if your product has a competition that confirms that the idea is needed and worthwhile. You don’t need to be cutting-edge and mind-blowing with every feature, just develop them better. Yet signature innovation is a great way to boost your sales from the start.
Back on track. When researching the competition, pay attention to the comments from their customers, especially the negative ones. That’s the effort they should have put into quality testing and assurance.
Make sure each step, each build, each change:
- Passed Quality Control.
- Approved by Quality Assurance.
Testing will spare you customer dissatisfaction and bad reputation.
When we were fired up with an idea of three-vectorial analysis of rotary machinery, we’ve heard a funny quote more than once: “That’s too daring”. Well, it might be.
But, from our experience, each project is challenging and you definitely will encounter unique obstacles and pitfalls. Facing challenges? Lots. Gaining experience? Even more!
Working with robotic arms, measuring air, controlling solar energy, fully operating mining machinery, and other exciting projects we work on and lots of those we completed, they all taught us 5 principles of success:
Start off from thorough understanding
Align scope with business goals set for timeline and budget
Think of value instead of features
Determine limitations and leverage them
Find a team that delivers results not excuses
And enjoy the process. It is amazing how IoT simplifies our everyday lives, our work, our progress of humanity as a whole. And that is just the beginning.
Thanks for reading and hope you’ve enjoyed this article.