- User needs vs. user wants Blog

---

We're building software products and over the past years we've built quite a few of them learning progressively as you customer base grows steadily.

The biggest lesson we've learned is that it's neither easy, nor clear what is that customers are willing to buy in order to ensure product success so any reasonable investment in finding what sells is worth the effort.

Upon launching your first product we've learned that there is an intrinsic difference between user needs vs. user wants. Customers communicate their needs in the language of wants, and the two can be easily confused.

If you're lucky, as soon as you have acquired at least two customers, you may have to deal with at least three slightly different points of view on each specific requirement. Even if satisfying all user needs is therefore virtually impossible, interpreting needs wisely into sensible requirements is a key to deliver what customers are willing to pay for.

Still, early versions of your product may follow user needs quite closely if you predict user requirements correctly based on their needs, but you can never predict expectations of all your potential and future customers.

Lets imagine a product with a number of customers and a base of 10K users. This may be the total number of customers your product is going to enjoy in its lifetime, but still may be a small user base by many measures.

Conducting user studies in focus groups, or even taking into account behaviour of all 10K users can be a challenge on it's own but this specific group may just be the beginning of traction and requirements of early adopters may be conflicting with the requirements of the next 50K users that are just coming.

Early adopters are eager for new features and this is the reason they may have been interested in your product at such early stage in the first place. Their feedback, however, valuable, may be very different to what the next 50K, 100K mainstream users need.

It's therefore worthwhile building minimal viable product in order to deflect feature creep and growing scope of the product backlog, as it is extremaly hard to take back or dumb down the features you have already provided.

Following requirements of early adopters too closely could result in overly expensive product to maintain, scale, and eventually sell to the mainstream users coming soon after early adopters.

One of the technical ideas we've tried back in mid 90s was to solve the dilemma with a minimal product and a plugin architecture allowing turning features on or off, but this comes at a terrible trade off limiting product's overall functionality.

Another non technical ideas that we have deployed to tackle the problem was a feature voting system which focus group users could use to promote (or demote) certain functionalities before they were built into the product.

None of these techniques compare well against hand picking the right focus group users among potential product advocates and watching them use your product in their daily routine, predicting which use scenarios are likely to be common among other customers.