We use software to get things done. We hope these products will help make our lives better, and that's why it's such a blessing to be a software engineer and startup founder. There are an infinite number of things we can make that potentially make things better. Yet as software creators, we fail — over and over and over again.
Just in the past day, two big brands failed me in major ways through poor software engineering. Last night I bought an Xbox One game and tried to play it. I let it try to install overnight. The software is stuck now — complaining the installer hit network connection issues and won't continue, even though clearly the Xbox One can connect to the Internet. There's no retry button. I'm in a broken state and I don't know how to resolve it. This is a pretty basic use case that is completely broken.
This morning, I tried to use Silicon Valley Bank's new deposit-by-mail feature. First off, it took me over a week and two emails sent in order for them to enable it on my account. I shouldn't need emails to enable a feature like that, let alone wait a week. Then, when they finally did enable the feature, it didn't work at all for the handwritten checks I needed to deposit. The error? "The amount doesn't match the check image." The engineers probably used some off-the-shelf OCR system that barfed on handwriting. There's no workaround. Yet handwritten checks are a pretty core reason why someone would use a mobile phone app to deposit a check. The core use case is completely broken.
This is the inflatable hammer problem in a nutshell — too often, we are given tools that cannot be used for their described purpose. They're broken in fundamental ways.
In the end, SVB and Microsoft suffer from broken product and engineering organizations. These organizations have plenty of resources to make these simple core scenarios work. But it's not a resource issue. These failings usually happen because designers and engineers who actually make the software are divorced from the management organization that sets the deadlines. There's no sense of ownership — merely hitting milestones and knocking off items on a to-do list. I hit my goals — ship it and let's get a beer.
Large orgs also make the mistake of insulating their product and engineering people from the people who actually experience the pain. There are layers of engineers and management and emails go to account managers who can't do anything about it and don't know anyone who possibly could. When I was a PM at Microsoft, the only interaction I had with end users was reviewing Windows Mobile help newsgroups once a quarter. It was like wading through an ocean of pain. It was so sad and ugly to look at, and that was the software we were making — that was the pain we were inflicting on our users.
Silicon Valley is obsessed with the auteur-CEO for good reason. When MobileMe shipped crap, it wasn't OK with Steve Jobs and clear action was taken. When idiotic product decisions are made, it takes someone with power to lay the smack down and enforce a culture in which that kind of thing isn't acceptable.
Startups don't have a creaky old dumb organization yet — it's just founders, right? Yet startups ship bad software all the time. Why? Well, founders have limited time, and the advice to ship-fast/fail-fast is a strong driver. We ship software when the basic case works at all. This is probably still the right thing for people do. But then founders forget to fix things that are broken. The moment your software works at all feels like you're 80% of the way there, but you're really at 20%. A great product is made, not born.
Startups have an even greater chance of success at products because they can listen to users. You don't have many, so you can actually read and answer every email you get. Take a page from Wufoo, who made their engineers and designers do support every single day. This is the best thing you could possibly do. Connect with the pain of your users, and fix the papercuts, no matter how small. That's how you get to a great product.
Don't make the same mistake the big orgs make. If it sucks, cut scope or slip the schedule. Don't cut quality and don't strand your users in frustrating bugs in core scenarios. Fix it and make it better. Listen to users. Fix it. Repeat.
SVB and Microsoft can endure a lot of failure before it affects their bottom line. They've got a lot more things going for them — one is a bank, and the other has a few durable monopolies that have decades of life on them still. But for startups, all you've got is whether the damn thing works. So ship it and make it better.