An alternative headline to this blog: Automating a shitty process only creates shitty results faster.
Most of my clients make software. Sometimes hardware, sometimes they’re a services business, but mostly my clients make software. And the purpose of software is to create efficiencies, so it makes sense that my software clients spend a lot of their time trying to figure out how to automate manual processes that, with technology, can be done a lot faster.
But just because you think a process could be automated doesn’t mean you know how to automate it, or that it should even be automated at all. When you don’t have much experience in a vertical or market, having an idea to completely redefine how people do a thing doesn’t necessarily mean you should spend the next six months of your life working on it. Without knowing how that process currently works, chances are high that whatever you build will suck. Not because it’s a process that doesn’t need some updating, but because you have idea of how it works or what success looks like.
Have you ever heard the story about the three blind men and the elephant? One feels the trunk and thinks it’s a snake, one feels the leg and thinks it’s a tree, and one feels the tusk and thinks “holy shit we need to get out of here.” (Ok, that’s not exactly it, but you get the point.) That is you trying to automate something you don’t know — blind guessing on what it is you’re working with, and the vast majority of the time you’re completely and utterly wrong.
How to solve this problem? Stop building things the moment you have an idea, and spend some time actually doing the work manually first.
A great example of this is a travel company I co-founded. One of our teams was always asking me to build automated processes for our future customers, before we’d ever sent a single person on a trip. I frustrated them by continuing to decline to do the work of automating something I didn’t know anything about yet, and telling them that once we’d done it with Excel spreadsheets a few times, we could talk.
This stands in stark contrast to a client of mine who built a platform to automate the process of bidding on houses. Before he founded SparkOffer, Mike was one of the preeminent auction-oriented real estate brokers in the country. He’s spent the last 20 years helping people buy and sell houses at auction, so he understands all the nuances of that process. He’s an expert, and he has every right to say that he can turn that process into software.
Another company I work with and have mentioned on this blog several times, Compliable, talked with a bunch of people who all wanted to pay for software that would automate the process of getting state sportsbetting licenses for their employees. It monly took them about a week to build out their first demo, because filling out a PDF isn’t that hard, especially if you do a quick search on Github for the right repo (searching for “fill out pdf form” results in 55 libraries across a variety of languages). Still, it took nearly six months to develop the full version. They took the time to watch, listen, and study the processes people were asking them to automate, and after you’ve seen it done dozens of times, you usually understand how it works.
Compliable was lucky in that it wasn’t hard for them to find people who would let them watch the process and work through it with them. It’s not always easy, but that doesn’t mean you can skip over it.
You also have to consider who you’re building your software for. If it’s for other people, great, go watch them do the manual process a few times first. If it’s for yourself, then it’s because you’ve either a) already done it manually yourself and know what a pain it is, in which case, great, get to work, or b) you haven’t done it yet but think you might have an issue with it someday, in which case, slow your roll, buddy. You might never actually do that process, so why would you automate it now? Or, once you do it, it might be super easy. Only when you’ve done a thing several times, and it sucks the life out of you every time, should you spend any time addressing it.
The larger point of this particular post is “don’t guess”. It applies to more than just automation, but it’s especially important here. When you’re building software, you need to be an expert in your customers’ business. Too many people have too many ideas that they get too excited about, and rather than take the time to know their customers and solve their customers’ problems, they create a solution that, in the end, doesn’t work and nobody wants.
When I was living years ago in Northampton, Massachusetts, there was a law on the books that you couldn’t walk around town with a duck in your pants (I tried to verify this with a Google search and I couldn’t, so just go with me here). It might sound like that law should be scrubbed from the books, but if you think about it for a second, there’s probably a reason that law exists, and maybe it’s even a good one. Maybe, 200 years ago, it stopped that weird guy in town from stirring up crazy shit, running around with ducks in his pants. And maybe, if we changed it, we’d be faced with some sort of duck-pants epidemic. I don’t know, and I don’t want to. But before anyone changes that highly absurd and possibly completely apocryphal law, I hope they understand it really, really well.
— Eric Marcoullier
When you’re totally over your skis, wildly excited about a new idea you just had in the shower, it’s vital to have someone ask, “great, how does that work” and press hard when you hand wave. “I’ll figure it out” only gets you so far. I pride myself on walking the thin line between skeptical and helpful. I’m always #TeamClients and sometimes that means questioning them more than their friends and employees. If thats the sort of help you’re looking for, then send me an email at eric@marcoullier.com or visit my coaching site.
(Photo by Krisztián Reischl on Unsplash)