Two years ago, I partnered with an awesome CTO, Alex Lines, to start a company called Path 101. We didn’t get enough traction on the product and business to continue it fulltime, so we’re now working on it as a nights and weekends thing as we take other jobs. This is the 1st of a series about what I learned starting up a company.
Raise money--That's the first thing many entrepreneurs think of when starting a business. They plot world domination schemes that hinge on their ability to get an angel round together, without answering a lot of important product questions first. That's fine if you're Rich Barton from Zillow and Benchmark gives you 7 million bucks to go do to real estate what you did to travel at Expedia. If you're running leaner and you're raising "Get something up" or "just feed ourselves for a little while" money, you need a lot more questions answered.
That was our first mistake at Path 101 and I'll take the blame for that one personally. Or, you could think of that mistake in a different light and say that I should have realized that we were going to have to be a lot more experimental and iterative. That would mean needing closer to a million dollars than the 350k we raised—and we definitely could have gotten more. We just had this innate desire to be lean and only take what we thougth we needed. Nowadays, I tell people to take twice what they think they need, especially if they’re doing this for the first time. Maybe it should have been a little of both, but regardless, wireframes, specs, etc should all be done before you take money. Granted, these will all change, but you can go a long way to honing in on the product roadmap in great detail on your own time.
For example, Aardvark worked on their product design and user interactions for 8 months before writing any code and before taking a big slug of cash. The social answers platform started out with a dude on the other side of a chat account manually interacting with users in a structured way in order to product test. They knew a ton about how their product was going to work and what it needed at the onset of development--and that's something you can do nights and weekends or bootstrapping. It doesn't need a designer either. Just tell me your best thinking on exactly what the product will do, in detail--talking basic wireframes here--at each milestone and how much money it will take to get there.
Milestones are important because not only does it help to estimate cost, but it helps figure out revenue and funding potential. You can (and should) take a wireframe to a customer and say "If we build this, will you buy it...and if no, why not?"
VCs may be a little different. They probably won't take a vaporware presentation very seriously unless you know them or someone vouches for your ability to build something. Get a warm intro. Scared that they'll take your idea? Someone can steal your idea a month after launch anyway, so what's the difference?
At Path 101, everyone we talked to thought that the idea of pulling resumes off the web to figure out career paths was really interesting. We talked about what data you might want to pull out of the Resume Genome Project but not a lot about what the data actually needed to look like to be useful to a user. There was no way we were going to get that right on the first try, but there's no reason we couldn't have had three or four iterations of that done--not just to show investors but to show developers, too. This would have helped us get a sense of technical challenges that maybe we weren't considering or just to generate more interest in our vision.
There wasn't a good model out there for what we were trying to do, so answering a lot of the questions about how users were going to interact on the site would have gone a long way. Instead, we did a lot of this research (and made more mistakes) when we should have been developing to more specific, vetted milestones.
That was lesson number one--more to come.