Sep 18 2012Comments
I was privileged to be asked to speak at the CED TechVentures 2012 Entrepreneurs Workshop this year, and I was part of a series of 8 speakers, each given 7 minutes to talk about aspects of the startup process. My topic was "Secrets of Building Software". Seven minutes is not a lot of time, but I wanted to capture my thoughts from my talk and add a point that didn't make it into my time on stage.
So, here are the 6 (now 7) secrets:
1: The first secret of tech startups: everyone must code
Your team of founders might bring a ton of knowledge, creativity, and experience to the table, but at least one of you must know something about writing code. Just like if you were starting the All American Pie Company, one of you must know how to bake. Or if you were starting 37HorseFarms, one of you must know something about horses. See, the thing is, programmers are a proud, vainglorious lot, and they have a finely tuned sixth sense: they can tell who knows what they are talking about and who doesn't. You need someone with a big enough clue to show up on their radar or, in the immortal words of a previous boss, they will "flip the bozo bit" on you. And trust me, once flipped, that bit don't flip back. Once a bozo, always a bozo, and you may as well try starting that horse farm.
Now, I'm not saying you have to run out and become DHH. But at least one of the founders must know the difference between a web application and an iOS app and be able to say "I'm not sure I follow, but do you mean X?" without "X" being some value of stupid.
2: Get to know your OFR
A lot of people like to talk about building your MVP (minimum viable product). I'm not a huge fan of the term. When somebody has a grand idea for a system, somewhere in his or her head is a Perfect Sparklepony, trying desperately to get out. When you say "MVP", you make them think you are going to turn their Sparklepony into a severed hoof. Minimum Viable Product is all about cutting things, eking things out, squeaking by. It isn't an optimistic phrase.
I prefer the term "Optimal First Release". Optimal means you aren't cutting scope; you are communicating your unique value so that people care that you exist. I hear from founders all the time that there is already a primary competitor in the space, and their "MVP" has to be feature-comparable with that competitor or nobody will buy it. Really? Who would buy a feature-for-feature knock-off of the thing they already have? Why bother? If you aren't thinking differently, then what is the point?
What you need to do is figure out what you are doing differently, and do that, just that. Oh and do it as excellently as you can. Here's the thing - you can definitively prove that you can eventually do that other stuff. How? Point at the competitor. THEY did it, and, as you already know, THOSE guys are LOSERS. If they could do that, so can you. And everyone will believe that. What sets you apart is that OFR - the thing that only you can do. You can catch up on the rest.
3: Features - Speed - Quality: Pick One
You've heard the "pick two" thing before, and if you haven't, well, there's a whole bunch of books you should read, starting with "The Mythical Man Month" and working forward from there. Fast-forward to now, and here's what I'm telling you: optimize quality over features and speed. Every time. The world is full of poorly thought out features that don't string together coherently. But there is an painful shortage of carefully crafted, easy to use software that makes people's lives better instead of worse. We are all drowning in software that we have to use, and systems that subtract years from our lives and deaden our souls. Spend time making software that's a joy to use. Nobody gets excited by checklists of features; but they thrill to quality.
Keep in mind that there are multiple definitions of "quality". There's how well the code is written, and there's how well the feature is received. High quality code is easily maintained, scales well, doesn't break under simple stresses, and is a joy to work with in the future. High quality features are written from the user's point of reference, cover the majority of cases with the smallest amount of user effort, and enable the user to spend more time on important stuff instead of clicking on random crap. The first stuff is important for you, and the second stuff is important for your customers. Make sure you plan for both.
4: Friends don't let friends code alone
Software should never be developed in isolation. Programmers the world over suffer from the same character trait: after 15 hours of staring into a monitor listening to the Tron soundtrack, they cross over into "I'm a genius" mode where their crazy, never-been-tried-before solution is clearly the best way to do whatever it is. And the simple convenience of a second set of eyes is usually all the inoculation we need to avoid this syndrome. Don't let anybody in your world fall down this rabbit hole. Even, and especially, yourself. Get a buddy. This does not necessarily mean you have to practice pair programming the way we do at Relevance. It does mean that you shouldn't be shipping features that have only had one person involved in their creation.
5: Software Development Plans that go More than Four Weeks are Comic Books (and they probably have pretty pictures, too!)
Grand plans may be sweeping, majestic and even convincing, but they are also fictional, and should be enjoyed as such. When somebody shows me a development timeline that shows specific features being delivered on specific dates months in the future, I assure them that the only thing I'm 100% certain of is that the plan, as written, won't happen. Weathermen can't predict the temperature three days from now, because the weather is a chaotic system. Software is a chaotic system too, made of people, and technology, and business goals, and money flows, and geopolitical problems, and, well, life. You can't predict that far in the future. You can SET GOALS. You can MAKE PLANS. But you should know that those plans are going to change. Operate on hardcore, short-term, iterative planning that helps you steer.
Look at it this way. It is 1492, and you are standing aboard the Santa María. Her prow is valiantly aimed to the west. You know you are embarking on a sea voyage. You have to know vaguely how long it is going to take, and how many men to man the ships so you can pack the right amount of food, supplies, etc. But what is the target? Is it "the Port of Tokyo in 194 days?" Or is it "Japan, hopefully before winter"? The key point is to be able to steer, and adjust, and maybe take advantage of the New World when you stumble on it along the way.
6: Software Development is Mostly a People Problem
Don't listen to people who tell you there is only one way to solve any particular problem. "Oh, you HAVE to use Oracle for that." "This is clearly a problem for Python." "Rails is the sendero luminoso." Forget that; tools serve the craftsman. Find people you can trust and can work with, and let them use the tools that make them most effective. 90% of the problems they'll be solving for you aren't algorithmic anyway, so help get the tools out of the way of the problem-solving by being flexible about them in the first place.
Clearly, there are limits to this rule; there are tools that AREN'T capable of solving certain problems. You can't turn SQLite into a cloud-scale graph database. You can't use iCal as a word processor. You'd never want to get COBOL running on an iPhone. But when multiple tools CAN solve the same problem, optimize for the people.
7: Don't Take the Easy Way Out
Focus on simple, for everyone involved in the system. You, your developers, your investors, the users, everybody. Build simplifying things, make them awesome, and don't scrimp trying to get there. There are no easy ways out; somebody always has to pay the price. When you take the easy way out when building software, it is usually at your users' expense.
Let me give you a story, told to me by one of the Relevance team. She has used the same exterminator for years. In every year before this one, the exterminator would show up, do whatever they do, then write a one-page note saying "I was here on this date, I did these things, and here's what you owe." Then the exterminator would tape it to the door and leave.
This year, the exterminator approached her after the job was done and asked if she could sign off on the work. Saying "yes,", the exterminator proceeded to haul a full-sized printer and a hand-held device into her kitchen, make her spend 15 minutes trying to sign on the crummy hand-held device, then spent another 15 minutes printing out three pages of paper with a bunch of details and boilerplate and a poor representation of her signature. Incredulously, she asked "what is the point of all this?" His response was telling: "they say it makes it easier on the back-office folks."
The "easy" in this case is that the system now makes it easy to process all those work streams and invoices and pieces of paper. But the exterminator AND HIS CUSTOMER spent an extra 30 minutes struggling through a difficult process to finish the job. And the kicker — the evil secret here — is that there aren't any "folks" in the back-office anyway; they've been replaced by Skynet, who is really loving having his fleshy robots out doing all the drudge work.
Great software is about removing difficult, boring, repetitive, failure-prone, tangled, messy, awful things from the world. Easy is about foisting your pain onto somebody else. And you almost always arrive at "easy" by starting at "cheap". Think carefully about the investment you are about to make into the system, and the change you want that investment to have in the world. And spend wisely on simple, high-quality, well-developed, easily-digested releases so you can succeed in a world desperate for real successes.