As you know, Bob, I spend my Saturdays ranting opining here on TechCrunch, but I spend my work weeks writing software, building apps, sites, and services for the fine startup-to-Fortune-500 clients of the software consultancy HappyFunCorp. (Check out our spiffy new web site!) In that time I have learned many lessons from our clients…the hard way.
By which I mean: over the years I have seen far too many clients make disastrous mistakes. (Or at least try to. I’m pleased to report that we’ve often managed to talk them back onto the path of righteousness.) Below you’ll find a list of ten of the most common tragic client errors. I beseech you, clients of the future; please try to make new mistakes. These ones are getting a little old.
Names have been omitted to protect the guilty. We’re all friends here, right?
1. Premature Scaling Is The Root Of All Evil
Yes, scaling is both hard and important. Yes, your app/site/service needs to be built within a technical architecture that can scale…
…but you would be amazed how many clients focus an an enormous amount of their attention on whether it already does. Founders who haven’t even launched yet, convinced that their baby will instantly become the biggest thing since sliced bread, grow obsessed with whether their app can handle a million users, ten thousand concurrent … rather than, say, whether anyone who doesn’t personally know them will ever discover that the app exists, and how many of those people will install it, and how many of those people will use it, and how many of those people will use it regularly.
Dear clients: Focus on your product, not your stress tests. You don’t need to launch with a back-end API already built as a full-fledged service-oriented architecture ready to scale to an arbitrary number of users. A decently-architected app running on a scalable service (Heroku, App Engine, reasonably-set-up AWS, etc) can scale to quite a sizable number of users without too much effort. And if and when you start bursting the seams of that envelope, you know what, that’s a really awesome problem to have. That means you’ve already won the lottery, because you’ve proven that your app/site/service has mass appeal. If your app is reasonably well-designed, your eventual scaling problems will be solvable. If it isn’t, well, you’ll never get to that point in the first place, because…
2. Technical Debt Will Kill You
Clients often come to HFC because they’ve had a Minimum Viable Product built on the cheap and then discovered, the hard way, that this often means it’s a hornet’s nest of bug-ridden spaghetti code. You know what clients in that situation really don’t want to hear? “The best solution here is to scrap the whole thing and rewrite it from scratch.” You know what the truth is, 90% of the time? “The best solution here is to scrap the whole thing and rewrite it from scratch.”
Dear clients: if the expert engineers you have hired are telling you this, swallow hard, bite the bullet, and listen. We know you don’t want it to be true. We don’t want it to be true either. We want the code you bring us to be elegant and extensible so that we can build new cool stuff rather than reinvent the wheel so that this time it’s actually round, rather than pentagonal. But bad code is often so bad that rewriting it is easier than fixing it.
Also: you know all those times when we said, “Well, the clean and elegant solution to Issue X will take a little longer,” and you said, “I have a demo on Wednesday, just get it done now”? Every time that happened, you accrued a little bit more technical debt. If you don’t build in time for testing and maintenance — and if you don’t keep that time, no matter what happens to the schedule — you’ll just keep accruing more … and bugs will start popping up more frequently, and the pace of development will grow slower and slower, and you’ll very soon lose far more time than you gained by cheaping out on writing tests and refactoring old code.
Dear clients: a stitch in time really does save nine.
3. Google Doesn’t Care
I’ve had clients who wanted to keep all of their plans incredibly hush-hush, NDAs for anyone who so much as breathed the same air, for fear that their genius idea would be stolen. Dear clients: with rare exceptions, the broad strokes of your ideas don’t much matter. What matters is your execution.
I’ve had clients who were convinced they could get Apple or Facebook to change their app rules. (And, OK, one client that actually did, but they’re the exception which proves the rule.) I’ve had clients who didn’t want to host on App Engine because they were worried about lock-in — a risk, granted, but one of the more improbable among the panoply that startups face — but also because, believe it or not, they worried Google might steal their code or degrade their quality of service. (I’m very fond of App Engine, despite its idiosyncracies, because it usually makes both initial development, A/B testing, and subsequent scaling fast and very easy. Just ask Snapchat or Khan Academy, both of which are App-Engine-powered.)
I even had a client who refused to host their video-related iOS app on Google servers because Google owned YouTube and was therefore a direct competitor and not to be trusted. They wound up on AWS. Because it’s not like Amazon does video, right? Oh, wait…
Dear clients: you are not industry players, at least not yet. You will be lucky if any of the Stack behemoths pays any more attention to you than an elephant does to a flea.
Speaking of Stacks,
4. You Are Not A Platform
Platform. It’s a magical word. Everyone wants their app/site/service to one day be a platform. Unfortunately, this can lead people to believe that this is what they are in fact building.
With a few very rare exceptions, that is not how this works. You don’t build a platform; you build a product. You plant a seed. If the product is successful, if it gets better and better, and eventually grows into a tree, then maybe you can turn that tree into a platform. Not before.
Dear clients: stop adding platform features — in fact, stop adding features full stop — and start removing them. Seeds need to be small in order to take root and grow.
5. Stop Trying To Make Viral Happen
I know, I know. You have it all figured out. You just need to get a few people to start using your app, and they’ll tell a few friends, and they’ll tell a few friends, and so on, and so on, and voila, you’re the new WhatsApp. Right?
And hey, you know what? Something like that just might happen. Some of the apps we’ve built for our clients are genuinely pretty great. But do you know the only reason why it might happen? Because your app is cool or useful. Do you know one reason it might not happen? If you keep reminding your users to log in with Facebook, or share with Twitter, or pin to Pinterest, over and over again. Such demands are neither cool nor useful.
Dear clients: yes, you do want to make it easy for users to share. But if your app doesn’t go viral, it’s almost certainly because it isn’t useful/good/fun enough, rather than because it doesn’t have a sufficient density of prompts to share. You don’t want to obnoxiously pester your users with calls to action. Furthermore, if “going viral” is your only marketing plan…
6. Have A Map Of The Valley Of Despair
Y Combinator calls it the “trough of sorrow.” I prefer “Valley of Despair” (well, actually, I prefer “Bog of Eternal Stench“, but nobody else at HFC does.) It’s what happens in the weeks and months after you launch, when the surge of interest and adrenaline from the initial press and email blasts wears itself out, and you’re left with nobody but your baseline regular users … who may well number in the mere hundreds.
There are a million-plus apps already available in the App Store and Google Play, and, to quote Fred Wilson, “Not only do we have a rich get richer dynamic in mobile apps, but we also are witnessing a maturing market consolidating.” It’s never been harder for an app to become a breakout hit. It’s also never been more lucrative … but that’s scant consolation if you don’t make it.
Dear clients: know your market, and have a marketing plan other than “launch and go viral” — and talk to us about it.
7. Stop Trying To Be The NSA
You would be amazed how much time and effort clients put into analytics. Adding ever more events to track, ever more values to measure, heat maps, demographic breakdowns, elaborate custom-built reporting interfaces, a dashboard for every occasion, you name it. Is Google Analytics good enough? Should we use Flurry? How about Mixpanel? New Relic? (OK, New Relic is actually pretty cool.) Does iTunes Connect have an API we can use to download that data hourly? And we have to have our users log in via Facebook, so we can get their demographics, and their interests, and their friend graphs!
Now, granted if you have a good reason to analyze all this data — and if you have users who are actually, you know, generating it for you, and your privacy policy is clear and upfront — then it can indeed be incredibly valuable. But all too many clients don’t actually know what they want to learn from their analytics. Instead they take the NSA’s approach: “collect it all and look at it later.” This is a mistake.
Dear clients: I know Big Data is the phrase of the era, but you won’t get valuable insights from just collecting the maximal amount of analytical data and then randomly browsing through it in an ad-hoc manner whenever the mood strikes you. You need to figure out in advance what your key metrics are, what it is you actually want to measure. Stop trying to replace “asking the right questions” with “throwing more unwanted answers onto an already huge pile of analytical noise.” Instead, start defining exactly what it is you want to learn from your analytics.
8. Stop Managing By Crisis
Project management is a fine art, and a lot of clients are new to it. I do understand, and greatly sympathize; they’re taking a risk, they want results, they want them as fast as possible, and they don’t fully understand when engineers tell them about the unforeseen problems which inevitably arise. They just want it to work, dammit. A noble goal.
But there’s a particular kind of vicious managerial cycle which I’ve seen happen a few times. A client pushes the panic button, instigating crisis mode; engineers (and designers) respond, because hey, it’s a fire drill; and then the client, noting how that big red button got results, just keeps pushing it over and over again, whether or not there’s an actual crisis … without really noticing how the results keep diminishing, because nobody can work in crisis mode all the time, and after a few weeks it loses all meaning and begins to just breed resentment.
Dear clients: save the big red button for real crises. If things seem to be wandering down the wrong trail, or moving too slowly, just sit down and have an honest and open conversation about your concerns. You’d be surprised how effective that is, and what you might learn from such a discussion.
9. Let It Go (For Enterprise Clients)
I don’t need to write this point because someone else already has: I give you the brilliant Half-Arsed Agile Manifesto.
Dear clients: if you work for a hidebound bureaucratic large company, and you’re hiring an agile software consultancy, read this. And cringe.
10. How To Report A Bug
OK, this may sound like a mere pet peeve. And it probably is one. But it’s one which has consumed an enormous amount of my time over the years.
Dear clients: when you are reporting a bug to an engineer, never ever ever say “it doesn’t work” or “it’s broken” or the like. Instead, use the form “when I did X, I expected Y, but got Z” — and then specify X, Y, and Z in reasonable (or even unreasonable) detail.
Postscript
Dear clients: we like you, and we genuinely admire you, and we think your idea is excellent and could be big. We really do, or we wouldn’t be working with you. We want you to succeed almost as much as you do. Help us help you, and avoid making these mistakes, or at least open your mind to the possibility that they might be mistakes — and you will maximize your chance of success. I solemnly swear this in the name of Knuth.
Image credit: Pixabay, public domain.