As product design leaders working in media for the last six years, we’ve been part of cross-functional teams that have researched, tested, developed, and released various product features, optimised customer journeys, and even launched a few new products. 

Despite being immersed in our users’ news habits and behaviours, we are often surprised by the customer insights we uncover along the way.

Here are some examples:

We never would’ve known to adjust a channel focus or take a more nuanced approach to our product experience without insights from our customers. That is why the voice of the customer is needed as you work to evolve your products. 

Product discovery focuses on ensuring you (your team, product, or organisation) are solving the right problems or needs of your customers while assessing the risks and opportunities involved in achieving your business goals. Developing new products or features is time consuming and expensive. When a product team is focused on the desirability, usability, and viability of any potential solution, it is easier to mitigate risks, ensuring your organisation prioritises the “best bets.” 

Product discovery is about creating products with a human-centered point-of-view and accepts (even honours) a certain level of vulnerability. It’s based on the premise that as a product team, you don’t always have all the answers and need to step into the “shoes” of the consumer to challenge your thinking and assumptions. Discovery is all about determining what is the core benefit that the product must provide. 

Requirements of a productive discovery approach

Discovery is also messy, non-linear, and often frustrating. It requires:

The right mindset: One of curiosity and investigation; interested in learning about the pain points of others (customers); valuing the validation of concepts; and being able to pivot as needed. You should not be overly concerned about “checking all the boxes” but in doing just enough to identify a path forward for your consumers or business. The inclination will be to jump right into design, but it’s critical to first understand the underlying user need. 

Discovery is not done once or at a single point in time. It is a regular, ongoing phase of working that informs quarterly roadmaps, five-year plans, etc. Think of it as the engine driving inputs into delivery.

The right players: These include problem-solvers seeking answers and risk-takers who push until they find needs or opportunities that are desirable for their consumers and viable for their business.

Discovery teams should be composed of players from different functional areas (strategy, product, product design, engineering, marketing, content and editorial, growth, etc.). This ensures there is diversity of thought and speeds up the alignment required to bring change and identify new opportunities. Exposing these teams to user feedback so they can “walk in their shoes” ensures the user is always top of mind from discovery to launch. 

Embracing common frameworks: Driving innovation requires a framework-based approach. Don’t spend time overly documenting every process and dependency. Establish just enough “rules” to govern inter-team collaboration working toward actionable insights and potential concepts or solutions.

This ensures you can work nimbly and efficiently. A common complaint of formal discovery work is it takes too long. Instead, teams often skip this step and start by jumping to a solution — often one that is feasible from a delivery standpoint but may not address underlying consumer needs or achieve sufficient impact to your business. Instead of falling into that trap, consider some simple rules of engagement to do “just enough” discovery that you need for your problem space.

Examples of some rules in the process

1. Understand your user

This can be a large undertaking or a rather quick confirmation of your existing knowledge base of your target. 

The rule: The level-of-effort here is driven by the answer to this question: Is this a first-time endeavor in understanding the problems of the target consumer? 

If yes, then you will probably need to dedicate some time and resources to ensuring you identify common problems and needs so you get the full picture as you move to identifying solutions. If no, then what is the nuance or new question you are trying to address? How might you leverage existing feedback and insights to jumpstart your work? How can you show a connection between your existing knowledge and desired learning?

2. Frame the problem

In discovery, it’s not about solving a problem but making sure you solve the right problem. Framing the problem is essential because it ensures the team aligns on the right scope of work. Often the problem statement is focused on business value instead of user value. This mistakenly turns discovery into focusing on how to sell more rather than identifying value for the user.

In the words of Scott Berkun, author of The Myths of Innovation: “Discovering problems actually requires just as much creativity as discovering solutions.” 

Many teams typically believe problem framing is problem solving. It’s not. It’s about challenging assumptions about how users interact with your product and being open to new perspectives not previously considered. A good problem statement(s) can help to ensure your eventual solutions are aimed correctly in the larger problem space.

The rule: Don’t skip this step! The inclination will be to jump into problem solving without critically evaluating the problem first. This is because problem framing takes effort, attention, and practice. Pulling together functional requirements and spinning up visuals is what teams do every day and“feels” like the right step.

Instead, stop and ask (one or more of) the following:

• Would your target user agree this is their main pain point? Do you know for certain this is this problem that impacts user engagement and retention?

• Who would use this product or service? Does this align with your growth demographic?

• What is the root cause of this problem? Is it an issue with process, platform constraints, capacity?

• Where does this problem live within the organisation? What teams are most affected?

• Will solving this problem serve both the users and the business? Will the solution create capacity issues? Will you need to crawl before you run?

• How will success be measured?

• What KPIs are being affected by this problem? 

There are a number of exercises to get you there, but here are two effective options to help you begin:

• The 5 Whys: Start with the problem and then ask “why?” five times. The key is to avoid assumptions and logic traps. It helps to explore the cause-and-effect, getting to the root of the problem. 

• The Four Ws: Gather around a large wall with Post-its, or in an online collaboration tool like Miro and ask the following questions to quickly synthesise the issues: Who is affected? What is the problem? Where does it happen? Why does it matter?
  

Understand the competitive market

Analysing direct and indirect competitors will help the team understand what the market for a product or feature will look like. Performing an in-depth analysis helps gain an understanding of what users might expect from your product. 

Secondary sources like industry articles, case studies, benchmarks, and market research help provide a more complete version of the market and could be examined when needed. But completing a UX competitive analysis will reveal how similar products address user needs and behaviours.

An effective analysis should: 

• Reveal the strengths and weaknesses of your product.

• Identify the biggest gaps in the market.

• Provide evidence to back up design decisions.

• Help the team determine how to differentiate the product from the competition.

Establishing a clear objective for this work will ensure you don’t “boil the ocean” and review an entire Web or app experience. Identify the key user flows or features, navigation, or content in advance. Then, create a list of five to 10 direct and indirect competitors. Compiling your findings into a presentation, highlighting both product weaknesses and innovative ideas provides a foundation for design to build upon.

Related to a framework mindset, there are different discovery techniques featured in this post that can be used in a variety of combinations to gain user insights and determine what is the problem you are trying to solve.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .