A critical aspect of industrial connected product commercialization that is often overlooked by product teams is how the system will be customized once released to the market – including how often and how long each customization will take. At Bright Wolf we’ve created a tool called the pyramid of configurability to assist product management when designing the initial IoT product offering.
The purpose of bringing connected equipment to market is to embed your products and services inside the customer value chain and break the spiral toward hardware commoditization. To accomplish this goal, you must first understand each link of the chain, mapping the requirements, skills, and constraints of each actor from development and delivery through to sales and consumption.
In many cases, this mapping activity will touch actors in the value delivery chain with which your company has not previously had a direct relationship. The pyramid of configurability serves to guide the levels of investment and capabilities required at each layer of to ensure your system architecture accommodates the needs of each actor from the beginning, avoiding costly rework and market failures after your production release.
Let’s walk through a few examples. In the case of heavy machinery HMI production, there are likely to be the following roles:
- Software developer
- Internal engineer
- Machine system integrator
- Service technician and Dealer
- Owner and Operator
At each level there are more individuals, starting with the core development team and ending with the individual consumers of the products produced.
The activities performed, and more importantly the expected frequency at which they will be performed should be mapped as well.
When you combine the roles by size and activities by frequency into a single chart, you will see clear patterns emerge for guiding your product strategy.
What this tells you, at the extreme, is that there are going to be a lot of users wanting specific layouts and display widgets on their HMI dashboards. If you don’t build in the ability for individual owners to easily configure their own screens then either your small team of software developers are going to be incredibly busy following up on support tickets to make necessary code changes for each HMI operator – or your product is going to fail in the market due to a fixed one-size-fits-all user interface that nobody wants to buy.
On a similar track, there are certain configuration changes that your service techs and dealers are going to need to be able to make that end users should not be allowed to access. How are you going to restrict different levels of configurability for your equipment in the field? This ability to enable or disable functionality based on user role (and the methods for properly authenticating each user) are either part of your overall system architecture or not. IoT Product managers must plan accordingly and include this as part of the initial specification and requirement documentation, and budget for sufficient development resources to accomplish these tasks.
Another example we’ve seen in connected product systems involves how the system will enable customers to configure I/O during installation. In these situations, manufacturers typically include a set of open I/O ports in addition to an initial set of supported sensors, such as temperature and pressure. When new data types are desired in the future (ex: acceleration, vibration), operators are able to plug the appropriate sensors into these channels and begin immediate collection – at least at the physical level. This is another key area where configurability must be considered ahead of time. Critical information will be lost unless the digital system has been architected to accept, pass along, and process this new data and its associated configuration.
Even if the data is anticipated and stored correctly for future analysis, the architecture will also need to enable proper display in mobile apps and web applications. While new data types as a concept may be anticipated, the specific types of data are unknown until the customer identifies a new requirement or opportunity. Therefore, the architecture must allow for system operators to configure the application user interface and data reporting after deployment. Otherwise, the new sensor values will begin appearing as desired in the list of metrics for each asset in the field, but with fixed, unhelpful names like “Data5” and “Data6” and displayed in generic number formats that must be deciphered manually.
Another related area of configurability is human readable translations. Many products get sold into markets where the operators cannot read one of the initial set of supported languages. Allowing owners and operators to add translations for local languages can also be a valuable configuration capability.
The specifics around how much configuration to make possible for actors at each point in the value chain will vary across industry verticals and the products themselves. IoT Product Managers must consider all of the actors who will participate in the solution from end to end in so they can provide sufficient specifications for the IoT development teams designing the system architecture. Each actor must be well understood upfront – their requirements, goals, and the tools they’ll need based on their likely skill sets – in order to deliver a commercially successful connected product system.
Bright Wolf has helped some of the largest companies in the world to understand and solve these and other challenges of industrial IoT and connected product systems. Contact us to learn how our decade of experience can accelerate your digital transformation journey.