For Part 1: Easy to Talk About, Much Harder to Achieve, read previous blog post
The question of when teams need to collaborate in the product development lifecycle has an easy answer: always. But, there are key activities that take place within a product development lifecycle where collaboration is absolutely necessary.
Collaboration through Product Discovery and Product Delivery
There is an emerging concept in product management called dual-track agile that essentially looks at product development as two tracks: the product discovery track, and the product delivery track.
On the product discovery track, teams collaborate to understand what the right product is to build. On the product delivery track, teams collaborate to make sure the product is built right. (Source: Jeff Patton, www.agileproductdesign.com)
Both tracks require a foundation of collaboration and validation in order to be successful.
In today’s blog post we’re going to talk about the importance of collaboration through the product discovery phase of product development—when teams are trying to figure out ‘what’ actually needs to be built in order to be of value to the market.
Traditionally, in the product development lifecycle the validation of a product doesn’t tend to happen until after the launch of a product or during the validation of a developed prototype. Usually by that time, a significant amount time and money has already been spent on defining and developing the product to some degree—without completely validating that the product will meet a market need.
On the product discovery track of the dual track agile approach, the focus is on validation, validation, and validation. Validation that the right problem has been identified, validation that the right solution has been decided upon, and validation that the solution being proposed is a beneficial opportunity for the company to invest in. Validation cannot be done without collaboration.
Remember that statistic we mentioned the other day? That 80% of a product’s features are never or infrequently used? Well here’s another stat to think about—of the billions of dollars in consumer electronics that are retuned annually, only about 5% of those are because of defects. And what that really says is that the main reason people are returning products is simply because they are not what they expected or needed. And it’s not just because they were unwanted Christmas or birthday presents. Returning a product because it is not what we needed is something we can all probably relate to—how many of us can say that every product we have purchased has met our needs perfectly? Or that we have never returned a product once purchased because once we got it home ‘it was way more complex than it needed to be.’ People want products that solve their problems and are easy to use—in other words, they want usability and utility.
Product discovery helps us develop products that will solve a real problem—and make sure the features we do develop are meaningful and valuable for the target market. And that’s because the product discovery track’s entire purpose is to eliminate all potential product features that will not solve real market problems. In the world of lean, it means that we are eliminating the ‘waste.’
How does product discovery work?
During product discovery, validation is the name of the game—and in order to validate, you need to collaborate.
The right market problems need to be identified and validated.
There is no value, or business sense really, in developing a product that solves a non-existent problem. It’s a lose-lose situation—the market gains nothing and the company developing the product could possibly lose everything.
One of the key activities within the product discovery phase, and one that almost every product manager is responsible for, is to ensure real market problems are being identified to solve. How to identify the problems can be the tricky part—the list of potential problems can sometimes seem endless and the effort to sift through them all to identify the real ones can often seem overwhelming. There are problems reported directly from existing customers in the form of complaints, there are direct requests for new features from existing customers, the request for new products from potential customers, the market studies that indicate the need for this or for that for market segment x or market segment y—you get the picture and most likely relate. Identifying the real problems to solve can be a daunting task. But if it’s not done and the right problem is not defined then there can be an entire domino effect into the solution that is eventually defined, then developed, and then released—most likely into a market that will not want it.
The source for gathering problems can be many in product management: specific feature requests from existing customers, product requests from potential customers, focus group results, market studies, customer interviews, user conferences, and the list can really go on. But receiving problems and understanding what problems need to be resolved in order to be of value to a customer is a different ball game.
We have all probably heard the famous ‘horses’ quote by Henry Ford:
“If I had asked people what they wanted, they would have said faster horses.”
Whether or not that statement is actually accurate, we cannot be sure—but I think the point of the quote is important and valid. And that is: the problems we receive from our customers are not always the problems that need solving. They are however, problems that need analyzing. Many times what we receive from customers are the symptoms of the real problem or a solution they have already thought up in the form of a feature request—the product discovery team then needs to take those problems to analyze them, categorize them and identify where the patterns lie—and what the real problems are that need solving. To do that effectively (and efficiently) requires validation through collaboration. Problems need to be analyzed from different perspectives, and everyone on the team needs to be on the same page about what the valid market problems are that they will be solving with a new feature or product. If only one person undertakes this activity, or there is too much of a reliance on the market to dictate the real problems, there is a serious risk that the real problem will be overlooked and the wrong solution developed.
To identify market problems, product teams must work together and with their customers and users to understand, analyze and then validate what the real problems are that need solving.
The solution that solves the problem needs to be validated too.
When you start thinking about how to solve a problem, there is a good chance you will think of more than one way to do it. In fact there is almost always more than one way a problem can be solved.
In product management, there are also factors that influence how a problem can be solved—the budget a company has to develop or enhance a product, the market segment the product is being developed for, the amount of time a company has to develop the product before their competitor does, and even the level of complexity and effort that should be used to solve a problem. Some problems we may need to develop a new generation of product for, other problems we may only need to apply small enhancement and maintenance upgrades to. Both approaches could result in the same level of value and satisfaction for a user.
Collaboratively analyzing problems and coming up with the most effective solution is all part of determining and validating the solution to an identified problem. Problems are solved more effectively when done by a team of people, and solutions are more valuable when they are constantly validated throughout the development lifecycle.
Let’s talk about why collaboration is so important when it comes to defining valuable solutions.
As individuals, we simply don’t have all of the different perspectives, experiences, and knowledge to brainstorm all potential problems and solutions ourselves. Our perspectives are filtered by our past experiences, and we can very quickly fall into the traps of confirmation bias and functional fixedness.
Confirmation bias is a human tendency that happens when we already think we know what the solution or problem is without really examining if we might be wrong. Subconsciously, we do it all the time—we look for evidence to support what we already believe. We seem to remember only the times our favorite sports team has won yet tend to easily forget about all those times they have lost—or maybe we only tend to research the information to confirm our already formed opinions when it comes to write a new article. Or have you ever noticed that when you buy a new product—maybe the newest phone, or a new car, that you start to see it everywhere you go? That’s confirmation bias—it’s us looking for evidence that we purchased the right product. In product management, confirmation bias can present a real threat to both understanding what the real problem is, or determining what the best solution is to build when it is undertaken by only one person, and not questioned by the team.
We also tend to get trapped in a cycle of what is called functional fixedness—meaning that we tend to approach solving problems in the same way over and over again, especially if we are familiar with the components of it.
Want to test it out and take a break from reading? Try the following test designed by psychologist Karl Duncker to illustrate the effects of functional fixedness:
Given the following items:
How could you fix the candle to the wall so that the candle’s wax does not drip onto the floor below?
Well if you are like most people, resolving this problem is a challenge. Often, individuals alone cannot approach a problem from different angles to fully explore all viable solutions. In the case of the thumbtacks, matches, and the candle—many people get stuck thinking only of the objects as they are presented, which are in the boxes. But remove the thumbtacks or matches from the boxes and ask them the same question, and they are more likely to get it right:
To fix the candle to the wall so the wax does not drip, remove the thumbtacks from the box, place the candle in the box, and tack the box to the wall so it catches any dripping wax.
Most individuals get stuck on thinking about the problem in only one way—but when they are allowed to collaborate with others to discuss possible solutions, many tend to get the answer eventually right. When we apply functional fixedness to product management, we can immediately start to see why brainstorming solutions needs to be a collaborative effort—it is too easy for a single person to miss a potential solution.
We also can’t forget about the role customers and users of a target market can play in validating the solutions we come up with—before they ever make it to the market. The product discovery phase of a product’s development is arguably the most important time to engage your customers and end-users in understanding the problem and what the best solution will be. Collaborate with your market by inviting them in for focus groups, calling them up to elaborate on requests or complaints—drill further down into their issues, and ask them to contribute towards or rate the various solutions your team has generated.
Before any product idea moves into development you want to have it validated by the market you are trying to sell it to—doing so will save you time, money, and many frustrations down the road.
Once the solution is validated, the opportunity needs to be as well.
The development of a product needs to be mutually beneficial for all stakeholders involved—the customers, the users, and the company investing in the development of it. The product development team may have thought of a really great feature to solve a real problem with—but that doesn’t always mean it will be beneficial for the company to develop it. Thought and consideration needs to be put into how an identified solution can also help the company achieve its goals. No feature or product should be developed until it is determined it can actually be developed successfully.
To do this, a collaboration and validation process needs to take place with the relevant internal stakeholders to determine that the identified opportunity is one that is worth a company undertaking. The team together needs to answer the questions: ‘how will solving this problem help our business?’, and ‘why us? What makes our company capable of solving this problem successfully?’
Stay tuned for the next blog post that talks about collaboration through the next phase of the product development lifeycle: product delivery.
Read Part 3: Working Together Through Product Delivery
[cta id=”7443″]
Trackbacks/Pingbacks