Are customers always right in building Tech products?
Ever since the switch in the approach to building software products, customers and their under-served needs have formed the foundation for how to approach a possible technology opportunity or problem that needs to be solved.
The phrase ‘the customer is always right’ has been associated with Gordon Selfridge who opened Selfridges in London in 1909. Although some people claim it was Marshall Field, it is important to note that these people both had a hand in popularizing this concept which has been misunderstood to its literal meaning, but I believe it is not about the factual beliefs of the customer, but about the wishes or desires of the customer. Therefore it is definitely not giving the customer a blank cheque to dictate what you build, but putting the customer or user who is going to use the product in perspective in building the product. For example, if electric bulbs didn’t exist and we wanted to solve a problem of darkness for a particular customer. The customer will most likely request for firewood to make fire but that just shows that the customer needs some form of illumination and a bulb solves that in a safer and long-lasting way than making a fire.
Two main learnings have formed the foundation of understanding the problem space; the customer’s under-served needs and the target customers. We know in this age, there are solutions popping up everywhere in the tech space, and as the need to build quickly intensifies, the need to satisfy the customers has also sky-rocketed because the customer, now more than ever, has so many options to choose from. As Eric Ries analyzes in his book ‘The lean startup’, There are more entrepreneurs operating today than at any previous time in history.
Customer insight forms the basis of product management and just as it is for any business, customers and their behavior towards your product validate the success or failure of the product. The lean startup idea was born out of the desire to figure out what customers want even before there is a product out there. That is, right from the idea phase.
In case you are new to the product or the tech space in general, lean is a word you will hear very often and it basically means a business that maximizes value while minimizing waste. In this article, I will try to elaborate on the importance of validating your ideas using customer insights. That is, testing your idea with potential customers to gain some insight into whether you are solving a problem for a customer, what your target market could look like, and whether your idea is a problem for this potential customer or potential target market.
Customers don’t help you create ideas:
Two very famous Entrepreneurs gave insights into their success. Henry Ford famously said: ‘If I had asked people what they wanted, they would have said a faster horse’. Steve Jobs also cited this same quote by Henry Ford in his 2008 interview with Forbes. Some people argue that these two people are evidence that user-centered design or approach to building products will not lead you to breakthrough solutions, but this is also wrong because if you build in a bubble you will neglect the customer that will use the product and end up spending excessive amounts of money trying to acquire customers later because you built something that customers don’t want. Let’s look at two examples that validate this idea.
For example, Cuil, a search engine launched in 2008 tried to rival Google. People already saw the importance of search engines, so many customers were in love with Google and that showed in their market share of over 60 percent at that time. Cuil wanted to differentiate itself by having the largest index of web pages for web searches. They claimed to have an index of 120 billion web pages which was estimated by them to be three times that of Google who at the time was their major competitor. The problem though is they didn’t validate this idea as a major problem for users. Users cared more about relevant results and fast results (This example is curled from The Lean product playbook by Dan Olsen).
The idea might be yours but the execution must be customer-driven. This essentially means you have to put the customer in mind when you are building things, like everything that has to do with risks there are high risks and low risks, the problem in technology is that there is very little benefit going with high risk because you can save money and get a large ROI by going with low risk and it means you can also be more efficient in terms of time, money and effort.
Talking To Customers is the Remedy to Product Blindness
Naturally, when you build something whether it’s just a feature or a whole product offering, you get attached to it, and because of this you most likely can’t see the flaws as you should. If a business is going to be viable and scale, it needs to reach people that know next to nothing about it and solve their problems effectively. When we don’t do this we create something called tunnel vision. You will probably build something you like, your development team will probably enjoy building it and it might even get them super excited about the possibility of getting very wealthy but that won’t happen if the first contact your target market is having of the product is at the launch.
Unnecessary inventions is one of my favorite handles on Instagram and by its tagline, you will understand that building a product people love is more than just conceiving an idea and building something with it. Though this is humor, it is the reality of many startups nowadays.
Before you test a new product idea with customers you first need to spend some time in the problem space to know who your target users are and understand the market they are in. Then, you look to solve the needs of the personas in your target market, but also you look to solve them better than those that already exist as competitors in your target market.
There are two major ways to validate your ideas with your customers when you start to create solutions: Quantitative testing and Qualitative testing.
Qualitative testing:
This hopes to answer the question, why? It is usually done with a smaller subset of users compared to qualitative testing. You want to find out why customers to the actions that they did.
Quantitative testing:
This hopes to answer the question, How? It is usually done with a larger subset of users and you really want to see how many times they perform a certain action.
