Hacker News new | comments | show | ask | jobs | submit login
How to evaluate and implement startup ideas using Hypothesis Driven Development (swombat.com)
76 points by bensummers on Jan 7, 2011 | hide | past | web | favorite | 14 comments



A fourth question that came up for me was "Will I enjoy doing it if it is a success?" I only focused on this aspect after I asked the question can I make money from it and realized that it was not something I wanted to sustain in the long run.

Once the will I enjoy it question is answered, then Swombat's three questions are definitely the way to go.


That's definitely important for some people. As I said, the exact questions are unique per person/idea combination. What you prioritise first will depend on your skills, your concerns and fears, your past experiences, etc.

For example, if you got burned by building something great that no one actually used, "Can I find users?" will be pretty high up the list.

This is not a method for avoiding all mistakes - it won't save you from all your blind spots. But it gives you a better chance of leveraging your experience and getting somewhere.

I'll write another article at some point about how to generate those questions.


Looking forward to reading your article on how the questions are generated and what else goes forward. I have been thinking about this quite a bit after doing a failed startup, working at a startup with funds, and pursuing a startup currently. Thanks for the great blog post.


Some hypotheses missing from Daniel's list:

   o customer problem or need
   o symptoms that indicate customer problem or need
   o description of benefits that customer will understand
   o features to support benefits / solution customer will accept
See also Ben Yoskovitz's "Useless Feedback" at http://www.instigatorblog.com/useless-feedback/2010/06/14/ which begins:

   Asking a friend, "What do you think of my idea?" is almost completely useless.
   Asking a friend (or someone else who isn’t as biased as your friend, 
   "Do you have this problem, and how painful is it?" is a much more useful query.


Another useful method of opinion getting I have found to be useful, is to directly beg/ask for criticism.

"Please tell me all the bad things you can think about this idea." "Please tell me all the reasons you think this idea will not gain traction and will fail" "Please tell em why quitting my job to pursue this idea is a bad thing"

Questions that openly invite criticism are useful, since I think people think more imaginatively when they are being critical ... there are only so many ways to say nice things about something, but the insults can come from anywhere.

More than just finding fault with the idea, you will find assumptions you had implicitly made being challenged. So even if the idea is good, it might still be a bad idea to pursue it, lest you end up with a "the operation was a success, but the patient died" scenario.

If you have a cofounder, take it in turns, over two days, to defend/attack the idea. Defend your idea like Fort Knox on day one, and then attack it like it owes you money on day two.


The ACH method would be useful in conjunction with this: http://en.wikipedia.org/wiki/Analysis_of_Competing_Hypothese... (once you gather data to back your hypothesis)


Seems very much like the practices of customer development part of Lean startups. But leaner.


Thanks, I'll take that as a compliment!


He missed to most important way to start testing your hypotheses: go talk to customers


I wasn't listing out ways to resolve the hypotheses, just a method for using hypotheses to drive the startup. Talking to potential customers is obviously an essential step in resolving questions like "what features are people willing to pay for?" or "will people be willing to pay anything for this?"


Even better is to aim not for something you can get people to use, but instead try to build something you can charge for immediately

I don't get this. If no one can use it, what are they paying for?


Convincing people to pay for something generally entails providing them with something they can use, or at least with the pledge of something they can use.

One common way to go about this is to create a paper prototype, pitch it to potential clients, get them to sign a non-binding letter of intent to buy the product if you develop it as per the specs, and then develop the product and sell it to those people who already told you they'd buy it.

This is as contrasted with the somewhat more common, but often less successful approach of building something useful to a bunch of users, letting them use it for free while you develop the offering, and then asking them to pay.


This gives a fresh perspective on the matter. Never thought about evaluating questions this way. Ill give it a try !


splitting a project in small steps and moving from step to step based on results analysis is something i've suggested even for contracting web projects




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: