Field Workers Don't Care about your Stupid App
"Field workers don't care about your stupid app...but if they are remotely interested, everything about it better be as reliable as a hammer."
If you spend enough time around field and mobile workers, there are many pain points related to time, waste, and things that are a massive hassles. When Shapetrace was in the construction and facilities management sector, we tried pretty hard to optimize field operations for workers. We ultimately failed, and we've spent a lot of time thinking about why. We feel it came down to the state of augmented reality not being good enough for such an environment and as a result, getting users to commit long-term was hard. We were too early.
But what does this really mean?
In between closing Shapetrace in May 2017, then opening it up again in January 2018, I spent the summer and fall as an field team leader at Dropbike, a bike share startup. I could see similarities to the construction industry and any job that is in the field. I used this as a time to reflect, and here are some of the insights.
Your Job is to Operate
Our team was responsible for verifying the locations and the condition of the rental bicycles, doing minor repairs, and for rebalancing the fleet, which means to move bikes back to the popular start points. Rebalancing is the biggest challenge because in a common scenario, people pick up bikes to ride down a hill to a subway station and drop it off, but they won't ride bikes back up a hill. Since you end up with crowded sidewalks and the bottom of the hill and unhappy customers at the top of the hill, you have to move bikes back up. You either rode in a truck or you did this on foot. And this cycle repeats over and over again, all over the city, every day.
"Your primary job function is to operate and to stay safe, not design."
As a field worker, you take pride when you finish your shift because you feel like you accomplished something tangible by using your body, and then you go home to rest and get ready for the next day. But field operations is a thankless job: you don't really get praise when the operation is smooth or ahead of schedule (which is 99% of the time), and there's limited upside because your shift is time-boxed, and your body needs rest. Then, if you really reflect on this, your primary job function is to operate and to stay safe, not design. But everyone is on your neck when shit hits the fan. Then in the nature of many field jobs, there's a never ending list of things to do: there's always a bike to be moved, there's always an elevator to be fixed, and there's always a pothole to be filled.
As Reliable as a Hammer
"... for a field worker, the tolerance for bullshit is next to nothing."
In the "startup gospels", you get preached that users are willing to deal with bugs because the benefit would override the nuisance. While this is true to an extent; however, for a field worker, the tolerance for bullshit is next to nothing. When our bike rebalancing team was updating bike locations, we depended on mobile connectivity and server uptime from our mobile app. Since the bike locks were unlocked by Bluetooth, we needed the digital key from the server to unlock. If we couldn't unlock, we'd be cursing and twiddling our thumbs until it did. If it wasted one min of time per bike, 20 bikes adds up to 20 minutes, and my to-do list for the next day just got longer (and remember that the list never ends). 99.9% of the time, the app was just fine, but I used a mobile network that had sparse towers in the area. Guess what? I blamed the app for wasting my time, but it was hardly its fault. So, the whole field solution you offer has to be reliable, not just your piece of it or you'll get unfairly blamed for hiccups.
For construction AR, we expected superintendents and workers to hold up their mobile phones in a pre-constructed space such that they could see the 3D designs overlaid the real world. "See before you build", we'd say. But here was the biggest problem: you could pick up the phone and it would automatically align the real and virtual worlds together to less than 5 cm precision; however, it would misalign 10-20% of the time, and you'd have to spend a minute re-aligning it. Well, if you were using your hammer and 10% of the time, the hammerhead would fall off, you'd be pretty frustrated too. This is why on our current projects, we now assign high reliability metrics to our specifications in addition to spatial accuracy.
Tool has to be Central to the Job
In order for any field tool to sell, the tool needs to address the central part of my job function. it has to be so important that without it, there is no job. In the case of Dropbike, their internal app was all the mattered to me: I needed the app to tell me bike locations, to unlock them, and to tell me where I needed to move them to. Unfortunately, this is pretty difficult for an enterprise customer to adopt, and it will require buy in from the field team and its managers to change their existing processes. The app needs to demonstrate that it directly manages operations, has the most value as a team process, and work extremely reliably as a complete solution. You can understand why early adopters often want long field trials with a small team to test and measure any return on investment. Then, the rollout is generally in multiple phases before the entire company adopts your process (which is your goal).
Our recommendation is that if you're building digital tools for any field workers, spend a lot of time in their spaces, and remember that they expect reliability or nothing. Their job is tough and often dangerous enough, so they don't expect anything less than the reliability of a hammer.
Note: I'd like to spend another article talking about safety for field workers, which is a massive concern.