Starting up in KC
7 March 2015
This is a post that outlines all the things I think have been major take aways from my time working with startups in and around Kansas City. Most of this advice is probably valid far wider than just in Kansas City, but since my experience is very localized here, I figured it wise to hedge my bets.
Over the last 6 years, I've learned a lot about startups. I have immersed myself in startups. I've written software for about 10 different startups and sadly, most of them are no longer around. So, I've learned a lot about what not to do.
Focus
This is probably the single most important thing. If you are starting a startup, it has to be the only thing you are doing. No side projects. No starting two or three or four startups at once. No building the startup community.
You need to focus, it's a huge endeavor. Making a startup succeed requires a lot of work and that work requires all of your attention, until you give it that - it's just a hobby. Don't get me wrong. Hobbies are fine, I fully intend on launching at least one hobby project this year. Maybe that hobby project turns into a startup, but more than likely, it won't.
Not Anyone Can Start a Startup
Startups are fucking hard. Not everyone is cut out to do it. Hell, I'm not sure if I am. I've worked with my fair share of founders that I look back at and wonder why they were a founder. That's not a knock against them, except that they were in over their heads and didn't understand what it meant to start a startup. They had been fooled by the media's portrayal of startup glamour.
If you're starting a startup for the glamour, or even to simply get rich, you're in the wrong business. You should be passionate about the problem you want to solve. There are ways to increase the passion you feel towards something, like working your ass off to build something, but that probably also requires a baseline amount of passion.
Creators Only
You really, really should be able to build a product if you start a startup. This gives you such a leg up on people it's ridiculous. Building something self re-inforces your passion for what you are working on. You've put your blood, sweat, and tears in to that thing, of course you want it to succeed and are more likely to do whatever it takes to keep going. On numerous occasions I have worked on a product for a founder, only to find that I cared more about the product than they did when version one was ready to ship.
There is no better way to learn and understand your product and how to sell it, than building it from the ground up. The people creating it make a lot of little tiny decisions that you as a non-creator never even get to think about and you lose the benefit of reasoning your way through the entire product. In a perfect world you, the founder, have a significant amount of industry knowledge, and that allows you to make fewer mistakes early on. Which greatly improves your chances.
Don't Worry About the Press
You need press a lot less than you think you do. The reason to get early press in a startup is to get a handful of early users so that they can start to guide product development. That's it. That's the only reason you need press at launch, because when you launch you shouldn't be launching a fully featured product. Far from it, what you launch should be somewhere between useful tool and a product.
I think startups value press a lot more than they should, as with fundraising, it is a distraction from focusing inward on your startup, your product, and your customers. Press is a tool to be used sparingly and strategically, it just one possible marketing channel you can use to generate leads.
Shut Up and Ship It
The less you know about the industry or the broader the industry is, the faster you need to get your product into the hands of actual users. That's not saying you can wait around forever to launch if you have 10 years of industry experience. The best thing for your product is to be in the hands of users. This starts a feedback loop. Feedback loops are important in startups, the faster you can get feedback about a new feature, the faster you can improve it.
In fact, the way you should develop is to use Github, or some sort of source control and whatever is in master is a working, shippable product. That's what's in production. Now, obviously there are going to be some rough edges pre-launch. Seriously, use a PaaS (if it is a web app) like Heroku or Azure Websites and always have your master branch deployed there that you can show people (use the herokuapp.com address and the free tiers for everything). This starts some really good software habits early on in the life of a company.
That New Feature is Going Take Two Weeks
But, no. I don't care what it is, two weeks minimum until it is done and being tested, then its still maybe a week out.
We actually tell each other this at Freightview. In fact, we refer to it as Two Weeks™. It's just close enough to signal that it is being actively developed, but just far enough out that you don't want to make any definite plans on it. Notice I also said, feature, that's just one self-contained feature. Yes, building quality software is hard.
It might get done sooner and often does, but you shouldn't make any plans that it will be sooner.
In fact, you probably shouldn't ever give dates to customers on a feature launch until the feature is being tested in staging, when its less than a week out.
This is just the nature of software. Humans give poor estimates, so try and get rid of them all together. Cut the feature into bite-size chunks (or as close as you can get them, some stuff is just a lot harder and time intensive than others) and figure out what the next most important thing to accomplish is and do that. This is when it really pays off to be a creator, or at least have experience running product.
You Need Feedback Loops, not a Business Plan
I used to think that no one needed a business plan. That they were useless documents that started going stale the moment you starting writing them. And I still think that, at least in terms of the business plans I got taught to write in college.
You need basically three things to start a software startup. A plan on how to build product and how to figure out what to build (a feedback loop), a plan on how to acquire users and how to continually evaluate marketing channels (another feedback loop), and a plan on how you are going to make money and how to figure out more ways to make money (another feedback loop). The best plans are feedback loops and you can let different people be in charge of fine tuning each feedback loop to be quicker and to surface more information. Its likely that your marketing and business model feedback loops will sometimes serve as inputs to your product development feedback cycle.
This is one of the reasons building web applications, as opposed to native applications is really powerful. Web applications inherently speed up your feedback loop. When you ship something, the product team can watch usage and figure out if something is broken or see how people are using it immediately. You can ship tweaks to the feature as they are identified and then built, a lot of times by the person who built it and while it's still fresh.
Fire Fast and Grow Your Team Slowly
Blindly hiring to grow is a sure way to doom your company. This approach is what happens when you view employees as resources. Thinking along the lines, "if we only had 2x more developers we could have shipped twice as much code last month," is not likely to ever work out, even if you had hired those developers 3 months ago. Developers take time to ramp up and the more you hire at once the more time you spend training them. Adding developers also increases overhead unless you can figure out how to segment them into small teams effectively, this and more is described in the Mythical Man Month.
You should be very careful about who you bring into your delicate startup. Bad people can seriously affect a startup as it matures, you should be picky and you should pay the people you do pick well. Internal growth at your company should be structured in a way that makes sense and it would do you well to think of it as another feedback loop to monitor and improve.
Part of this feedback loop should be evaluating employees regularly. I'm a fan of weekly or every-other-weekly one on ones and having a whole team activity (like lunch) at least once a week.
Who you hire and how they jive with the rest of the team can have a huge affect on your start up's trajectory. I'm probably not the best to give you advice on how to find the best people, but I think a hack is: you want to find people that build stuff just to build stuff. The people who think about building stuff, or how to sell, or what a product looks like in their free time, and not nearly as a way to punch the clock. You want people who care. You want craftsmen and women.
Bigger isn't Better
I'm a big believer in the power of small, exceptional teams. Teams that are able to take responsibility for a project and that have the authority to implement it in the way they see fit. Creating a team or, later on, multiple teams that care about the project is what you want. It's easy to tell when this happens because your team will start fixing small defects that aren't necessarily broken, but they just aren't quite right and they will do this without any input from their superiors.
I think this is a key reason that startups are able to out execute big companies and building to maximize this effect gives you an even bigger advantage against incumbents.
Startups are hard, but working on one or for one can be a very rewarding experience. I think that the company is probably one of the greatest human inventions of all time. When a company is viewed as a tool to affect change on the world by aligning a group of highly competent individuals toward the same goals, its easy to see why there are so many people jumping on the startup bandwagon.