Should I ask my customers if they would use a feature before building it?
7 comments
Its not a good idea to ask users about features because users are not good at identifying the next features of your product. Instead the questions should be
1) What is the hardest part [about doing this thing]? (Identifies the pain-point of customer)
2) Tell me about the last time you encountered this problem? (Identifies the context of user's problem)
3) Why was that hard? (Identifies the specifics of the problem)
4) What have you done to solve this problem? (Identifies if user is already exploring the potential solution to that problem)
5)What dont you love about the solution that you have tried? (This is the exact question about the features but just in more efficient way)
All of the above questions are summary from YC partner Eric Migicovsky's youtube video on "How to Talk to Users". Its a great informative video.
1) What is the hardest part [about doing this thing]? (Identifies the pain-point of customer)
2) Tell me about the last time you encountered this problem? (Identifies the context of user's problem)
3) Why was that hard? (Identifies the specifics of the problem)
4) What have you done to solve this problem? (Identifies if user is already exploring the potential solution to that problem)
5)What dont you love about the solution that you have tried? (This is the exact question about the features but just in more efficient way)
All of the above questions are summary from YC partner Eric Migicovsky's youtube video on "How to Talk to Users". Its a great informative video.
Here's a link to the video: https://www.youtube.com/watch?v=MT4Ig2uqjTc
Thanks, i'll check it out.
Thanks, i'll check it out.
My experience matches yours: users will say yes as long as they don't have to pay for it and don't have to alter their existing workflow. In other words, no.
Eliciting what users actually want is very hard. The best way is to actually be one yourself. A distant second is to spend time with them, watching their work flow.
A distant third behind that is trying to imagine yourself into their place, reading up on their jobs, learning their tools and environment, learning who their customers/clients are and what they want, etc. That's not great, but it's better than trying to elicit the same information with a brief question about what they want.
The better you get to know the users, the better you'll be at providing their needs. That turns out to dominate the job of most professional developers. The actual "computer sciency" part of the job is less than half of it.
Eliciting what users actually want is very hard. The best way is to actually be one yourself. A distant second is to spend time with them, watching their work flow.
A distant third behind that is trying to imagine yourself into their place, reading up on their jobs, learning their tools and environment, learning who their customers/clients are and what they want, etc. That's not great, but it's better than trying to elicit the same information with a brief question about what they want.
The better you get to know the users, the better you'll be at providing their needs. That turns out to dominate the job of most professional developers. The actual "computer sciency" part of the job is less than half of it.
Ask users if they're willing to pay extra for the feature. For example, say "We're thinking of adding this feature and increasing the cost by $2/month. Would you like this?". Then if enough people say yes, build it and don't increase the cost (unless you want to). Might build you some goodwill too.
Just an idea, never seen this in practice.
Just an idea, never seen this in practice.
Ah crap I had a long reply but hit refresh on mobile and lost it..
Long story short, we did this with great success. Instead of a feature we made a separate app that people actually pay for more than the main app.
It is a "shut up and take my money" kind of thing, and being a small business, that is the only type of development we could justify working on.
We had many other ideas which we discussed one way or another with customers, but none got that "I need it now and here's a cheque" reaction.
Long story short, we did this with great success. Instead of a feature we made a separate app that people actually pay for more than the main app.
It is a "shut up and take my money" kind of thing, and being a small business, that is the only type of development we could justify working on.
We had many other ideas which we discussed one way or another with customers, but none got that "I need it now and here's a cheque" reaction.
In my experience, when people are ready to pay for something, you might as well just sell it. Giving it free sometimes adds doubts - will it be maintained? Is it an experiment? Is it a budget version of what you promised? Will they "owe" you one?
I'm happy to just pay for things because it "closes" a transaction. Where I live, we even have this tradition that the buyer says "I agree to buy" and the seller says "I agree to sell". A receipt is an abstraction of this process, but here, it's normal for someone to respond "I buy" when emailed a reciept.
I'm happy to just pay for things because it "closes" a transaction. Where I live, we even have this tradition that the buyer says "I agree to buy" and the seller says "I agree to sell". A receipt is an abstraction of this process, but here, it's normal for someone to respond "I buy" when emailed a reciept.
I like this version of the same question - it's like a mini commitment.
If you're looking for feature ideas, and if you have decent user analytics, I would seek ideas from users who have changed their engagement with your product for the worse. If you solicit suggestions from someone who's cut their time with your product, or who uses it in fits and starts, you might get some pointed suggestions.
Agree with this. Ask the users who have stuck around with your product the longest. Their opinions are more valuable and insightful.
I think you should ask them questions that will elicit the exact information you’re trying to get. So for example, like bhargav1195 said, asking questions like “what have you typically done to do xyz (i.e. the goal you want the feature to achieve)?”, “what’s been the most difficult part for you when you’re trying to accomplish xyz?” etc. Those will give you better information to work with because users don’t always know what they want. You find what they truly need hidden in between the lines.
briefcomment’s suggestion also sounds good but I’d be curious to see how that works out if you ever try it out because I don’t think I’ve seen it in practice either
briefcomment’s suggestion also sounds good but I’d be curious to see how that works out if you ever try it out because I don’t think I’ve seen it in practice either
Great question, and I just recently watched the video bhargav1195 suggested. Watching it will be well worth your time.
Side note: As much as I'd love for "table steaks" to be the parlance for minimum entry requirements, the correct term is "table stakes".
https://en.wikipedia.org/wiki/Table_stakes
Side note: As much as I'd love for "table steaks" to be the parlance for minimum entry requirements, the correct term is "table stakes".
https://en.wikipedia.org/wiki/Table_stakes
Wow, I never knew that.
We use lots and lots of customer calls and interviews to get opinions on new features. It's a great idea, and it helps a ton.
Yes.
Obviously this is very contextual, for instance a group of users digging holes with their hands will most definitely use a shovel. What I'm talking more about are features that maybe a competitor has, or a feature that is usually considered "table steaks".
Curious what HN has to say about this.