The origins of product discovery began in the early 2000s in response to the then-standard waterfall development methodology. In addition to the release of the Agile Manifesto in 2001, UX design and design thinking were solidifying as a way to refocus product development on customers rather than the whims and desires of internal stakeholders.
Most product teams decide what to build next with some kind of intake process. Initiatives are generated by product managers, prioritized based on a variety of factors, and the highest-ranking initiatives are built. There is a difference between product owner and product manager. When using this approach, the team is making a lot of assumptions about how well they know the customer and their expertise.
Let’s take a look at newer approaches to product discovery based on the ideas of Steve Blank, Eric Ries and others pioneers in the field that avoid making these dangerous assumptions.
Product discovery is all about customer empathy and iterative testing processes. Click To TweetModern Product Discovery 101
Product discovery is an iterative process designed to reduce uncertainty around a problem or initiative to make sure that the right product is built for the customer. In addition to ensuring that customers get the most value, product discovery can avoid the creation of feature bloat and technical debt that can sink a project over time.
While product discovery is often associated with the beginning of a project, the process should take place continuously throughout the development cycle. Dual-Track Agile is the idea that product discovery should always be occurring alongside product delivery as continuous activities that connect to create feedback loops.
Modern product discovery is all about customer empathy and iterative testing processes, according to Teresa Torres, Product Discovery Coach and creator of ProductTalk.org. Rather than sending requirements from the top down, teams should assume that customers are the experts and iteratively experiment and invest where the data leads.
Amoeboids-Collect-Customer-FeedbackDeveloping Customer Empathy
Many product teams are already familiar with customer development interviews, customer observations and participatory design. In fact, some teams have highly skilled experts that conduct customer research in order to inform the product roadmap. Unfortunately, these insights are often siloed in the product team and never reach the development team.
Product discovery should involve the creation of several artifacts that are circulated to everyone on the team in order to help them build empathy with the customer. Moreover, these artifacts should be living documents informed by hard data from customer interviews, observations and/or co-creation efforts rather than a one-time exercise for an expert.
Some of the most impactful artifacts include:
- Customer Journey Maps tell a story about the customer to better understand how they come across a particular problem or workflow and handle it during their day.
- Empathy Maps explore what customers think, see, feel or do when working through a challenge, which helps the team quickly jump into their mindset.
- Customer Personas detail a customer’s goals, motivations, feelings, beliefs, desires and other things in rich stories informed by real interviews or observations.
There are several automated tools that can also help improve customer empathy. For instance, Enriched Profiles for JSM helps everyone gain context with additional information about the individual, their organization and more based on their email address.
New product initiatives should emerge from a shared understanding of the customer rather than from a stakeholder. For example, a developer working through a user story might see a quirk in the way that a feature works based on their deep understanding of the user, which may not have been obvious to a stakeholder or even a UX researcher.
Iteratively Testing Initiatives
Many product and development teams already use some form of iterative testing, such as A/B tests. While these are better than nothing, the problem is that the development team has already done all of the work! If a feature doesn’t perform well in an A/B test, there’s a tendency to keep it anyway since there was a large amount of effort put into development.
A better approach is to run an experiment:
- Ask yourself: What has to be true for the idea to work? The goal is to uncover as many underlying assumptions as possible before writing any code.
- Look for evidence that supports and refutes each assumption using past research, customer interviews, observations or co-creation activities.
- Determine the riskiest assumptions and use them to form a hypothesis and run an experiment to validate the assumption.
- Based on the evidence, make a judgment call. Many times, teams choose to modify an idea based on what they’ve learned.
- Iteratively invest in the idea using an Agile delivery method.
Public product roadmaps, such as Roadmap Portal for JSM, can be an excellent source of evidence to support iterative testing practices. For example, a hypothesis that a user wants to score a lead in a sales tool may be quickly validated by a significant number of votes for a lead scoring feature in a public roadmap—especially if you know those votes are actual customers!
The iterative testing process can seem tedious early on. For example, you might have dozens of assumptions and very little evidence to back them up, which translates to a lot of time-consuming experimentation. Fortunately, the feedback loop speeds up over time since most ideas share underlying assumptions at their core.
As with customer empathy, new product initiatives often emerge from these exercises. When validating an assumption, a customer interview may lead you down a different path that turns out to be a much better solution to the problem.
The Bottom Line
Teresa Torres of ProductTalk.org compares iterative testing to collecting building blocks, in that over time, you collect a lot of building blocks and it’s easier to see ideas emerge from them. On the other hand, she warns that iteratively testing guesses isn’t very useful, which makes deep customer empathy an important part of product discovery.
If you’re using Atlassian products, we provide a variety of add-ons in the Atlassian Marketplace to help streamline everything from your release notes to employee success. We can even help you develop custom add-ons for any functionality that you may need to improve your workflow and deliver better products to customers. Contact us today!
