Seven questions to answer before you begin development for your IoT product
Launching a connected product is both an exhilarating and a terrifying prospect. The benefits to your customers and users are clear, but the risks are also considerable.
Reviewing a core checklist of questions at the outset has helped our clients save on unnecessary expenses, keep development within their timeline, and ultimately like the products they come up with. Answer these seven questions before locking yourself into your process and your development, and you’re much more likely to experience the success you’re planning for.
1) Who do you need on board?
Even before you solidify your concept, it can be helpful to be absolutely confident about the skillsets you need at the table to make your idea a reality, because people with the right skillsets will help you make key decisions. What many teams don’t know is that you may need three distinct teams to deliver your product: hardware, cloud, and applications. And ideally, you’ll find one person who can speak the language of all three to oversee and manage the entire process.
An IoT solution is like an iceberg: only a small part of it is visible above water. Underneath the customer-facing mobile app or the device itself is a vast ecosystem of sensors, cloud systems, data, APIs and business algorithms. The prospect of managing every aspect of an IoT solution can be overwhelming.
That’s why we recommend enlisting an IoT visionary. This person will understand your business and assess your functionality needs. Their analysis can guide you towards finding the right team members or technology partners. They can also make suggestions around the feasibility of various solution concepts, and even suggest cost-saving opportunities or additional options aimed at delighting your customers. The role of visionary can be filled by a person from any number of backgrounds, from Technical Product Manager to System Architect. The traits that qualify this person are the following:
they understand your business and processes
they are problem solvers
they are educated on what is possible within the IoT industry
With your IoT visionary plotting the course for your IoT product, you can form teams to better accomplish your IoT goals. These are the four standard teams that are often required for IoT solutions:
Application Developers
Your software engineers will build mobile or web applications and help you deploy them to various user platforms, including iOS, Android, Amazon Alexa or Google Home. Depending on your customers’ needs, these are the team members that can create the experience that delights your customers and sets you apart from your competitors.
User Experience Designers
If you intend to have any type of interface for your IoT product, you should employ the expertise of User Experience (UX) designers. They will ensure that any type of mobile, web or touch screen interface will be easy to use, be pleasing to the eye, and follow your corporate brand standards.
Cloud Engineers
Most IoT products require a cloud back-end, which is the intermediary between your customer interface and your IoT device. Data and commands flow through the Cloud solution (typically constructed with Amazon Web Services [AWS] or Azure), and enable the data collection and device commands that power your connected product. Cloud engineers will ensure that these data and commands flow seamlessly.
Firmware Engineers
The firmware is the software that runs on your IoT product. It allows your device to connect to the Cloud via an access protocol like WiFi, or in many cases, it will allow your device to connect directly to a smartphone or tablet through Bluetooth. It enables your product to be truly connected. This team will also help you with any hardware components or sensors necessary to make your product operational.
2) What do you want to accomplish?
You can tell us what you want your app to do, but that’s not the same thing. What difference will it make in your customers’ life? And who is that customer, exactly? This will become especially relevant when you begin working with your app developer. A good developer will want to know who your target users are, how they’ll be interacting with your product, whether your product needs a web or mobile application, whether it can be a PWA (progressive web app), and more.
This stage should be nailed down early on because it will govern everything you do from here on out. At Outside Source, we tackle this question during an initial solution architecture process that will provide you a roadmap for the rest of your development journey.
Here’s what happens during that Solution Architecture process:
Step 1: Solution Workshop
This is a key step in the process of developing your IoT product. It allows you to define the solution goals, identify the customer pain points that need to be addressed, and provides valuable ideation on the solution. This may be an activity that you initiate within your organization with your product managers and customer experts. However, if your organization does not have much experience with software development, you may want to contract with an experienced IoT organization to facilitate.
A seasoned IoT product expert will ensure you make good use of your time in your workshop, and ensure that the information gathered is exactly what is needed for the later phases of Solution Architecture. This information could include:
High level requirements
Prioritized customer issues
Digital experience storyboards
Most importantly, a workshop should identify the opportunities for failure in your IoT product. This is critical in that it highlights the solution areas that should garner the most attention from product teams in order to minimize risk.
Step 2: Solution Definition
In the solution definition phase, we want to document the artifacts that are critical to system design and estimation, as well as get alignment that we understand expectations and customer needs. There are several deliverables in this phase:
User journey maps. These are the details of how your customers or users interact with the current solution, as well as the future connected device being build
User stories. This is a list of the specific features that is desired in the IoT solution. The user story is a requirement that is specific to agile development practices that facilitates project estimation and allows for scope flexibility in project planning
Competitive analysis. When thinking through the solution approach, it is important to take into account similar solutions in the marketplace. This will impact UX design and surface up opportunities for creating a competitive advantage.
Wireframe clickable prototype. Before we start estimating a solution, we will create a bare bones clickable prototype of any web or mobile application. This allows us to get alignment and approval on the IoT product vision before moving forward to the next step.
Step 3: Technical Assessment
Now that the requirements and the product vision is established, we move forward with a technical assessment. This is where we document systems requirements and solution architecture. Because there are potentially many subsystems in an IoT solution (cloud, firmware, mobile, web, sensors, etc.), it is important to document and confirm all technology assumptions and create a blueprint for the deliverable. This enables the project definition and estimation step.
Step 4: Project Definition
This is where all of the previous steps really pay off. Armed with a product vision, requirements and a technical blueprint, we can create a project schedule and estimation with confidence.
Too often, projects become at risk because project decisions are made prior to having all the information needed. This is where projects go wrong, as unknowns that could have been fleshed out earlier cause change and disruption to the overall project plan.
The ultimate deliverable in Solution Architecture will be a project proposal with a high probability for success. It would include:
Project schedule (“When will it get done?”)
Project costs (“How much will it cost?”)
Scope definition (“What will it do?”)
Resource needs (“What skillset do I need for my project team?”)
System architecture documentation (“How do I build it?”)
Successful IoT projects demand thorough up-front planning and analysis. We’ve seen it many times, and the process works. Companies that do not do their homework up front risk facing many project complications, leading to late delivery and dissatisfied customers.
If you’d like an idea of what this process looks like from the perspective of an Outside Source customer, check out this solution architecture article.
3) What’s the connection protocol?
Do you already know whether your app and product combo will be using wifi or bluetooth? How will you make that decision? If you’re not sure, this will be a key feature to discuss while you’re interviewing development partners for this project.
Here is a list of several popular options for wireless connection for IoT products to consider.
WI-FI
Wi-Fi is the most popular wireless protocol, and makes it easy to connect smart products in the home, with a typical range of 150 feet for a 2.4 GHz band indoors. The big drawback: wifi can have a high battery consumption, making it a poor fit for battery-powered devices.
Bluetooth Low Energy (BLE)
The early versions of the BLE protocol were largely used in cars and audio equipment, but it has now evolved into a protocol that can be used for a more diverse range of IoT devices. Newer versions of BLE now have faster speed and longer range (BLE 5.0 offers a range of up to 400 feet). BLE is ideal for a medium data rate, and therefore would not be recommended for applications that transmit a significant amount of data. It is a good option for battery-powered products that need to conserve energy.
Zigbee
This wireless protocol enables the use of mesh networking, meaning that it allows devices and sensors to connect to each other, allowing them to work together. A typical example may be a Zigbee light switch that controls a Zigbee light bulb. Because speed and range is low—and the devices are insulated within their own network—it is a great solution where long battery life and security are important, and transmission of data is not required.
Cellular
This protocol used by mobile phone networks can also be used by IoT devices. It is an essential solution for devices that exist beyond Wi-Fi range or travel long distances. The technology can transfer high amounts of data. Expense and power consumption can be high, as well.
4) Who will be designing?
Outside of a UX designer’s portfolio and talent, there are three characteristics that we recommend looking for in a great design partner: curiosity, toolset, and a collaborative mindset.
Here’s the breakdown of those three characteristics.
Curiosity: If a UX designer shows a high level of curiosity about your company and your customers, chances are they will not only create a design that delights your users, but they will likely help you identify edge cases in the experience that could prove frustrating if not properly considered.
Toolset: What type of tools does your UX designer use when working with clients? The best designers will use tools that not only create clickable prototypes, but allow them to do so rapidly. Some use InVision, Marvel or Principle. At Outside Source, we prefer Adobe XD because of its built-in UI kits and prototyping capabilities.
Collaborative Mindset: The best UX designers know how to work with product managers and engineers to build the best products. Through this partnership, they leverage the expertise of others to build designs that are both feasible and address specific customer needs. The result may not just be a great user experience, it could also translate to cost-savings and on-time project delivery.
You may find it helpful to have your designer be on your team. Outside Source houses UX/UI and development under the same roof, and both sides of our process inform, support, and guide each other.
5) Who will be writing embedded software?
IoT product development is inherently complex because creating a great product involves expertise in both hardware and software. Building the bridge between the two of them requires an experienced team.
When researching an embedded software development partner, look for experience in software architecture and prototype design as well as system integration. Because embedded software is just one part of the whole solution, the system design at the embedded software level is critical to the success of the cloud and mobile app solutions. We strongly recommend that all teams be brought together at the same time on system design. Collaboration is key.
As for requirements, one feature to value highly is Over-the-Air (OTA) firmware, which provides software updates over Bluetooth or Wi-Fi. It enables a great user experience, and critical firmware updates can be deployed frequently and reliably.
6) What will your ongoing monthly costs be?
In any development process, you’ll have considerable up front costs to get your app and connected product on the market. But many people neglect to plan for ongoing costs, including those expenses that will be required even after your product has launched. Are you prepared to handle those ongoing costs?
If you are using a cloud solution in your IoT product, there is an ongoing monthly cost that needs to live in your budget.
We recommend AWS IoT Core as the ideal managed cloud service for supporting connected products. It is full featured and highly scalable. Below is a summary of the AWS Pricing structure for AWS IoT Core (as of March 2020). Actual cost varies by region.
Connectivity
Connectivity for devices is metered in 1 minute increments and is based on the total time your devices are connected to AWS IoT Core. Pricing is measured by per million minutes of connection.
Messaging
Messages transmit device data to and from AWS IoT Core. Pricing is measured by the number of messages transmitted from the device. There are three pricing structures:
Up to one billion messages
One to four billion messages
Over five billion messages
Device Shadow & Registry
The Device Shadow stores the desired state or actual state of a device. The Registry used to name and manage devices. The pricing is metered by the number of operations that access or modify the Device Shadow or Registry data.
Rules Engine
The Rules Engine allows you to transform device data using algorithms or external functions, then route the data to another AWS Service. Cost is accrued each time a rule is triggered, and the number of actions executed within a rule, with a minimum of one action per rule.
To estimate your pricing by region for AWS IoT Core, visit this site.
7) How will the platform scale?
You know what you want it to look like once it’s complete. How do you plan to scale your connected device when you’re ready? You may find that you’ll need to involve some members of your development team when that time comes. Be prepared with ideas and questions for your expert partners to prevent misunderstandings and dead end, non-scalable products or solutions.
Scalability for an IoT platform is really about planning ahead for what you might need up to five years from initial launch. Many companies don’t think beyond their first proof of concept, and that can cause challenges as more devices are produced and data grows exponentially. Sometimes, these companies need to re-platform. This isn’t impossible, but it can be very difficult to make sure customers are not impacted.
That’s why you should think towards the future when investing in your IoT platform. Making sure that your platform supports the best case scenario for your product will lower risk as your business grows. Consider the following when thinking about scalability:
How will firmware updates be managed?
What is the required uptime for your solution?
Is the right data management plan in place?
How is access managed?
Once millions (or billions) of rows or data are collected, how do you make it actionable to enhance customer experience or drive process efficiencies?
The takeaway
You have every right to be excited about your IoT product idea. Approach your planning with answers to these questions, and you will be able to plan early on for a successful solution. If you’re ready to talk with an expert about moving ahead with this process, contact Outside Source.