Listen to Your Customers, They’ll Tell You What to Build | Hacker News Reader

Listen to Your Customers, They’ll Tell You What to Build

blog.tailwindapp.com

189 pointschinedufn82 comments

I agree that doing more listening than speaking when talking to customers is important.

It's also important to remember that customers will tell you they want features they they won't actually use or pay for. So it's necessary to develop an understanding of what your customers do and what problems they're trying to solve.

This often helps more than just listening to features they say they want. If your customers aren't in the business of building products (especially software products), their ability to ask for features is limited by the fact that if you're not an expert in how the product is created, it is difficult or impossible to know what features might be easy to add, and which ones are difficult.

It's even likely that you can add features that your customers that your customers don't even know are possible. In this case, they won't be able to ask for those features, or anything like them. As an expert (in software, or any other specialized product development field), taking the time to really understand your customers, the problems they face, and the jobs they are trying to accomplish can help you come up with new features and products that actually amaze your your customers and attract new ones.

Great points! Being willing to listen is step 1. That's the product culture that needs to exist first and foremost. Completely agree with you: knowing what to do with the feedback you receive, and how to interpret it in order to innovate and solve real problems is the key that I firmly believe drives the ultimate success of a product. That's a product development/design problem that's alluded to in the middle of the article, but hard to really do it justice in a few small blurbs. Feels like a good topic to be the subject of its own stand-alone post as a follow-up to this one :)

"Part 2: Listen to Your Customers, but Don't Do Everything They Say" haha.

Ha, sounds like a good part 2 to me! :)

As you pointed out, you did allude to it in the article. I was just trying to add a bit more based on first hand experience with software customers.

And hey, sometimes customers will just flat out tell you that they need a feature that is blindingly obvious to them, but didn't occur to your product development team. It's nice when it is that easy.

So I agree that the knowing how to interpret what your customers say is and important part of being able to act on what they share with you. That certainly doesn't diminish the importance of anything you wrote, though. Without engaging with customers and properly listening to them, there wouldn't be any information to interpret.

It's great feedback.

Here's what Alex (atopiler) Slacked me yesterday after he read the article in draft "One thing that I felt didn’t really come through fully was some of the true essence of cust-dev calls. This is the product snob in me talking, but it felt a bit like we're listening to what our customers wish for, and we build what they tell us to build. When it comes down to it though, what the calls really reveal, and what we’re really trying to understand more deeply than anything else is what are biggest problems and frustrations they’re dealing with on a day-to-day basis? Why are these things frustrating? Why do they put themselves through that frustration? And what would it enable them to do if those problems didn’t exist?"

And that became that middle section.

Thanks to all of these comments I'm seeing the light of what he was really getting at there and I've salted the headline and some of the earlier passages to set that up a little better.

p.s. this is my intro to HackerNews - you guys are awesome.

Absolutely - huge thanks for reading and for the thoughtful replies!

I agree with most of your points.

I would add that when you put a person in a position that you have asked them for input, they will feel pressured to give SOME kind of input, whether or not it is actually warranted. You're kind of setting them up to give input in the same way you might set someone up to tell a joke, they feel pressured to fill that space with SOMETHING.

Most of the time when I have built features that came from customers, it ends up being the least used feature of a particular update cycle. Sometimes to the point that we have to reverse or highly modify it later. The reason your customer isn't in the business of making the thing you're making, is because they have no idea how to make that thing.

If you ask a person what they want out of a new Ford car, they are not going to say "Brake pads with a higher durability for longer use," they are going to say "More cupholders wouldn't hurt, and maybe you could offer it in magenta?"

See also "The Bike Shed Problem": http://bikeshed.org/

Or, The Homer. http://vignette4.wikia.nocookie.net/simpsons/images/0/05/The... https://www.wired.com/2014/07/homer-simpson-car/

Instead, you need to ask your customer about what they are doing in areas around your software. Not "What would you like in a new car?" but "What have you been doing in your car?" and "How much maintenance do you have to do?" and "What's the worst thing about the stuff you do in the car?"

Then maybe you can find out that the brakes make a squealing sound because they are mis-adjusted and are wearing out the pads too early.

"When people tell you something is wrong, they are most often right. When they tell you how to fix it, they are always wrong" ~ Neil Gaiman

Things may have changed since I got out of website building but my customers were usualy focussed on what they wanted their customers to see.

They very rarely had any idea about what they wanted to see behind the curtains.

There can be counterexamples to that advice. Maybe since Tailwind is in the B2B space, this affects their bias of the recommendation.

If you're in the Enterprise/SaaS/B2B space, it seems more common to closely track what your (paying) customers want.

However, if you're in B2C or mass market, there are successful examples of being bold with providing something your customers didn't ask for. An example is the Facebook "newsfeed" feature rollout in 2006.[1] They initially had a user revolt over it but Mark Z and his team stuck to their guns and sure enough, the newsfeed became addictive and contributed to the envious engagement metrics that Myspace/Friendster couldn't match.

It's the modern variation of Ford's apocryphal "if I had asked people what they wanted, they would have said faster horses."

But that doesn't mean all counter-intuitive decisions by businesses always make sense. Steve Jobs removing the floppy drive on iMac met disapprovals and eventually was vindicated by fast USB adoption ... but the jury is still out on removing the headphone jack from the iPhone 7.

Setting aside the missteps by Apple, a creative startup could identify with Steve Jobs saying, "customer's don't know what they want until we've shown them."

[1] https://techcrunch.com/2006/09/06/facebook-users-revolt-face...

> It's the modern variation of Ford's apocryphal "if I had asked people what they wanted, they would have said faster horses."

This x100 times. After building several B2B products I've found that the most successful features are the ones the customers weren't expecting and didn't ask for...

It's ok to do customer development in order to track what your users want and at least cover their expectations, but you'll never create amazing products with this mentality...

Relevant: "Obvious to you. Amazing to others."

https://sivers.org/obvious

"You'll never create amazing products with this mentality..."

I think that this kinda misses the point. If you're only building the things they explicitly ask for, then yes, you're right. However, customer development isn't mean to track what your users want and cover their expectations; it's to uncover the biggest pain points/real problems to come up with amazing solutions for - what's actually _worth_ pursuing and potentially building? How exactly those solutions manifest themselves often times does not come directly from customers, but the amazing ones are just as often inspired by insights gleaned from customer development.

The article you shared actually backs up my point exactly. Example: what could be obvious to one of your customers can end up being amazing to you and your other customers. In practice, I've found this dynamic play out time and time again.

The Atari Lynx wasn't massive because it needed to be; the creators listened to their customers:

"In all the focus group testing, and we did a lot of it with consumers, we had a bunch of different models that we showed them," Mical recalled in an interview with 1UP.com. "[We asked] "which one do you like? Which one would you like to have it be?" We showed them big ones; we showed them little ones. We showed them gigantic ones; we showed them little tiny ones. They loved the big ones. They all told us, 'Make it big. Make it big. This one feels like it's substantial and I'm really getting my money's worth.' They all told us to make it big, so we made it big. And when it came out on the market, they all said, 'Why is this damn thing so big?' It'd drive me nuts, because the original Lynx was mostly air space inside. We put it in, because that's what they told us they wanted."

http://www.usgamer.net/articles/too-good-for-its-day-ataris-...

Focus groups are absolutely the worst way of getting product insights. Unless they are extremely well run to counterbalance a huge number of cognitive biases and random influences within the group, don't do them. They can be worse than useless.

Yep, and in addition to not knowing what they want (at least sometimes), customers also don't generally have a detailed understanding of the costs associated with building new features. It's easy to say "I want X" if you're not the one who has to build it, integrate it into an existing platform, support it, etc.

Also, "customers" are not a monolithic group. Some will try to pull you in one direction, and others will want you to go the opposite way. You'll go crazy trying to please all of them. Just saying "listen to your customers; they'll tell you what to build" is a massive oversimplification.

At the end of the day, customer feedback can be very valuable, but only as a starting point. You have to internally decide which of the things, if any, you actually want to build.

But if you wrote a blog post that said: "listen to your customers and consider building what they ask for", it would sound obvious (because it is) and wouldn't drive any clicks.

> There can be counterexamples to that advice.

Welton's law of startup advice: for each trite bit of advice, there is an equal and opposite bit of trite advice.

Hi - UX designer here. So shoot me.

Firstly, you might consider that close to all basic ideas behind objectively successful products (eg the telephone, Facebook, photo copiers, Twitter, rabbit vibrators) were NOT arrived at by asking the target audience what they wanted. Most were intuition born of observing that audience.

When you ask people direct questions about what they want, it takes a great deal skill and judgement to actually get a successful product idea from that. In fact it's almost not worth the bother, and few professional designers really do it very often by choice. Far better to try to observe what people do (often by giving them tasks to complete in some sphere of activity) and see what comes out of that. You might see your target audience performing needless operations, misunderstanding things, or doing things that appear irrational to you but rational to them. Once you see that sort of thing happening, it's far easier then to see what they might need or really want.

I wouldn't go so far to say that asking people what they want is a bad idea, but it's getting close. Perhaps it's a mildly toxic idea best avoided in preference to observation.

I should add that the key to this, also mentioned also in the article, is frequency. Observe often. Over time, you can then build hypotheses (which you can then also test out if you want). To use a crass example, Steve Jobs was anecdotally very driven by hypothesis. This (perhaps accidentally) let him to stick to his guns in design decisions because he was able to say things like, "I believe people want visually desirable computers in their homes, not overtly functional ones".

Users are a source for problems, not solutions, that's the designer's job. However, the most common way that users articulate problems is in the form of solutions. It's then the designer's job to reverse engineer what the problem is from the proposed solution and design a solution that both fixes the problem and is contextually appropriate to the rest of the product.

So when you listen to users and they tell you "you should do X", just blindly doing X is a path to failure but similarly ignoring them is also a path to failure.

There's an art to properly eliciting insight from users and it's a mix of observation, interrogation and thought. In general, the best advice I've found is focus on the emotional and not the logical. When you ask when was the last time you had a problem with our product, you force the user to come up with ad-hoc logical arguments and paradigms that are most often wrong. If you ask when was the last time you were frustrated or annoyed with our product, you hone in much more reliably on real sticking points.

I am a product manager at one of those big tech companies.

This is exactly right and IMO one of the most important skills a PM should have.

One of my teachers used to express this succinctly the following way -

Imagine a patient going to a doctor and asking a course of antibiotics. Any doctor would erase that request and start asking the patient to describe their problem. This, he said, is the core of how a user feedback conversation should go.

I think that the key questions are not what you want or what you want to have but rather what you want to do or even more importantly what you want to accomplish.

Of course in addition UX designers do have their own demons to fight. I would call one of them as cosmic expansion of the space, that is - contrast will decrease and distance between meaningful UI elements will increase over the time.

I built my business by listening to customers. Do I discount a bunch of ideas that come my way? Absolutely.

But over over time you begin to develop a filter that separates really good ideas and mediocre ideas that serve a single or rare use case.

Observing is great if you have the bandwidth, but if you're a one-person-show, listen to your customers, listen to your instinct, and develop features that are going to drive revenue and push you forward.

As a UX designer do you use heatmaps as a tool to determine if your audience is taking the actions that you expect them to take?

No, because heatmaps only tell you what is happening, not why.

And even then they can be telling you nothing at all because you don't know things like user intent. Harry Brignull's summary of the issues on this is required reading here (about eye tracking but applies to all such heat mapping tools):

http://www.slideshare.net/harrybr/what-you-need-to-know-abou...

Thanks for this. Great information.

How do you determine why something is happening?

Largely through hypothesis which you then test. Eg you might see a lot of people abandoning your cart. You might guess (perhaps based on some or other evidence, but it can be a straight guess) that this is because the final price isn't prominent enough on the page. So you to test that you make the price bigger. And if the abandonment goes down then that's ONE data point in support of your hypothesis. You should then re-rest the idea in a different way to make sure, for example by moving the price to a different place on the screen such that it achieves more prominence. And it if abandonment goes down further then you have TWO supporting tests. But abandonment might go up, so you need to then re-evaluate your hypothesis (eg maybe it's some notion of apparent "honesty" you need to confer, not visual prominence).

This is the work of the UX designer. It takes time an effort. PMs usually don't have the time or understanding to do it properly, so products and companies often suffer. This is why, personally, I would be more inclined to invest in companies that have actual UX designers working for them than mere jack-of-all PMs. But hey.

Agreed, When conducting user feedback we always try to identify what the users frustrations are and then our team will work on coming up with solutions based off our findings.

Working as a designer, I've come to appreciate a lot of the ideas in Non Violent Communication. This is more or less the central idea of NVC: needs are very low level and highly likely to be shared by many people, whereas the strategies used to fulfil those needs are much more specialized and particular to a person or a small number of people.

People will communicate and confront you with their strategies for fulfilling the need they have rather than communicating the need itself.

Learning to "listen for needs" is not only valuable for conflict resolution, but also for service development.

This is very true. I'm going to read the NVC book after reading your comment.

Similarly, I've found that users often express all sorts of suggestions for how to accomplish some need they have. While many of their ideas are (from a UX/design standpoint) horrible, the core need is valid and often highlight something important that has been misunderstood or overlooked by the design.

The hardest people to get "needs" information from are intelligent, computer-literate people, who are often unwilling to admit that they find something counter-intuitive, and often frame their feedback in a way that conceals that fact... But who will end up not using something because of the friction that a suboptimal design causes.

I've also found it helpful to let people draw mocks of their solutions with a sharpie and to also share my own impromptu sharpie mocks with them based on their feedback.

At the very least, this process makes them feel respected and lower their guard which can often help them share information that is helpful in designing a product.

The craziest moments are when it turns out after weeks of trying to understand a user's feedback, that the user simply wanted a report view of some information and was trying to give feedback to make an interaction design turn into a report. This is quite common, especially in a feedback group where the highest status person is the manager who does actually need a report but is offering general feedback on general usability.

That's a fantastic analogy!

This is both true and dangerous advice.

You must listen to your customers, but then you must conceptualize their needs, prioritize them, and think about how to solve those needs well.

There is nothing worse than a "Christmas tree product" where every customer has hung some requirement and there is no conceptual unity or design. Loads of "enterprise" products are hairballs like this.

TL;DR: It's not listen -> implement. It's listen -> THINK -> implement.

Couldn't agree more. Very very well said.

Sometimes there can be value in doing rapid shallow MVP type iteration with key customers, but there should ideally be a step between that and stuff going into the mainline product where somebody thinks.

Yup. To be blunt, customers often don't know what they need. Often they don't even know what their real problems are.

But they know what their pain points are, and a good BA or Product Manager/Owner will know how to dig into those pain points and unearth the real problems that need solving, and how best to go about solving them.

Most people will read this title as, "Build what your customers tell you to build." The key here is that most customers will be happy to tell you they want all kinds of features and the best/only solution or feature looks like X. You have to go deeper. You have to listen to understand what they actually need.

I hate being that guy that trots out a quote from a historic figure, but c'mon, this is a slam dunk:

"If I had asked people what they wanted, they would have said faster horses."

Boom shakalaka! Perfect quote.

Which is what they got, from a certain point of view.

> I hate being that guy that trots out a quote from a historic figure...

Don't worry, it was a made up quote. You're safe.

1) I can't believe I missed the "trot out" pun in my original comment.

2) Anyone who's interested to read more on this made-up quote should see this HBR article:

https://hbr.org/2011/08/henry-ford-never-said-the-fast

Great example of this is from a music software from Propellerheads. Everyone was complained about the bulky, sluggish file browser. It stayed like that for a few versions, but then they reinvented the whole file browsing experience instead of doing the easy solution of just making it simply faster.

http://www.tamingdata.com/wp-content/uploads/2010/07/tree-sw...

The signal to noise ratio tends to be poor though. So many will insist and swear and beg and threaten about what they think they need, or what they used to do, or what they won't pay for but would like to have if it's free and maintained indefinitely. There's often a background noise of "all change is bad" and some improvements are not as clear as helicopter vs rush hour traffic, so the benefit will take time to appreciate.

The trick, of course - and rather old news - is reading between the lines and not becoming arrogant in response to the lower quality feedback. You probably don't know better than them AND they probably don't know what they want.

Very true. The helicopter vs. rush hour example is kind of like finding the holy grail, and that's what you strive for. In practice, the majority the improvements you can extract from these conversations end up being much smaller. But many small improvements compound and also help create the invaluable customer feeling of "Hey, I feel like the team behind this product really gets me!"

Also, well put: "You probably don't know better than them AND they probably don't know what they want."

Great point about the signal to noise ratio. One interesting thing there is how the ratios differ between a mostly emotional experience (a new social platform for example) vs.. say.. a product that helps the user make more money (most B2B). You'll often have much less noise when all of your users want roughly the same specific thing. But, like you said, there's definitely still a bunch of noise.

For sure it gets a lot worse if you have multiple different groups saying different things and you don't know which are the most important or profitable.

This is true. And the bigger a company is the more there is to trawl through.

Still, you get stuff like this 14 page thread dating back two years asking Dropbox to stop forcing new folders to automatically sync[1], or this 10 page thread spanning 3½ years where adding an external email to hotmail/outlook.com was broken[2]. Never any official response, just moderators posting form responses like robots. Those are where I feel things have gotten a bit ridiculous, when the company stops ever interacting with the customers at all.

[1] https://www.dropboxforum.com/t5/Dropbox/Stop-auto-inheriting...

[2] https://answers.microsoft.com/en-us/outlook_com/forum/oemail...

Oh my god I can't stand moderator responses. Worse when they're just copy+paste and they didn't even read your request/question. Been happening on Github more and more too with issues.

Sounds like you're having some trouble with forum moderators.

To allow me to fully assist with your issue, can you please make sure you've completed the following steps:

- Restart your PC.

- Copy down any annoying messages from moderators that you see.

- Try reading the messages again to see if you feel better about them now.

If this message was helpful, please remember to upvote and mark as SOLVED.

   You can't just ask customers what they want and then try to give that to them. 
   By the time you get it built, they'll want something new.

-- Steve Jobs (The Entrepreneur of the Decade, Inc Magazine, April 1989, http://www.inc.com/magazine/19890401/5602.html)

If Apple did that than they would been out of business 25 years ago.. Steve Jobs did not ask Apple customers what to build but predicted what in the future apple should build to get more customers.

This is not to say that customer feedback is not important but to clarify that it pertains to very short-term marketing in that it only refers to somewhat minor-point increments in fine-tuning the current product.

I have to whole-heartedly disagree with this. Customer development and feedback don't just apply to short-term marketing and minor-point improvements. That couldn't be further from the truth.

The "They'll tell you what to build" isn't meant to be taken literally. If you listen and try to truly understand people's problems, they'll guide you towards the most useful solutions. Coming up with those solutions is still up to you in most cases, though.

Re: Apple - they understood the real problems that their potential customers had. No, customers didn't come and tell them to go and build a device like the iPhone. However, from understanding the market and the pain points that people had with mobile phones, Apple was able to identify an opportunity to enter a new market and disrupt it.

> However, from understanding the market and the pain points that people had with mobile phones...

Any reference on this?

Actually, I'd suggest people did tell them to build the iPhone, and the iPod.

They looked at the problems with the MP3 market at the time, tiny devices with poor user-interfaces and their solution to the state of the market at the time was the iPod. Unexpected from Apple which was only a computer company at the time.

Once we had our iPods we were carrying around an iPod and a phone (Blackberry was huge at the time). They understood customers wanted a single device, it had to have great messaging like a blackberry, and do all the music and video needs of an iPod of that era. Blackberry had apps, a web-browser, maps, etc. It's important not to forget that. Apple did a better job with the browser and gave the thing a full-size touch screen. Customers didn't ask for that, but they had asked for the basic device. Apple took what was asked for and put their own scrutiny to it to see just how amazing they could make it.

I was watching Seinfeld recently. It was a 90s skit of him talking about the answering machine. How sometimes you would be disappointed if someone answered the phone.

I was thinking, wow, he is just talking sending sms messages. The crowd would laugh or woot in what seemed to be agreement.

He didn't know what he wanted, but there was a problem that he and everyone wanted a solution for. At the time in the 90s, it was a social problem (not wanting to waste time with an annoying person on the phone) but in the 2000's that problem was solved with technology.

A lot of times, customers do not know what they want. Imagine what Jerry's answer would have been if we had asked him a question about pinging his contacts list to know if they were available in 1991. He wouldn't have understood and honestly, no one would want to carry around a massive rolodex at the time, so the answer would have been silly at best.

I did find the video .. someone else noticed the same thing. https://www.youtube.com/watch?v=8UeINnBMFA4

I've been doing lots of customer interviews lately, and I'm absolutely loving it. I think this bit of advice from the article is dead wrong "know exactly who you want to talk to and what you want to know".

I've got a product that is growing nicely and that users love, but we haven't been able to monetize it yet. Lots of other comments point to things like Ford's (misattributed) "they'd say I want a faster horse".

Don't ask people directly what they want, find out what they are doing, what they need to do, and you'll start to find a pattern emerge.

The reason I feel you can't know what you want to find out or discuss is that you can miss exactly what the customer is telling you.

In my experience, I will often ask pointed questions about what more we can do, and I get blank stares and uses just say "it's great" and give me requests for minor improvements. When I probe them about other parts of their business, they open up about what they are doing in other segments which to them are completely different than what we do, but when I point out the similarity, and what we could do in these other areas to help them out, they perk right up and come up with a bunch of good ideas that they are happy to pay for.

So be flexible, and look for patterns more than answers. I'd also suggest, if you're in the same place as I am looking to monetize an existing product that most see as free, ask where they are spending money and see if there is opportunity for those funds to be re-allocated to you.

The thin font is super unreadable on my Galaxy S4.

Same here, one plus one.

I read an amazing book on customer development: The Mom Test by Rob Fitzpatrick - https://www.amazon.com/Mom-Test-customers-business-everyone/...

The first few pages blew my mind. It was a great read all the way through.

Having read several customer development books, I second that recommendation.

One of the main takeaways of the book is that you should always start by asking factual questions. What do you do. What software do you use to do that. When's the last time you did that. How did you feel about it. Etc.

No "What ifs", no "would yous." Don't ask how much they would pay if [you could code whatever feature by next week].

That may seem obvious, but most people go for the second type of question right away.

I think there needs to be a certain separation between the artist and the customer, in the sense that the customer says what they want, but how you get there is part of the artistry.

For example, Michelangelo was told to paint certain things, but it's how he did it that made him legend.

The real beauty, the real success of a thing, lies in the how, not necessarily the what.

Agree 100%. Great analogy.

> Listen to Your Customers, They’ll Tell You What to Build

It's 1901. I want a horse and buggy that can go 55 mph.

Ultimately somebody involved has to make the decision of what is needed. The customer often doesn't know exactly what they need and even more often does not know what is realistic. The developer often doesn't understand the problem(s) and even more often has little idea of why the customer is doing what they are doing.

There really is no substitute for having someone (or a team) study the area in detail who has the background to be able to understand the problem(s) and is able to translate this understanding into a development plan. For anything but the most trivial problems this requires a large investment in time, money and effort.

Interesting, I am wondering whether Apple listened to its customers or not when they firstly built iPod, iPhone and iPad...

One thing is listening and acting based on what you understood, which you should definitely be doing. This requires product planning and thinking, as any you've ever done.

Just blindly doing what your customers tell you is not what you should be doing, it's just design by committee on a massive scale.

IMO, this is trivial advice. It is obvious to sell people things they tell you to sell to them.

True business acumen comes from understanding two things that are not as obvious:

1. A customer often does Not Know what he wants.

2. What a man wants is malleable and can be shaped and influenced by forces created by other men.

They'll tell you what they like, but not always what you should do about it.

> If I had asked people what they wanted, they would have said faster horses

Imagine the frankenlaptop the Mac would be if Apple ever listened to its customers? CD-ROM , touch screen, fm radio, infrared whatevs

And you'll get faster horses all around.

This the difference of listening to what your customers literally say and being able to deduce what it is what they need.

"I want faster (or better) horses". Needs a follow up question or ability to understand the deeper core meaning. From the above quote. These are some off top of head self distilled thoughts on what that means

I want to get from point a to b faster. (faster vehicle or teleportation.)

I want less time traveling.

I want less prep time for traveling(E. G. Saddling horse).

I don't want to take care of my means f transportation (offer a stable service or offer non animal vehicle)

I want my destination closer.(urban)

I don't want to go to the store to buy X. (delivery service. Ala amazon?)

I want faster Internet vs I want to reach my final destination faster are similar but different outcomes.

Would you rather have Google load pages 100x faster or have above 99% chance to guess the site you really wanted/needed.

Amazing! That is the true essence of customer development.

When you walk into a hardware store and ask for a 2-inch drill bit, it's not the tool you really want. What you really want is a 2-inch hole in the wall.

> I want less prep time for traveling(E. G. Saddling horse).

Years ago I saw an interview with a Sami. 'Why snowmobile instead of reigndeer?' 'I don't have to spend half an hour chasing down my snowmobile.'

What if you don't have any customers?

Then ignore the stupid advice in the title and likely article (I just skimmed but only saw noise) and instead of listening to anyone else, build something amazingly great. Seriously, build something amazing and then tell people about it.

Nobody is going to tell you how to do it. it has to come from you.

Super interesting perspective here :) Question - in this no-customer scenario what's the downside of trying to solicit feedback from others while you go along?

"imagine if I made a night-sky, but, like, out of swirls"

-Vincent Van Gogh, hypothetical

Starry Night (Value: est. ~$80M-$100M+)

Vincent Van Gogh, Actual

The point is to talk to people to know whether something you want to build is actually going to be great before you go and build it. Most of the time when people go and build what they think is "great" they end up realizing that nobody actually cares. It's a sure-fire way to waste a ton of time of money, which for startups, are the two scarcest resources you have.

this actually isn't bad advice for idiots. so if you're an idiot, by all means it's probably better to ask someone, "how'd you like it if" rather than build it and see. As a great example, everyone knows people like battery life. So if you're an idiot, a great question to ask your customers might be, 'How'd you like it if we made a giant battery, like a car battery, that you can take along as an external battery booster for your next Samsung, so that you can just have it connected and have 72 days of life. It would be deep discharge, so that you have hundreds or thousands of cycles." Why did I use this example? Because only an idiot would ask any customers this. It's idiotic. But if you're the kind of idiot who would make that - then by all means! ask them.

On the other hand, steve jobs didn't need to ask his customers how they'd like an iphone - he told them why they'll like it.

Would recommend you check out "The entrepreneurs guide to customer development"!

Customer Development is a process that's really meant to be applied to prospective customers. The whole point is to figure out what problems the market needs, and ultimately what kind of solutions there might actually be a market for.

Instead of building something and then going to people and asking if it's useful, find out what a large segment of the market would find useful first.

Get out of the building and talk to actual people - create simple experiments to help you prove whether a market actually exists. Validate your assumptions before building. Follow the Lean Startup methodology :)

"Premature optimization is the root of all evil" -- Knuth

Reply on news.ycombinator.com