How Internal Tools Can Make or Break Your IoT Solution

Internal tools are one of the most overlooked parts of any robust IoT solution. Product Managers usually focus on the customer-facing parts of the solution and leave internal tools as an afterthought. However, IoT solutions typically require a significant amount of monitoring, controlling, and behind-the-scenes operation.

Related article: Internet of Things: A Primer for Product Managers

If you don’t plan ahead and build these tools, your Development and Analytics teams can get bogged down by requests from other departments, such as:

• Can you help me with a demo for a big sales opportunity?
• Can you verify Customer X’s system was installed properly?
• Is the performance of the solution meeting the commitments we made to our customers?
• Can we get a report of all the devices that have failed year-to-date?
• Customer X called and said they can’t see any data. Is their site down?

Your team may be able to handle these one-off questions in the early days of your company or product, but once you reach a certain scale, these requests will become overwhelming, creating a bottleneck for the company as a whole.

Building (or buying and integrating) internal tools empowers other departments to answer their own questions and do their job more autonomously, without needing to ask the Development and Analytics teams for help as frequently. That leaves more time for everyone to focus on their core work, and get more done. And that means your company or product can scale more quickly.

6 Internal Tools Your IoT Product Needs

Below are six of the most common internal tools your product may need. These tools are organized in order of the customer lifecycle stages for an Industrial Internet of Things (IIoT) product, from pre-sales to installation to live operation and reporting. (Consumer IoT products will require a different but related set of tools.)

1. Demos and Sales support tools

The most common Sales tool is a demo of your application(s). By empowering Sales with their own tools, you are not only supporting the main engine of the company, but you are also protecting your PM team from being the “demo guys”.

Although it sounds simple, creating a robust IoT demo requires a lot planning, configuration, and sometimes even development. Before you define the demo features, make sure you understand the needs of the Sales persona.

The demo needs to use data that shows a compelling story for your prospective customer. And that sample data can be hard to find or generate. If your IoT system streams and surfaces real-time data, you will likely need to simulate a real-time data stream in your demo, or use a historical real-time stream from real customers.

If you decide to use real customer data, make sure you get their permission in writing or scrub the data of any customer identifier to make it anonymous. Showing identifiable data from customers is usually a violation of their privacy, and it can get your company in trouble. Be very careful.

2. Installation & commissioning tools

Once a deal is closed, then you move into the deployment stage. The complexity of the installation process is typically much higher for enterprise IoT products than for consumer IoT products. For example, some home automation solutions require no installation other than providing power and network access. Others require a simple installation that can be done by the end user or by a technician (think Nest thermostat).

On the other hand, applications in the industrial space usually require skilled professionals to perform the installation. Think of a machine monitoring solution or a big MRI machine at a hospital.

It is very important to understand the installer persona and the installation process and consider the tools they will need to install your product and to connect it to your Cloud. The polish and granularity of your tools will depend on whether the installer is part of your company or is a 3rd party contractor. The form factor also plays a big role here since these installations are done in the field, so you’ll probably need to focus on a mobile use case.

Installation tools often include things like:

• Workflows to walk the installer through the process
• Checklists to ensure all steps are completed and can be audited if needed
• Local (as opposed to Cloud-based) diagnostic tools to ensure the system is properly installed

Once your solution is installed, then it can be commissioned. The first part of commissioning is adding it to your IoT network, and ensuring it authenticates and can properly communicate. You might want a tool that allows your system to perform auto-discovery and be added to the IoT network automatically. Or you may want a tool that allows an installer to do this manually, depending on your industry and application. Commissioning also includes creating the customer account and registering users in your system.

The last part of commissioning is usually to perform an acceptance test to demonstrate that the system is fully functional. You’ll also need to provide the necessary tools for the operations team to perform these tests.

3. Asset tracking tools

If you provide an IoT solution-as-a-service, chances are you’ll need to track your assets so you can perform maintenance, service guarantees, etc. At the highest level, you might only need to track the physical location and the serial number of your device. But in some cases, you’ll want more detailed tracking, such as parts installed, delivery dates, installment dates, etc.

For example, if you have an IoT alarm system, then you might want to track the serial numbers of all installed sensors as well as the serial number of the gateway.

Keep in mind that there are many commercial systems for asset tracking and management. Unless your needs are unique, I don’t advise you build this system yourself. Focus on providing APIs so that your IoT solution can automatically feed the necessary data into an asset management system.

Related article: The Business of APIs: What Product Managers Need to Plan For

4. Health monitoring and performance tools

Once your IoT solution goes live, day-to-day operations are usually transferred to an Operations team. It is very important to understand the needs of this persona and make sure they have the right tools to perform their job.

Product Managers can begin understanding their environment with questions like:

• Do they operate a NOC (Network Operations Center)?
• Do they provide 24/7 service?
• What other responsibilities do they have?
• Etc.

Health and performance monitoring ensures that each individual device, and the overall IoT network, are available and performing according to specifications. The Operations team is usually responsible for questions like:

• Is the overall solution responding?
• Are the individual devices responding?
• Is a particular site down?
• Is data missing or corrupt?
• Are there any emergency conditions?
• Are there any devices that need maintenance?
• Do all devices have the latest versions of software/firmware?
• Is the performance of the solution meeting the commitments we made to our customers?
• Is there any degradation in the devices that are affecting the performance of the solution?
• What reports do I need to provide to the rest of the organization?

What do all of these questions have in common? They rely on getting accurate data from the remote devices and require the ability to communicate with and update devices in the field.

All these data and control capabilities are already available in the Cloud Platform, so the task here is to make this information available to the Operation team in a way that is useful to them. Most likely you’ll need to develop a custom application that provides them with the functionality they need, and that may require opening a new set of APIs. You can use the IoT Decision Framework to help define the features and needs of this application.

The operation of your fleet of IoT devices can be a complex endeavor. This area will require a significant amount of attention and development resources to ensure success. If you don’t create the tools needed ahead of time, requests from the Operations team could fill up your backlog, and they will use up a lot of the capacity you need to build customer-facing functionality. Plan accordingly.

5. Enterprise systems integration tools

As your company grows, it’s very likely you’ll need to integrate your IoT solution with other third-party systems. For example, you might need to integrate with your CRM for commissioning, or with an ERP for asset tracking or billing.

These integrations are usually handled by IT, but your product needs to provide the right APIs, security, and data caching to make sure these integrations are possible.

6. Business intelligence tools

In addition to the tools above, many other departments will want their own custom analytics and reporting. This is another opportunity for you to do a build vs. buy analysis. Unless your core competency is building Business Intelligence tools, you might be better off integrating your Cloud platform with a top-notch BI provider like Tableau or Birst.

Related article: Big Data: 6 Key Areas Every Product Manager Should Address

Other Considerations

Build vs. buy analysis

Depending on your industry and company size, you need to decide whether you’re going to build your own internal tools or integrate with third-party monitoring tools and services. I strongly recommend performing a deep build vs. buy analysis on each of the areas in this post. For a structured way on how to weigh the trade-offs, check out my IoT Decision Framework article.

Some companies decide to build internal tools in-house because it provides a strategic advantage, or because there’s nothing in the market they can leverage. Other companies recognize it would tie up too many resources to build such tools in-house, and they find a third party solution good enough to fit their needs. Most companies end up doing a little bit of both: buying tools for some needs and creating custom applications for others.

The build vs. buy decision will have a big impact on who is responsible for what. If you build in-house, Product Management will drive the process, researching the internal users and their needs, defining the roadmap and features, etc. However, if you buy and integrate a third-party solution, much of the responsibility will likely shift to your IT department and the department that needs the tool. In this case, the Product Manager’s role will just be to provide the necessary integration interfaces (APIs).

Many companies that build a lot of internal tools in-house have a dedicated Product Manager and Development team exclusively focused on this area. This is hugely beneficial since building and managing your internal tools will be a big endeavor. Asking your core Development/PM team to take on this job will result in a lack of focus and reduced velocity of producing the “revenue generating” parts of your offering.

Define your internal users

It is important to understand that the user of internal tools is completely different from your external user. And they are also different from your developers who might build one-off tools for their own troubleshooting purposes.

Just like with any other user, you’ll need to research their pains and create personas and jobs-to-be-done. It is also important to work closely with them as your internal customer to understand their process and decide which parts of their workflow need to be automated vs. which parts are better done manually (at least for now).

Development teams might be inclined to automate and build amazing tools for anything and everything. That’s where you, the business-savvy Product Manager, need to jump in and understand the ROI of building such tools. Maybe that need could be solved not with tools but with better processes or more support staff (i.e. technicians and operators).

The Bottom Line

Internal tools are an important but often overlooked requirement of a successful IoT solution. If ignored, your Development team could be overwhelmed as other departments fill your backlog with requirements, severely slowing down product development. Building (or buying) the six internal tools outlined above can empower other departments to get the information they need and work more efficiently, allowing your company to scale more quickly.

I recommend thinking of internal tools as another product line your company needs to support. With this mindset, internal tools are more likely to get the resources, budget, and attention they need. Remember to conduct a serious build vs. buy analysis before making any decisions. Development teams might jump at the opportunity to build all these tools because it’s fun and because they can. From a business perspective, that might not be the best use of your resources.

By planning ahead and creating a roadmap for internal tools, you’ll be on your way to creating a successful end-to-end IoT solution.