Building What Customers Need: The Ultimate Recipe
According to Clayton Christensen, a professor at Harvard Business School, nearly 30,000 new products are introduced each year, and 95% fail. Though this number is more related to physical products, it only takes a little effort to realize this is true for digital products. And this is a terrifying and disturbing thought because startups and entrepreneurs invest tons of money to build these products. This brings us to an important question that every product manager and the associated tech teams ask themselves every time they dip their feet in the river of building digital products. Why do products fail, and what can the teams do to build products that customers need?
A few days back, I was chatting with a product manager at one of the biggest software companies of our time. He has been leading multiple teams for over two years now. The most exciting part of his experience is that he has conducted more than 50 experiments within these two years. And these have helped his team to understand what to build and, more importantly, what not to build for the customers. While chatting with him, I understood that these experiments were expensive in terms of capital and time. So even deciding what experiments to perform was tricky since the team needed to justify the capital they needed to perform the experiments.
Unfortunately, only a few companies have this much bandwidth and capital to experiment. And hence its extremely important to understand what customers need and build the products accordingly. But before we dive into how to build products that customers need, it’s essential to understand why companies fail to do so.
Reasons Why Companies Fail To Build Products Customers Need
- Solving The Wrong Problem
Understanding the problem is the first step to efficiently building the right solution for the customers. In one such instance, recalls the product manager of the social media company, the internal users of his product came up to him and said they wanted to use machine learning for automating some part of manual activity. Although machine learning (ML) and artificial intelligence (AI) are buzzwords in today’s tech industry and some very solid products have been built using ML. But, in most cases, ML and AI aren’t necessary and might consume more resources.
Upon investigation, it turned out that automation was possible just by tweaking the systems. And the problem wasn’t to use “ML” to automate certain tasks, but it was to automate certain tasks mainly because they were time-consuming. In fact, upon more profound research, it turned out that this automation wasn’t necessary at all. This was possible because the product manager invested time understanding and defining the problem. And this is why it’s imperative to understand the problem at deeper levels so the team/company can find the right problem to solve. This is the first and foremost step, and most of the products fail at this step itself.
- Aiming For The Perfect Solution
Whenever a team/company tackles a problem and builds a solution for it, most of the time, it’s easy to fall into the pothole of building a perfect solution. This is extremely risky because the team/company misses out on the timing and risks spending time on a solution that the users might not need when it’s rolled out.
Something similar happened with the product manager with whom I had a chat. He was involved in building a product that would completely replace the current content management system for around 600 internal users. The initial period to build this system was 12 months. But as and when the engineering team started working on the solution, they came across multiple corner cases. This increased the timeline from 12 months to 18 months. When the users learned about this, they started questioning the entire content management system. Their point was that if it took this long to build the whole system, it would take similar, more extended periods to build new features in the future. So, they kept pushing for more features to be added to the scope.
All this happened because the tech teams were waiting to build and launch the best solution. The product manager shared that instead of this, they should have divided the content management system into more prioritized minor features and released them iteratively instead of one big-bang system release. Fortunately, the risk of releasing this way was lower since the system was meant for internal users, but this could have been a bigger problem if the users were external.
- Not Getting Early Feedback
This probably sounds very straightforward, but asking for feedback from the users later in the product development stage is a blunder. User feedback is one of the most robust methods to build the right product. Without regularly checking with them, it isn’t easy to guess what they are looking for. Your best defense against the enormous amounts of spending money and wasting the team’s bandwidth is touch-basing with the users frequently, showing them your features, proactively gathering feedback, and validating every new iteration of your product to understand better which product features add the most value for your end-users. The product manager shared one of his favorite examples.
On June 30, 1970, AT&T uncloaked its commercial Picturephone service in the city of Pittsburgh, Pennsylvania. Blinded by its own vision, the company’s executives ignored the negative feedback the company got in the testing phase. They believed that a million units would be in use within ten years of launch. Much to their surprise, they pulled it off the market in just three years due to a lack of consumer interest. Why?
During the trial phase, the users shared their feedback. They found the equipment too bulky, the screen too small, and expensive. But all this was ignored, leading to the entire product failure.
Getting feedback early on and working on it will help you build the right solution for your customers’ problems.
Building Products Customers Need
- Working Backward Approach
Dr. Werner Vogels, CTO of Amazon.com, wrote an article about Amazon’s working backward approach in 2006. And even though this was written 18 years back, the method is still very relevant and is being used by companies worldwide to reduce the risk of building the wrong product and understand customer needs right at the start of the project. The method mainly focuses on writing a press release (PR). The primary author of the PR is a product manager who writes the document and leads the successive iterations. A PR has the following parts -
- Heading — This should ideally be the name of the product and essentially tell what the product is about
- Subheading — The core benefit of the product
- Summary — Summarize what the product does along with its main benefit
- Problem — Specific problem this product solves
- Solution — In what way the product solves the problem
- Quote from you — Create a fictional spokesperson and ask for a one-liner explaining why this product is a must-have.
- How to get started — Explain how to use the product the easiest way possible.
- Closing and call to action — End the press release by letting the reader know how to find out more or start using the product.
The product manager I chatted with shared that this has been the single most effective method to build products that customers need. He has used this to build all of the products during this tenure of 2 years. Mainly because even before building the product, all the stakeholders, including design, engineering, users, marketing, and sales, give feedback on this PR. And so till the time the tech teams start building the product, everyone is sure that the customers are indeed interested in using the product.
- Design Sprint
A design sprint is a methodology introduced by Google to test ideas quickly in 5 days by rapid prototyping. It saves four to six weeks of development time by aligning teams under a shared vision with clearly defined goals, deliverables, and validated solutions. The best part of a design sprint is that it involves the users, engineering, design, and all other relevant stakeholders during the entire 5-day period. This helps the tech team to understand the customer needs, build a low-cost solution and quickly take feedback.
One of the examples the product manager shared was how a design sprint helped his team susdecide between build and buy. His team was tasked with changing the content production flow that supported 400 internal users. These users’ tasks were to create content (images, videos, gifs, etc.) daily that showed up on the website for 50 million daily active users. The new content production flow was said to save 2 million Euros per year in 2020. The product manager gathered a sprint team comprising a couple of users, their lead, an engineering manager, and a design lead. The sprint went on for a week. At the end of the sprint, the tech team not only understood the problem at hand but also came up with a low-cost solution that they converted into a full-fledged product in a period of 2 months. This product is still in use in 2022 and has saved over 5 million Euros yearly since its existence.
- Quantitative And Qualitative Feedback
Data plays a vital role in understanding what customers need. And a product manager’s core responsibility is to use analytical thinking and back up the decisions via data. Ideally, there are two ways to gather feedback — quantitative and qualitative.
- Quantitative feedback includes experiments such as A/B testing, surveys with closed-ended questions, and product analytics. This requires analytical aptitude since the data is large and expressed in graphs and numbers.
- Qualitative feedback includes research using questionnaires with open-ended questions, 1:1 interviews, direct observation, contextual inquiry, focus groups, and personalized data collection. As compared to quantitative feedback, this is expressed in words.
The product manager recalled multiple examples using quantitative and qualitative feedback and research to find out how his team figured out what to build early on. In one of the examples, he used A/B testing to determine whether or not a high-quality image on the website will increase the conversion rate of the product description page. As opposed to the assumption that a high-quality image will increase the conversion rate, the A/B tests proved otherwise. This helped the operations team to refrain from investing in creating high-quality images, thereby saving thousands of Euros.
As such, there are multiple ways to understand what customers need and build solutions accordingly, and it purely depends on the company and team to use any of the methods. But, what is more important is not to build products that the customers don’t need. History says that the earlier the feedback is taken from the customers, the easier it is to build the right solutions and save resources.
What method do you use in your team/company to build the right product/solution? What problems do you face while using this method? Comment below; I would love to know.
