If you’ve been following our blog posts, you’ll know that we recently partnered with RealWear to allow customers to build and run custom voice-controlled RealWear apps. These apps can allow RealWear users to:
- View reference material hands-free, including documentation, schematics, photos and 3D models.
- Capture structured data (text, photo’s, checklists etc.) using voice.
- Interact with machines and equipment with voice commands.
- Extend existing SAP, Oracle, IBM Maximo, or MS Dynamics functionality to RealWear devices.
We’ve hit the ground running since we announced our partnership, and are seeing new and existing customers approach us with innovative plans to implement apps for the RealWear HMT.
These plans often come from business or technology teams who intuitively understand the value that their RealWear initiative will unlock, but don’t have experience in designing or running pilot programs for RealWear that deliver the data needed to make a decision on a broader implementation.
This blog post lays out guiding principles that we share with customers looking to design and run RealWear pilot programs.
- Our five steps to running a successful pilot.
1. Select a use case that will move the needle
This might seem to compete with the idea that a pilot should focus on the proverbial lowest-hanging fruit but it doesn’t – it simply means you should skip the overripe apples within arm’s reach.
The reason it’s important to select a use case that, once rolled out at scale, will provide significant business impact, is because extended reality systems are at peak hype. If your use case doesn’t explicitly show how wearables and assisted reality will positively impact business objectives, your pilot program runs the risk of being dismissed as a gimmick.
To get an idea of the use cases that we see most often, see our post on workflow apps. Selecting a compelling use case is the first step to getting organizational buy-in for adopting this new technology.
2. Get buy-in for pilot success criteria early on
Once you’ve identified the use case that your pilot will revolve around, formulate the objective of the pilot in terms of a specific problem that it will solve. For example, for a hands-free equipment inspection use case this could be:
Problem: Data not entered into operations system at the point of data collection:
Inspections conducted on raised walkways are manual as technicians cannot carry tablets up stairs and do not have two hands available to safely operate tablets on raised walkways.
Then, build up your success criteria based on the problem statement. Using the same example of a hands-free inspection use case, the success criteria could be:
The pilot would be successful if it is shown that…
- Technicians can safely capture all inspection data at the point of data collection.
- Data from an app on a RealWear device can be integrated into the operations system.
Once you’ve formulated your success criteria, present it to others within your organization, including those that will eventually be end users, management who will be responsible for paying for the solution, and information technology teams.
Getting buy-in at this stage will smooth over a lot of potential wrinkles down the road, and boost the profile of the pilot within the organization.
3. Set your sights on a Minimum Viable Product
The next step is to define the minimum viable product (MVP) that will meet the pilot success criteria.
- Credit to Henrik Kniberg who created the original image used here, he discusses his thoughts on the principles behind the MVP approach and gives some great examples here.
The key with any minimum viable product is to define the most essential functionality that makes a product usable to solve the defined problem. The MVP’s purpose is to collect feedback from end users about whether a product can be used to solve a specific problem, so set your sights on the fastest way to do that.
A viable product is one that is usable to solve a problem on its own, without the need for additions. Minimum means including only functionality necessary to reach that point, nothing more.
Customers (the eventual users of the solution you’re spearheading) should be forgiven for pushing back against restricting scope in this way: their experience could be that the first version of a product is often the last version they get. Here you need to reassure them that this approach allows their feedback to be incorporated into the design and implementation process while adding increasing value with every step – the true agile approach.
Also remember that a key consideration with a pilot is speed — you’re trying to tie up as few resources as possible to validate whether an idea has merit.
Using the inspection use case example from earlier: it could be that the ideal version would have 3D models shown to users on the RealWear device, as a reference for what they need to inspect. Ask yourself:
- Does the MVP need 3D models to meet its success criteria?
- Would reference photos work just as well?
- Are technicians using any reference material today?
- What problem would this functionality solve?
Being critical of any requested functionality relative to success criteria will help save time, narrow focus, and provide a better foundation for moving forward post pilot success.
4. Design your pilot program around success criteria
At this point you would have defined a specific problem, set success criteria for a pilot aimed at solving that problem, and set requirements for an MVP that meets that success criteria. The next step is to decide on the who, how and when of your pilot program.
Who will the pilot users be?
The most important feedback will come from the eventual end users of the solution. Others may help analyze data from users, brainstorm implementation ideas, or solve logistical issues — but only end users will be able to tell you whether the product is usable.
You may decide to run the pilot with all users at a specific location or have a few pilot users from each location. There is no rule of thumb that is applicable to everyone here — as long as logistic decisions don’t override the involvement of eventual end users.
How will they conduct the pilot?
The ideal would always be to use the MVP in as near as real-world conditions as possible. Often we see customers request pilot users to conduct a process through an MVP in addition to the current way of doing things; this works well.
When and for how long will the pilot program run?
When: In general, try to avoid scheduling pilot programs during seasonally busy periods where users may deprioritize using pilot software as they deal with a glut of work.
For how long: Consider the duration of a pilot in light of your use case: would a short, high-impact pilot period work or does the process being addressed by the pilot occur too infrequently for that. In general, it helps to think in minimum viable terms: what is the shortest duration that would give you enough data to conclude that success criteria have been met or not.
5. Get your hands dirty
- Piloting emerging technology like RealWear can be a fun and exciting experience! Image © 2021 RealWear, Inc.
If only you could launch a pilot and comfortably sit back while watching data flow in from end users… Unfortunately, as the person spearheading the pilot, you should be prepared to fulfill the roles of configuration expert, trainer, tech support, drumbeater, and more. These compounding responsibilities are another reason to keep the pilot as limited as possible to achieve the success criteria.
For pilot programs that specifically involve RealWear, think about the physical distribution of RealWear HMTs, being available for any initial configuration support, and plan to use RealWear’s free Foresight MDM service to deploy the solution to pilot user devices.
At JourneyApps we have a customer success team experienced in running pilots who help with this process but many other products will leave you to your own devices through the pilot phase.
Spearheading a pilot might seem like a lot of responsibility but, fortunately, if you’ve followed the steps above, your pilot program should be lean, have organizational support, stand to make a real impact and be easy to manage.
Good luck with designing and running your pilot program, we wish you all the best!
JourneyApps provides a rapid way to build custom apps for RealWear® HMT, mobile and desktop. Auto voice commands are simple to set up and manage, we provide offline support out of the box, and deploying apps happens with a single click. Comes with prebuilt ERP integrations. If you are interested, please contact us to schedule a demo. You can also visit our RealWear page to learn more and subscribe for notifications about new blog posts.
