share
Stack OverflowDeveloping a software idea into a business
[+106] [9] AndyUK
[2008-11-04 22:30:33]
[ business start-ups ]
[ http://stackoverflow.com/questions/263723] [DELETED]

I am interested in finding out the experiences of those who at one time have come up with a neat software idea, maybe as a result of a hobby, dissertation, college project, etc and have developed it into their own business. Or maybe those that could not endure subordination, wanted to create something for themselves and have done so.

I have one or two ideas of my own I would like to pursue and some of the things I am interested in finding out are:

Many thanks

Andy

(1) careful... I fear pending closure here... ;) - Jason
I doubt that. So far 8 people (including myself) have tagged this as a favorite. I think there are a lot of us here who would be interested in any answers. - Glomek
I am very interested too... I just didn't think others would consider it on topic. I'd like to see more business-of-software related questions. - Jason
That's what I like about this site, if your question is sincere and not off-the-wall it gets considered... - AndyUK
I'm glad you found my answer helpful, even though it was high level motivational. For more specifics, I too highly recommend JP's suggestion to read "Getting Real" by 37signals. - dongilmore
I like this discussion. - Uri
AndyUK - there aren't many questions on SO that I can provide a good answer to. In fact, this'd be the question. My answer has the most votes (by a 2:1 margin). Would you consider marking it as the Accepted Answer? It would mean much to my frail ego. Also, some bug in SO puts it down the page. - Clay Nichols
Perhaps try asking on answers.onstartups.com. - TRiG
[+97] [2008-11-12 10:55:28] Clay Nichols [ACCEPTED]

Did you like this question & answer?
Please click the reopen link above (at the end of the question above) to nominate it to be reopened.

12 Steps To Starting your a Software Company
and 3 Unit Tests to to measure your progress

Or the art of Changing Hats, Calendar Time and not waiting by the phone.

By Clay Nichols

Below are step by step instructions based on my experience running a successful small software company for the last 14 years. Below that are some milestones for measuring your success along the way. These are principles that I just followed intuitively. My partner works in the industry our software serves and so a lot of this ("stay close to the customer" sort of stuff) was built in naturally. I violated the rules about finding customers first one time and that was the only one of my products that wasn't a success (it was, in fact, a miserable failure commercially. ).

How to make Calendar Time work for (instead of against) you
I've found there's a certain amount of "Calendar Time" for things to develop. For example, it takes time for the customer to convert from a "prospect" to a paying customer, and it takes time for the effects of marketing (ads, Adwords, etc.) to take measurable effect. You can't speed up these Calendar Time events so tt's helpful to have something else to work on instead of "waiting by the phone". The steps below interlace marketing/sales and product development productively while also giving you something to do while waiting on something else.

  1. Feel their pain
    Become intimately familiar with the domain you're working in and the pain you're trying to solve. Hopefully, you've chosen one you already know. You might also find your "anchor customer(s)" who already understand your market. They needn't be actual partners. The relationship could be that they tell you about the market and they get the product, built largely to their specifications, free. Beware the single datapoint. Ideal First Customers have an understanding of the computer and what's easy and hard and understand how the typical customer in this market would use the software.

  2. Be the customer.
    Play customer. Try to find an existing solution to the pain. This will show you who your competitors are and how your customers might find you. Be exhaustive. Try forums, google groups, whatever. How do people currently solve the pain? (Perhaps your software is replacing someone, or it might just help them do the job faster). This will be important when estimating the value of your product. Because the price of your product should be based on its value to the customer, not its cost. (The customer will never pay more than how much it's worth to them and they couldn't care less how much it cost you to create it.)

  3. Find a few representative customers.
    As in, people who would pay if you solved their pain. They needn't actually paybut they have to be willing to. Payment is a litmus test at this point, not an income model. Tip: your Aunt Irma who thinks you have the cutest blue eyes and will buy whatever lemonade your stand is selling is not a customer unless she'd pay for the product even if she didn't know you from Adam. Get referrals from #1 or find them while you're searching forums. These will also be your beta customers. I can't tell you how many people I've seen spend months or years working on a product and then ask "how do I get beta testers". How do you know if you're on track if you haven't been at least talking to potential users.

  4. Evaluate the market.
    4.1 . Get a domain name & Build a simple website. Submit to google. This starts the clock (see calendar time above) for getting your site into Google. Let folks sign up to get an email when the product is available. They'll be source of enthusiastic Beta testers and first sales. Be clear with them that the product isn't available yet. 4.2 Read this excellent article by the author of Lean Startups [1]. The basic premise is that bugs in your idea (whether you can make money selling it) are more deadly than bugs in your software. Your product's #1 goal is to test your business idea. (I.e., version 1.0 should be the minimal product to test whether there is a market there for your product).

  5. Paper prototype and get feedback from beta testers.
    Test your vocabulary. Having a clear vocabulary about the product is good indicator that your mental model is well constructed and clearly defined. If ya' don't know what to call it then ya' don't know what it really is.

  6. Alpha prototype. The simplest thing that will be of net positive benefit to the customer. It doesn't need to be professional. It might be ugly. It might crash a bit. As long as it's better than what the customer uses now,it's good enough. Someone asked Seth Godin what advice he'd have for his own child on how to start a business of their own.

    His response? One word:

    Start.

  7. Get feedback from Alpha testers. Interactive demos, etc. Look for common feedback themes.

  8. Find keywords that your customers use
    If you can find the lingo your customers use when describing their pain then you can use that vocabulary in your site text and even get a domain name with that text. And you can even find keywords that your customers ("Marketing Segment") use even when not discussing the pain. E.g., if you find that the "pain" you solve is the pain of using paper records in a hospital (your solution: Electronic Medical records). Obvious keyword are the solution ("electronic medical records") the problem (" best way to store paper medical record") and also just words your marketing segment uses: Find Doctors (or Hospital Sys Admins) who are techies.
    Start an Adwords campaign to start finding out the right keywords. Make "beta trial sign up" one of your conversion metrics. A willingness to give out their email address is the closest (and dearest) thing you can ask of the visitors at this point. All visitors are not equally interested (or equally likely to buy your product). Ones that sign up to be a beta tester are much more likely to be worth your time selling to. The goal of the Adwords Campaign is to find which keywords are likely to attract customers, not simply attract visitors. If all you wanted were eyeballs on your site, you'd just advertise "free sex". But out of the nearly billion people on the internet, you want the folks who are likely to be your customers.

  9. Beta version. Get Beta feedback. Does everyone have trouble starting the program? Do they all ask the same questions "What does XYZ mean?". Remember: add features that help a large % of your users and harm a small % of them. Stay focused on your goal. If you're creating a Contact Manager and someone is using it for some other task they'll start asking for weird features to get their non-standard task done. On the other hand, if a lot of your users all "misuse" it the same way maybe you've discovered an unmet need. That's how Flickr started: it was originally a gaming site with the option to share photos. Turns out the photo sharing was the "killer feature". They sold it for around $20 Million. So... look for trends and make sure that the customers who are giving feedback are representative of your market.
    UserVoice [2] is a great way to gather this info. Users get to suggest features (or you can suggest them) and vote on each others ideas. They have a free "starter" edition that works find for small companies.

  10. Let visitors to site sign up to get a trial when it's ready.

  11. Let some of them try the trial if you think it's ready.

  12. Work on Beta 2.

SUCCESS MILESTONES A software company could be considered a Software Factory pattern. And what's a pattern without a Unit Test? Here are three to get you started.

  1. Finding beta customers for whom your Pain Story resonates. They understand they have a problem and see how your product could mitigate their pain.

  2. First dollar - First sale (ideally to someone who doesn't already know you, but hey take what you can get) - validates the value of the product

  3. Stranger Money - Next 10 sales - validates your marketing. (If you can get 10 sales from strangers for $x in marketing then that's probably repeatable and there is a future for revenue from this product. Whether there is profit is another question. But if you can't get to this point, then you'll never reach profitability)

[1] http://www.inc.com/magazine/201110/eric-ries-usability-testing-product-development.html
[2] http://uservoice.com/

Wow, some interesting points there. Thanks for posting. - AndyUK
I've tried to articulate the concept of calendar time before, but you really hit the nail on the head. Thanks so much for that! - Micah
This is really a fantastic answer - more useful than some full books I have read. - nshaw
The milestones were a nice thing to see. Shows that the ones I have in my head are somewhat similar. However sadly I am still in between 1 and 2. - corymathews
Answers like this are why answers need to be favoritable. - Jesse Dhillon
(1) This is old I know but - I've expressed calendar time before as: 'it takes nine months to make a baby, more people working on the same thing won't speed it up...' - Stevo
1
[+26] [2008-11-04 22:54:42] JP Richardson

I really like the book called 'Getting Real' by the company 37 Signals. The book is about creating a profitable and successful web application. However, the advice in this book isn't only applicable to web applications, as it contains a lot of excellent advice for software developers who just want to market an application.

I highly recommend you check it out, as it might give you some more advice. The book is free to read online.

http://gettingreal.37signals.com/toc.php

-JP


Dude! This book is too awesome! - hasen j
Check out David Heinemeier Hansson's talk at Startup School 98: 37signals.com/svn/posts/981-the-secret-to-making-money-online. A must see. - Pascal Thivent
2
[+13] [2008-11-04 22:46:48] Micah

What you'll hear from most is "Fail Fast" - you want to spend as little time as possible before finding out if your idea is viable.

Essentially, you want to get your product out into the marketplace as quickly as possible. Try to write a beta, or feature-lite version that has only the core essentials. Get it in front of users ASAP, so they can tell you where you're wrong, because you almost certainly don't understand it as well as you think you do. If they like the core, start refining. If they don't scrap it and move on.

As to price, I've heard that most startups under-price their products.

If you're really interested in striking out on your own, a better place to ask these questions is http://news.ycombinator.com


3
[+10] [2008-11-04 23:04:46] pro3carp3

Check out the Business of Software [1] discussion board.

[1] http://discuss.joelonsoftware.com/?biz

4
[+8] [2008-11-04 23:28:24] Andy Brice

The only way to know for sure if a product will succeed is to launch it. But you can reduce your risk of failure by taking the following steps (much condensed, obviously).

-Decide who your ideal customer is. Approach some of these people and find out what your product would be worth to them. Talk is cheap - try to get some committment from them, e.g. a promise to buy when it is released.

-Google for competitors. Lots of competitors=bad (probably too much competition). No competitors=bad (probably no market). A few successful competitors with mediocre products=good.

-Think carefully about marketing your product before you start programming.

-Launch ASAP with a minimal feature set.

-Iterate like crazy based on customer feedback.

See also related question:

http://stackoverflow.com/questions/86998/whats-the-best-way-for-a-developer-to-start-hisher-own-business


The only thing I'd argue here is doing too much research into competitors. Sometimes ignorance of competitors will allow you to develop a product that by default is superior instead of "also doing" what your competitors did. - Mat Nadrofsky
Mat, there is some truth in that. But I definitely wouldn't advise doing no market research. At least find out number of competitors, company size, product pricing etc. - Andy Brice
I'd suggest having a good understanding of the problem first (to avoid contaminating your ideas with competitor's inferior solutions). Research no for copycatting but for knowing how to set yourself apart (easier, faster, richer, cheaper). - Clay Nichols
5
[+8] [2008-11-05 00:02:38] dongilmore

Turning an interest into a business: it is easy to find lots of examples of success and failure. How to apply these lessons to your own situation is not so clear, but your starting point is excellent: something that interests you.

You can look at examples of success stories, and you can try to follow the same steps towards success, but the real world can not be controlled like code. Timing and luck are huge. You may be rewarded beyond your wildest dreams for a trivial accomplishment, or you may be totally ignored for the best thing since sliced bread.

Learn all you can from others, but make sure you are on your own path, doing work you enjoy, building something you believe in, preferably with a small team on the same path. Learning from your own successes and failures is profound. If you maintain interest, that in itself is success. Best of luck!


6
[+5] [2008-11-24 01:43:49] Mat Nadrofsky

All of the suggestions made so far are fantastic. I would also highly recommend the book Founders At Work [1] by Jessica Livingstone who is a founding partner at Y Combinator which is a start-up funding company mentioned in one of the replies you've got already. Heck, Joel Spolsky [2] wrote the foreword for that book.

A great resource to also check out (and while I'm on the topic of shamelessly plugging Y Combinator) is to have a look at Paul Graham's [3] site, also a founder. His essays on software start-ups and the numerous adventures to be had by starting one are fantastic.

Last but not least, I'll plug another favourite, Seth Godin [4]. Can't go wrong reading his blog.

Last but not least, my own personal bit of advice. Just do it. It's largely all about motivation. The rich and successful are motivated. They got up and did something. They likely failed the first time and the time after that, but they never gave up. That motivation was always there. Yes you need to have a good idea, yes you need to make it technically sound, yes you need a good lawyer... blah blah blah. First and foremost, start doing. The rest of those details you'll pick up along the way.

Best of luck!

[1] http://rads.stackoverflow.com/amzn/click/1590597141
[2] http://www.joelonsoftware.com/
[3] http://www.paulgraham.com/
[4] http://sethgodin.typepad.com/

7
[+3] [2008-11-24 02:58:21] hendrixski

Excellent question! Startups usually need more than one person because usually a marketing guy can't write code, and vice versa. Finding out if the idea is something people want is what the marketing guy can do, and writing the code is what you can do. My experience, from doing two startups is that writing the code will teach you new things (or at least patching together bits of code from pre-existing sources, I found that if you write too much code you're probably doing something wrong because much of it should have been written already).

Somebody else mentioned some blogs like Joel Spolsky and Paul Graham, I'll second that. Both of those have been a huge influence on me and kept me going when things got tough. One thing that Paul keeps saying over and over again is that you gotta get a beta out there as soon as possible, and then improve it rapidly. So code up a beta, and then you and the marketing guy/gal have something to show people to get better feedback to drive you towards making the right product.

Hope that helps


8
[+3] [2010-06-27 20:54:11] joe snyder

One of the first calculations you should research is the size of your market and how much of it you can grab. If your software will be for left-handed goldfish owners who drive red volkswagens then your customer base simply won't be big enough to support your efforts. Cash flow is the blood that keeps a business alive. How many copies do you have to sell each day at what price to pay your bills and make a sufficient profit? Those numbers can be sobering.

There are many similar common startup pitfalls to watch out for, and most of them aren't specific to software. Review the vast literature on " why new businesses fail [1]" to make sure you avoid those mistakes.

[1] http://www.google.com/search?q=why+new+businesses+fail

9