Product Development Starts With A Hypothesis, Not A List Of Requirements

For a startup to be successful, the founders (or whoever owns product) need to have strong opinions about both the market problem and the product solution.  Sometimes - maybe even often - this means ignoring your users.

That doesn't mean that you don't listen to your users - even companies as insular as Apple and Nintendo do some work reaching out to others.  Apple designs for others; they just don't do formal market research. Nintendo has "random employee kidnappings".  But if you don't have the luxury of having the singular, strong editorial voice that Apple gets from Steve Jobs or that Nintendo gets from Shigeru Miyamoto (or that 37signals gets from Jason Fried), you probably have to set yourself up to conduct lots of experiments.

Do you remember your scientific method?  If not, here's a really, really good primer on the scientific method.  Never mind that it's written for children - it's good.  Here are the steps:

Ask a Question
Do Background Research
Construct a Hypothesis
Test Your Hypothesis by Doing an Experiment
Analyze Your Data and Draw a Conclusion
Communicate Your Results

If you've noticed, we've actually done the first two steps.  Asking a question is finding a market you're interested in.  Doing the background research is figuring out the problem statement.  The next step, where we are now, is to construct a product hypothesis.  Remember, when you test hypotheses, they're falsifiable - you only can find out what *doesn't* work for sure.

What this means is that you have to keep pivoting until you find yourself in product/market balance.  Too bad that every product hypthosis and every pivot costs you in time, money, blood, sweat, tears, and all the other various inputs.  You can't iterate forever; you're going to run out of one of those inputs (most likely money).  

The only way to reduce your time in this cycle is to make a really good hypothesis from the get-go.  If you're not playing with other people's money, then you better make sure that you don't have to pivot at all.

Listen to your users on the problem statement - they can feel that pain.  But listen to your judgment on the first product hypothesis - there's a reason you want to solve this problem, and it's not because you're a stenographer.  It's because you see something everyone else doesn't.  Asking better questions allows to more clearly see what others - even your users - may not.  Here are some better questions to ask:
  • Are your customers time poor or just frustrated with the time they have to spend on a task?  
  • Are your customers cash poor or not seeing value for their money?  
  • Are your customers status poor or are they embarrassed to use your product?  
Customers often will tell you one answer, but they often mean another.  It's your job to 1) ask better questions, 2) read between the lines of the answers, and 3) use your judgment to make a really good product hypothesis.

Dropbox doesn't save a large amount of time; but it makes saving/retrieving files thoughtless.  RC Cola just didn't have the status of Coke (or Pepsi); you can always get store brand pop if cash is king.  

If you better understand the true pain, you'll make a better product hypothesis.  Dropbox is great because it "just works", but it took Drew to define what "just works" meant above and beyond Mozy, Carbonite, XDrive, and every other storage in the cloud provider.  RC Cola "tasted better" (they won every blind taste test they sponsored, supposedly), but it turned out that people didn't pick their pop based on taste.  They picked it based on status, nostalgia, inertia, (and as the supermarkets found out) price as a tiebreaker between Coke and Pepsi.  Remember, your users may lie to you.  

Users may not know what they want in a product until you show them.  But they always - always - know their problem.  

(That's what Steve Jobs is so damn good at.  He keeps using Apple's prototypes until the stabbing pain of the problem Apple's identified goes away.  Then and only then does he bless a new device/program/feature.  See copy/paste on the iPhone.)  

Your judgment on how to solve the (real, maybe unstated) problem of your potential customers is your initial competitive advantage.  Your ability to get a product hypothesis out there that your users don't immediately reject (and hopefully would be terribly disappointed if you took it away) is what gets you paid the big bucks (when you exit).
4 responses
Liked the point: 'Users may not know what they want in a product until you show them. But they always - always - know their problem.' Interpreting what users say and making the right hypothesis soon is important.
Great article sachin.
sometimes the customers dont know that they want. They dont know where the technology is heading. Instead of cloud they always wanted to change hard drives without shutting down the server. :)
1 visitor upvoted this post.