What are the key steps to a successful Proof of Concept in a serious IoT project?
In my first article, we addressed the four pillars for a successful serious IoT project and the first steps to implement. Let’s dig now into the Proof of Concept phase adapted to IoT/embedded projects.
Write the first line of code as late as possible. Build the first PCB (Printed Circuit Board) even later.
While Proof of Concept method for pure web product can be easily applied, the question is how to make that real when a Proof of Concept involves embedded software and hardware parts?
Proof of concept method hides a huge gradient from a small « slide deck » to a realistic mock-up. Beware that a proof of concept is not a viable product since it is not a product! It is meant to validate some assumptions you made while designing your project.
Let’s take an example: a fleet management solution for purchase managers. This fleet management solution is based on an IoT device within the car, a gateway, cloud analytics + BI web interface and an app for the driver.
Here are the few steps you will need to follow to successfully design your Proof of Concept.
Design scenario, make mock-ups
Nobody can guess what is in your mind, neither can you guess what is in other people’s minds. Plus, what looks great in your mind can be impossible or just useless when exposed to a real scenario. How to transform a vision into something tangible? Just draw.
Illustrate, make ugly sketches with your pen, share that, challenge, iterate. I often see people who claim they cannot do this since they need the product brief, a designer to work on the graphical identity, skills to draw etc. That is just lying to yourself and trying to delay the crucial moment: have the first test of your idea by facing another people’s feedback, and maybe discover that it is just a dead-end.
In our fleet management system, we will draw a journey with a driver getting into his car and interacting with the solution:
- We will draw the purchasing manager looking every month into analytics when making his reports
- Some dashboard example
- How do we plug the device into the car
- etc
All that needs to be shared internally to align visions, and you can even present that to some of your trusted prospects who that can give you kind feedback.
Define what is to be tested
While designing your innovation, you intuitively make assumptions that can be wrong. The obvious needs to be stated because something obvious to you cannot be obvious to your team. You won’t convince anyone by saying « it’s obvious » / you need to doubt as much as possible to strengthen your intuition with facts.
To do so, you need to clearly state the assumptions you take, rank them with criticality, and then to set an action plan to test each one.
In our connected fleet management system example, we could say that the main assumptions to validate are:
- The answer to a painful problem faced by the purchase manager: waste of time, lack of insight to optimize, cost control, etc.
- The purchase manager is the one who is most concerned by these problems
- The purchase manager is aware of the problem and his willingness to solve it
- The analytics I propose give insight that is considered meaningful by the purchase manager
- Someone is happy to pay for it as it brings tangible ROI (time-saving, fuel consumption saving, car wear limitation, etc.)
- Drivers will be open/happy to have a tracking system while we drive
Fake it as much as possible
Write the first line of code as late as possible. Build the first PCB even later. You need to find any possible solution to make your test fast and cheap:
static screen, website faked with PowerPoint animation, 3d printing, fake packaging, videos presenting the use case, photoshop into real situations, using existing app to simulate part of the behavior, etc. the idea is not to trick anyone, but to be able to present to your potential customer something he can grasp and imagine his real life.
Back to the fleet management tool example, we can :
- Design a fake WebApp thanks to Balsamiq
- Make fake a dashboard thanks to Excel or Turbo
- Buy an existing OBD (On-Board Diagnostics) device for the customer to see how it looks like
- Make a quick & dirty web app for the driver (with WIX, iPhone mockup or one of the many existing tools online)
Usage testing with customers is mandatory
You have everything you need to get back to your potential customer and make him interact with what you have. Don’t explain him, let him try it without influencing him. Make sure he discovers the solution by himself.
Collect feedback, don’t try to convince, it’s time to listen and be humble:
You will be able to iterate this process as many times as needed based on the feedback you have until you get the final « Yes I buy it » from the customer. That way you will progress step by step from that fake solution to your functional specifications.
Think about it, what is a change on a fake solution compared to a beta product where you have already invested in dev, material, platform?
Your technical Proof of Concept
Here comes the cool part (from my perspective). The idea here is to validate technical assumptions:
Is my technical solution viable? What are the devices interoperability issues I might face? What is the related cost? What are the roadblocks I need to remove?
Back to the fleet management solution, software + embedded software developers will work on:
- A simple from HMI to have few data displayed
- A basic web app to avoid any commit on App Store
- The right embedded software into an evaluation board that has similar capabilities to your targeted HW for the device
- An existing ODB device that will send info over any radio protocol
- Integrate all that into an end-to-end solution, using a public Cloud solution
If all that works for a simple scenario, it means that 90% of the technical uncertainty has just disappeared. Now next challenges will be UX, scalability, stability, reliability, security, but that is for industrialization phase!
Time for specs
Good news for you: the functional Proof of Concept + technical Proof of Concept = functional specifications + technical specifications! No need for endless documentation, you just have a real spec! You can give that to Software experts and Hardware experts to have budget estimations and feasibility for the real one.
So you ‘re done for the next phase: industrialization! But this is for next chapter…