Startup Software Development – Do Your Homework Before You Develop Anything

I just had an all-too common conversation with the founder of a startup who had spent more than a year working with a software development company who had produced a mess. The mess really comes from a developer who was willing to get started on a product that was not fully thought out.

I always take a very different approach in early conversations. If I’m being asked to do startup software development, I’m going to push fairly hard on key questions that the startup needs to have answered before they develop anything. Some founders are taken aback. They are calling me to go build what they tell me to build. Why would I question whether they’ve done their homework? And most often I only know enough about their business to be dangerous. So why ask all these questions if I might lose a potential client?

If I don’t ask the questions and do a little bit of homework, then likely we will end up with a mess.

So what are the questions I’m likely going to ask?

1. Tell me a bit about yourself and why you are doing this.
2. Who are the customers? What’s their specific need / pain? Please be able to provide me with a few specific examples of different types of customers, what they need, what the system will do for them.
3. Tell me about the business. How are you funding this? What level of funding do you currently have? What are the big milestones you have as a business? Do you have any specific deals done that are a basis of this?
4. What’s different, special here? Where’s the mystery (see Matching Algorithm)?
5. Who are the other stakeholders involved? Other types of users? Partners? Administrators?
6. How will you be taking this to market? What channels will you use (e.g., SEO for Startups)?
7. What are your key Startup Metrics? How do you make your money?
8. What already exists in your space? Who are your big competitors? What are some good examples of similar sites?
9. What special data, content, APIs, etc. are you going to leverage? What’s the state of the relationships that brings you that data? What’s the state of those systems?
10. Where do you stand on your brand, name, logo, positioning? Examples of other brands/sites that are similar from a brand perspective?
11. Are there any specific hard dates or important time sensitive opportunities?
12. What do you see as some of the bigger risks / challenges?

Of course, we’ll also discuss the details of the product itself. What does the system do? How does it address the customer scenarios from the start? What's the User Interface Beyond the Web Site? What specific business logic is implied? Etc. This discussion always is at a pretty high level in initial conversations and then drills down from there.

Yes, a lot of these questions are partially answered in a business plan / presentation deck / marketing plan. That’s a great starting point for the discussion, but it’s never been complete in terms of answering all of the above questions.

A lot of the product discussion feeds off the answers to this conversation. We’ll spend quite a bit of time discussing specifics of early versions of the product that will achieve specific business milestones, or reduce certain risks, or prove market, or whatever it is. Without the context of the above, it’s hard to make good decisions from a product and technical standpoint.

In a fairly high percentage of cases, by the end of the conversation (in an hour or less) we are discussing a slightly different system than what we discussed at the start. If you are finding that your system definition is changing as the result of this conversation, then it means that more homework is needed. Actually that’s it…

For startup software development, before you build anything, make sure that doing more homework, asking more questions, doesn’t result in substantially different definitions.

Iterate until you have a stable definition. Then move fast towards a small first phase. Sounds simple, but there’s a lot of work to be done. Of course, that’s the really fun, interesting, challenging work.