> So, why don’t just go and ask people what is their problem, and how you could solve it? [...] Elasticsearch. It was born when Shay Banon tried to build a tool to search his wife’s cooking recipes.
It's a cute anecdote, but I honestly have no idea how you would get from "my wife wants to organise her recipes" to "my wife wants a distributed multi-tenant schema-free json document full text search engine"
> JAXenter: You started Compass, your first Lucene-based technology, in 2004. Do you remember how and why you became interested in Lucene in the first place?
> Shay Banon: Reminiscing on Compass birth always puts a smile on my face. Compass, and my involvement with Lucene, started by chance. At the time, I was a newlywed that just moved to London to support my wife with her dream of becoming a chef. I was unemployed, and desperately in need of a job, so I decided to play around with “new age” technologies in order to get my skills more uptodate. Playing around with new technologies only works when you are actually trying to build something, so I decided to build an app that my wife could use to capture all the cooking knowledge she was gathering during her chef lessons.
> I picked many different technologies for this cooking app, but at the core of it, in my mind, was a single search box where the cooking knowledge experience would start a single box where typing a concept, a thought, or an ingredient would start the path towards exploring what was possible.
> This quickly led me to Lucene, which was the defacto search library available for Java at the time. I got immersed in it, and Compass was born out of the effort of trying to simplify using Lucene in your typical Java applications (conceptually, it simply started as a “Hibernate” (Java ORM library) for Lucene).
> I got completely hooked with the project, and was working on it more than the cooking app itself, up to a point where it was taking most of my time. I decided to open source it a few months afterwards, and it immediately took off. Compass basically allowed users to easily map their domain model (the code that maps app/business concepts in a typical program) to Lucene, easily index them, and then easily search them.
> That freedom caused people to start to use Compass, and Lucene, in situations that were wonderfully unexpected. Imagine already having the model of a Trade in your financial app, one could easily index that Trade using Compass into Lucene, and then search for it. The freedom of searching across any aspect of a Trade allowed users to convey this freedom to their users, which proved to be an extremely powerful concept.
> Effectively, this allowed me to be in the front seat of talking and working with actual users that were discovering, as was I, the amazing power that search can have when it comes to delivering business value to their users. Oh, and btw, my wife is still waiting for that cooking app. Now, 10 years later, it is the basis of Elasticsearch.
You're right, the anecdote does not give enough guidance on how to create a successful startup that provides a solution for the users. Even though people face certain problems and challenges on a daily basis, they often don't fully understand these problems and have not been able to envision a solution.
“If I had asked people what they wanted, they would have said faster horses.” -Henry Ford
this quote keeps getting used as an example of not talking to users, but i think the interpretation is wrong.
henry ford seemed to know that people wanted faster transportation.
how did he know that?
the thing is that you are not asking people how they would solve their problems, but instead ask them what the actual problem is.
instead of asking: what would make your work easier? -> faster horses.
ask: what is the biggest problem in your work? -> horses are to slow.
once you understand the actual problem, you may come up with a solution that is beyond what people can imagine.
if people didn't want faster transportation, cars may not have taken off. but i think that kind of problem was pretty obvious, so there wasn't a big need to ask.
You're right. The quote should not discourage talking to users, but it should encourage true communication about the challenges that users face. In agreement with you, an important point is that most all of us are unable to articulate the specific problems we face everyday, and therefore we absolutely can't just tell some smart industrialist or software engineer how they can apply their skills to solve our problems.
It’s not about cute but about a person who is a software engineer and who’s privileged enough to afford not to have a job for enough time to only do open-source for a while.
Maybe his wife is super technical and actually said, "I want a distributed multi-tenant schema-free json document full text search engine so I can more easily organize my recipes"
I've been working for 10+ years for the same company.
We have kinda of a solid product in the market, and by "solid" I mean "it pays the bills for a bunch of people, consistently".
We're in no way a stellar company, we're more on the "dark side" of SaaS, and the reason as to why we have a selling product is that we cover, on the cheap, a real need from our customers.
I'm _just_ a developer, and even thought I have a personal relationship with the founders (10 years back it was just 4 of us) it's been increasingly difficult to get them to discuss product development based on "what the client needs". And that is after 8 years of development of a parallel, competing product that got nowhere except eroding our first one.
I think the first question to ask is if the people that can take the decisions are willing to take them.
You find ten people in an industry, you ask them what sorts of problems they have, or whether and for what they're using Microsoft Excel. If four or five (or better yet all of 'em) have the same problem, or use Excel for the same purpose, you build software that solves the problem or replaces Excel.
In a vacuum, your ideas are things that you can come up with. Maybe they're problems you have, but those problems might not be problems you're willing to spend money to solve. Often the 'idea' is something you as a founder think will be credible, and you end up with a "sitcom startup" (http://www.paulgraham.com/startupideas.html), something that might come from a writer's room.
I've never built a startup. I worked at a consulting firm that took money in exchange for building the software that some sitcom startups tried and failed to use, and I've worked at two successful venture-backed startups that followed the pattern of finding a problem and trying to solve it.
First customer (and their problem). I'd recommend 'Wizard of Oz'ing a solution to their problem for them before even writing code, if possible. Consult for/with them for free. If you successfully solve a problem for someone without code first, writing the code becomes a whole lot more straightforward.
Well.. you're here now. Speak on it. Did you find a user? How? Did that user have a problem your product solved, or did you iterate on the initial product to solve that user's problem?
And yet the (probably apocryphal) Henry Ford quote "If I had asked what my customers what they wanted they would have said faster horses" stands in counterpoint.
Talk to your customers, but leave room for your vision. If the customers knew the answer it wouldn't be a problem.
I think that (probably apocryphal) Ford quote is a bit of a red herring.
Sure if you ask your customer for solutions, you'll get "faster horses". But or course that that would be silly - you aren't talking to them for solutions. You are talking to (hopefully lots of) potential customers is to understand their problems really well.
The road to startup success is littered with the bodies of companies that had a neat solution to problems nobody really cared about. Sometimes really neat technology. Still dead.
If your business approach is a solution looking for the right problem, success is going to depend a lot on timing and luck; i.e. things you cannot control.
I've always wondered how to think about this dichotomy - there are other examples besides Ford, Apple sometimes, etc. The way I've thought about it is the classic "ask what your customers want" relies on you to bring customer context and understanding to make another jump to what the underlying problem is. "faster horse" -> "get from point A to point B faster"
I think the issue there is that the users did want faster horses... the same way that asking someone what they wanted would have lead to "a bigger blackberry" instead of "an iPhone"
Identifying and understanding the core problem from the user might seem trivial for an experienced entrepreneur(who might have got burned couple of times earlier for not doing that).
But, you'd be surprised how common it is for a first time entrepreneur to not care for the problem, but to build something just because 'they can' and later find out that nobody wants it. PG has written an excellent essay on the same[1].
I've been thinking a lot about 'solving the problem of not identifying the core problem' in my work as a startup coach, which lead me to the creation of needgap[2] - A problem validation platform. Of course, creating another platform is not going to magically solve anything; my personal goal with the platform is to understand the 'language of the problems' to differentiate it with the 'ideas'.
So far, I've understood from the platform that - Identifying the core problem, is much harder than coming up with a solution aka the startup idea.
I wonder if this obsessive focus on what the customer wants from the get go causes startups to optimize to the local minima, as opposed to trying to go deep in an area and coming up with a radically new idea/technology that can then find unexpected uses. Reminds me of the quote "If I had asked people what they wanted, they would have said faster horses."
Not necessarily a bad thing, but it does seem to me there are other ways to start a company.
The second thing, and even more important, that you will discover later and YC StartupSchool didn't teach you is how to do this. People lie, are biased & don't know what they want most of they time. You will probably learn this in the hard way or probably never, but you know, it's part of the journey of every entrepreneur.
> In a London apartment, Shay Banon was looking for a job while his wife attended cooking school at Le Cordon Bleu. In his spare time, he started building a search engine for her growing list of recipes.
This incidentally is one the big reasons why diversity is so important. Often the best software is written to solve problems we ourselves are having or those close to us. If we write software for people we would otherwise not have any contact with, there are going to be severe mismatches between what is written and what is really necessary to solve the issues. This is why I am happy to see startups and teams in places that are not Silicon Valley.
Very important point but it seems like "diversity" is a taboo word on HN. For a community of intellectually curious people, that seems odd.
Diversity isn't just a code word for a political ideology. Its about the ability to encounter other perspectives, ideas and ways of seeing the world. There are so many problem spaces that we've not even begun to explore in much detail because we don't encounter them in meaningful ways.
At some point the balance will have to shift (maybe we've already reached that point). Tech entrepreneurs will have explored all of the obvious and lucrative avenues and the opportunities in the unexplored problems will seem more attractive. Maybe at this point, we'll have a bigger emphasis on discovering problems outside of our own experiences.
Or maybe I'm being overly optimistic in seeing a limit to potential for solving lucrative problems in deeply explored problem spaces. We'll perhaps always be able to create new tech products that solve the same kinds of problems for the same consumers.
Maybe, a shift in focus towards less explored problem spaces would need to be intentional. If that's the case, being open to discussing diversity well as a community surely is a sign of how seriously we're taking problems that are not our own.
If you're in the "talking with customers" phase, you should also check out "The Mom Test" by Rob Fitzpatrick.
http :// momtestbook .com (EDIT: I just noticed this is an http site... breaking up the link into pieces for now. Sill recommend Googling the book)
The tldr; is that as soon as you tell someone about your idea, it's going to bias their subsequent answers. They're going to lie to, try not to hurt your feelings, want to get rid of you, etc. So if you're trying to validate an idea, the most important rule is "Don't talk about your idea".
What "The Mom Test" recommends is to instead ask prospective users about their lives and specifically to recall individual moments when they had the problem your idea will supposedly solve. With this "unbiased" recollection, you (as the entrepreneur) have to put 2 and 2 together to figure out if people 1) really have a problem and 2) are open/looking for a solution.
I presume it refers to a one-line description of what your startup is or does. Being able to succinctly describe this is very valuable if you’re trying to convince people to buy, use, invest, be interested, &c. You might think this was obvious, but many don’t actually do it. Deciding on this helps you focus on what you reckon is important, too, so it helps you to steer aright.
Helping PhD candidates prepare to present their research, I was struck not by the frequent inability to give a succinct outreach description - I was kind of expecting that - but by how non-trivial it was to help them create one. And this was after their theses were largely done. So I'm less puzzled now by how often it's not actually done.
It's a cute anecdote, but I honestly have no idea how you would get from "my wife wants to organise her recipes" to "my wife wants a distributed multi-tenant schema-free json document full text search engine"