In this post, startup CEO Ferdinand Goetzen relates how product discovery led him and his team to adjust their thinking, pivot and change their product 

---

Overview

We started Reveall in 2021 as a platform to empower UX teams to do more with their customer research insights. As we sought to navigate some of the most volatile market conditions startups have ever faced, we realized that we really couldn’t afford to make any wrong decisions about we would build next.

We were very aware that many companies spend a lot of time and resources building products and features that don’t create enough customer value. We knew we couldn’t afford to do that, so in the summer of 2022, we set out to understand why this occurred and how we could make product decisions that consistently delivered value for customers.

Throughout our exploration, we kept coming back to product discovery – the process of deeply understanding your customers’ problems, needs and desires so that you can create compelling features for them. We felt that product discovery perfectly matched our company mission of empowering teams to build products their customers really need.

Through our own product discovery, we learned that every product team we spoke to was dealing with similar issues. The opportunity to support teams in their product discovery was huge, so we decided to pivot and turn Reveall into the first product management platform dedicated to product discovery.

As a startup with limited runway, we were pressed for time and we needed to work efficiently to ensure the new version of our platform actually solved the core problems we’d identified. We rallied the whole company around our own discovery process, led by our very own ‘product trio’ consisting of our CPO, our CTO and our product designer.

Our goal? To relaunch Reveall as a product discovery platform in January 2023.

Our Approach

For clarity, I’ve broken down our approach into four phases, though please note that these weren’t clear-cut chronological phases – there was a lot of overlap and the process was continuous and iterative. Often we did things in parallel, going back and forth between phases as needed.

Phase 1: Research

In June 2022 we started to focus on our own product discovery. Our first goal was to truly understand the problems and needs of product teams. To gain this deeper understanding, we relied on four approaches:

1. Interviewing with our existing customers – a mix of UX and product teams
2. Interviews with over 50 product teams that didn’t use Reveall
3. An extensive survey run with over 150 product teams
4. A year’s worth of insights we had already gathered in our own ‘Reveall repository’

We ended up drawing insights from over 250 different product teams, learning that product discovery was both a priority and a challenge for them.

Doing our own product discovery about product discovery was an interesting experience. We not only learned from product teams how they struggled with doing discovery well, but experienced first-hand what the challenges were.

One takeaway was that the tools available were not designed to really facilitate the discovery process. Most focused on adding ideas to already unmanageable backlogs and building roadmaps that rarely get met – essentially, they encourage the natural tendency to jump straight to solutions, whereas product discovery is all about focusing instead on the core customer problems that can be effectively solved.

Once it became clear to us that we wanted to turn Reveall into a platform that helped simplify the entire process of  product discovery, we needed to figure out what exactly that would entail.

Phase 2: Mapping our opportunity tree

Like every product team, we had lots of ideas. And with all the research we had done, we had lots of insights. Fully aware that this is a recipe for confirmation bias, we decided to clearly map out and break down our main opportunities.

The idea for mapping opportunities in the form of a tree came from Teresa Torres’ opportunity solution tree. The high-level problems we had identified were huge and impossible to solve head-on, so we needed to break them down into problems that were solvable, especially given our timeline.

At the  highest level, the single, big problem we aimed to solve was that teams spend too much time and resources building things that don’t have the desired impact.

We broke this down into three sub-problems (which in turn were broken down into further sub-problems, and so on):

1. Teams don’t understand their customers’ problems and needs
2. Teams prioritize based on solutions and not on opportunities
3. Teams and stakeholders lack alignment

We worked on this tree as a team, pulling in ideas and suggestions from different departments.

Once the tree was mapped, we began validating and prioritizing the problems with the insights from our research, continuously collecting data as needed to further validate and prioritize.

We had the insights, we had the opportunities and we had lots of ideas. It was finally time to start thinking about solutions. But where to get started?

Phase 3: Reverse Discovery

One thing we realized was that getting started with proper discovery isn’t easy and isn’t always a top-down process. As humans, we naturally gravitate to details which leads us to focus on solutions – but a premature focus on solutions is what we’re trying to avoid. So instead of fighting that instinct by railroading people into a single way of working, we wanted our process to work with that tendency and turn it into a positive, while still connecting to the validated opportunities that we identified would lead to business outcomes.

With this in mind, we used our existing backlog as a source of inspiration and, staying true to doing discovery properly, our CPO Marcel Hagedoorn proposed what he called ‘reverse discovery’. The idea was to essentially start with products or features (i.e. solutions) we had already defined and reverse-engineer the connecting points in the discovery process from there – going back and linking them to opportunities and outcomes along the way.

Essentially, we took the ideas we had already come up with and attempted to map them where relevant to our opportunity tree. The process also inspired the idea for a new onboarding flow, where we help new customers do their own reverse engineering of the discovery process using existing items from their backlog or roadmap.  Working both top-down and bottom-up in this way, we found an increased flow of ideas and information, helping us more quickly and easily fill out our opportunity tree.

Of course, where existing ideas did not solve our main opportunities, we discarded or changed them. This also helped reduce our endlessly growing backlog of ideas.

Phase 4: Delivery

Our rigorous focus on discovery made delivery a lot easier for us. With clear ideas on what problem we needed to solve, we could easily adjust scope based on the core user stories we identified for each problem and the resources we had available.

At the end of December, we essentially released our product discovery feature set. This included three new features we added to the platform:

• Outcomes – identify goals and OKRs
• Opportunities – list customer problems, needs and desires, validate with insights from the Reveall Repository, prioritize based on ‘impact’ and ‘confidence’
• Solutions – define features and product ideas, validate with insights, and prioritize based on effort.

We also spent a lot of time understanding how to link these all together.  In one click, users  can list the range of opportunities that exist to impact a specific business outcome AND dive deeper into the set of possible solutions for any specific opportunity.

We had previously found that product discovery and insights management really go hand-in-hand and have plenty of overlap. Therefore, many of our previous features such as our insights repository and journey mapping functionality made perfect sense in a product discovery process, providing context for the customer problems we identified. This did present a challenge though as we had to work around the existing platform as we made changes.

To better manage the insight management and product discovery use cases we serve, we split the platform into two feature sets that are seamlessly interconnected:

• Reveall Discovery (outcomes, opportunities, solutions, journeys)
• Reveall Repository (themes, data, findings, insights)

Results

Within just a couple of months we managed to revamp Reveall completely. We started as a platform that helped teams do more with their UX research insights and successfully shifted to a platform dedicated to product discovery.

Most importantly, we managed to establish features that fundamentally address some of the biggest problems product teams face. That said, there’s a lot more work that needs doing. Our goal is to make product discovery simple and effective, but every team does product discovery differently. We’re still learning, but we’re excited to rework our opportunity tree based on the feedback we get and identify the next set of problems that we can focus on.

If you want to see what the end result (although there never really is an ‘end’) you can check it out yourself at Reveall.co. One thing we can guarantee is that if you share feedback, it will end up in our own Reveall workspace and become a part of our ongoing product discovery.

Conclusion

Product discovery is a fundamental process for teams wanting to reduce risk in their product decisions. Through our own discovery process we realized that there is an opportunity for us to support product teams in their discovery efforts. Using our own product to scratch our own itch was incredibly helpful in guiding us through our research.

Our main learning is that the product discovery really helped to rally the whole company behind the same priorities. Knowing what our desired outcomes are and what opportunities lay within them made it easier to research, plan, scope and deliver features that have impact.

The full extent of the results remains to be seen, but the process in itself was hugely valuable.