A prototype is a working demonstration of an idea. It may show that it will work, but it will not guarantee that customers require it, that it will work in the real world or that a business can support it.
That's true for the tech teams too. When technology teams build products, prototyping is not enough. To take a proof of concept and turn it into something useful, it takes more than just writing code. It takes testing assumptions, designing for actual working conditions, testing outputs, and knowing who you are designing for.
Let's say you're developing an industrial IoT application to monitor equipment throughout a manufacturing plant. You may have built a prototype that captures sensor data and displays it on a dashboard. A production-grade system must also contend with unstable connectivity, repeated events, broken devices, data integrity problems, security and access management, and legacy integration.
This idea holds true to a large degree in many technology startups as well: build to verify an assumption, measure the results, and grow only if the data warrants it.
- Define the Problem Before Choosing the Technology
It's easy to start with a cool technology and find the use case later. A more safe approach to innovation is to find the pain that you know your customers are already feeling.
For instance, it might take a team several hours to find tools or verify whether equipment is available. Ask yourself how the process is currently handled before you implement RFID, GPS, computer vision, or IoT sensors.
Ask questions such as:
- How frequently does the problem occur?
- Who is involved, and how does this impact their work?
- What systems or manual processes are already in place?
- What would a meaningful improvement look like?
- Who would decide whether to adopt a new solution?
These questions set a standard for the team and ensure they aren't wasting time solving a cool technical problem that may not have any operational value.
If you do a quick discovery phase, you will quickly learn if the entire system can be handled by just the software. Or, it may be that you need to implement hardware, process changes or integrate with something else.
- Build the Smallest Useful Experiment
For an MVP to be worthwhile, it should test an assumption, not just a small version of the final product.
Let's say the premise is that if tools are easier to see, that should speed up the search for them. The first experiment might not require a more comprehensive analytics platform.
A small pilot might include:
- A limited set of tagged assets.
- An asset location or status change recording system.
- A simple interface for authorized users.
- A timestamped event log.
- A means of benchmarking the results against the process which is currently employed.
The team will then see if the users do indeed go to the information and if the pilot enhances the workflow they are aiming to address.
Limit the scope of the experiment for easy evaluation. The first iteration, for example, may be asset tracking, predictive maintenance, and automated scheduling, as well as a few dashboards. If you have all of these things in the first iteration, it's hard to pinpoint what part made the difference.
- Design the Data Flow Before Scaling
A prototype operates in a controlled environment. A production system must manage missing, late, duplicated, and inconsistent data.
Example of a simple architecture for an IoT asset-tracking app:
``text
Sensors or Tags
v
Device Gateway
v
Event Ingestion
v
Validation and Processing
v
Database or Event Store
v
API and User Interface
``
Each stage introduces design questions.
Device gateway: What does a device do if it goes offline? Will it save events that occur while offline and play them back when it reconnects?
Event ingestion: How does the system handle duplication of retries? Does the event come with a unique ID?
Data handling:Are the timestamp, device identifier and asset identifier checked on an event that updates the record?
Storage: Is the Data model the one that records event history or just it reflects the most recent 'known state?
API and Interface: Can you tell if a user is taking a new reading or an old reading? What should the system do if it does not have a location?
This information matters to the readers. If a dashboard shows a location but doesn't say when it was last updated, it may give readers the illusion of certainty.
Use case, scale and availability requirements determine the best architecture. The key is to understand failure conditions at design time, not as an afterthought that we need to address post deployment.
- Measure the Outcome, Not Just System Activity
While these technical metrics may help describe the system's behavior, they don't necessarily prove business value.
A team might measure API latency, the percentage of events lost, how long devices stay online, or how many events can be ingested. Reliability metrics are important. But an industrial product should also measure the improvement it provides to whatever workflow it's meant to streamline.
For an asset-tracking pilot, useful measures might include:
- Average time to find an asset.
- Proportion of assets having adequatetimely status information.
- Frequency of missing or duplicate events.
- Number of manual checks required.
- User adoption during the pilot.
- Cost of maintaining the system.
Determine the baseline before you introduce the new system. Then compare results under reasonably similar operating conditions.
For example, if the team would like to decrease the amount of time searching for an asset, they need to document the current process and determine how search time will be calculated. A small pilot that completes searches faster might be promising, but it shouldn't be viewed as successful for every facility.
Making decisions based on what is seen instead of a good show is the goal.
- Treat Reliability and Security as Product Requirements
Software is part of the product experience, including when it is a part of the physical operations.
A venture must determine its critical failure modes before deploying more broadly. This could be door unlocked when it should be closed, service not available, wrong data gathered from a sensor, notification not received, or compromised access.
A practical review can cover:
- Input validation and data-quality checks.
- Authentication and role-based access control.
- Encryption where appropriate.
- Monitoring, logs, and actionable alerts.
- Backup, recovery, and data-retention requirements.
- Safe behavior when the data is absent or outdated.
- Testing under expected failure conditions.
Additional protections and validation within the domain of the application should be considered for systems that perform physical actions on equipment or safety critical decisions. Do not assume an automated output is safe because the model/software in the showcase performs well in a demonstration.
"Design for failure" need not mean trying to fix all the possible problems before your first pilot. It simply requires knowing which failures are important, making them visible, and designing a system that responds to them.
- Decide When to Expand
A pilot is data to be proven, not a go signal to grow.
Before expanding, review three areas.
Technical state of readiness: Does the system function reliably in a scenario closer to what will be used, can failures be recognised and will the team be able to support its deployment?
User value: Do users find it useful? Is the solution that they get, better than the way they previously did what the product is meant to do?
Business viability: Can the solution be implemented, maintained, and supported at a cost that makes sense for the customer and the business?
Scaling can reveal hidden issues beyond those you saw in a pilot. Larger numbers of devices: more volume of events. More customers: more integrations. More deployments: more support and maintenance costs.
https://apertureventurestudio .com/
Where possible, expand in stages.
Top comments (0)