How we set up our Team for Continuous Product Discovery

The Dilemma With Product Discovery

Usually, we use a discovery period intending to understand the users’ problem, define a solution, and then decide what to build in the so-called “delivery”. Many companies have their specific budgets for these week or month-long periods and a super-important meeting at the end of the discovery to present the findings to the leadership team so that they can decide on the next steps.

The discovery - delivery cycle

Even with very short cycles between discovery and delivery, it can take up to several months from identifying a user problem to the release of a potential solution to real users. While many companies adopt agile and product discovery techniques to better understand their customers faster, it still takes too much time and effort to identify suitable solutions that solve real user problems and also help the business.

I believe discovery should be a continuous process that involves all team members (especially if you don’t have a dedicated product researcher on the development team). Continuously generating insights gives us the flexibility to act instantly on changing parameters like requirements or newly gathered information (about our users). I’d like to outline how we set up our team at XING (the biggest social business network in Germany, Austria, and Switzerland) to be able to continually run product discovery while always checking the solutions against the user and the business value creation.

The Magical Intersection of Product Discovery

When we discover new potential solutions, we (hopefully) aim to build features that fall into the intersections between user needs, business needs, and technical possibilities. This intersection is where the magic happens. Here we face the following questions: how do we discover these solutions, and even more importantly, how can we stay in this intersection in the long term?

A Venn diagram of user needs, business needs, and technology with discovery at the center

First, we need to keep learning continually in each of the three areas. At Xing the technology we use is predefined so I will focus business and user needs and how they are connected. I found Melissa Perri’s new book, Escaping the Build Trap to be an excellent resource for understanding this connection. She says that you can only create significant value for the business by solving the big problems for the users.

Solving big problems for customers creates big value for businesses Melissa Perri

Let’s start with the business. There need to be specific elements in place before continuous product discovery is even possible. The company needs to have a clear vision and mission and a way to communicate these regularly to each employee. Everyone in the company – especially development teams – needs to know precisely where the company is heading and what it values. Company culture must focus on outcomes instead of outputs to make sure that there is room for iteration and learning. There will often be times where a specific task might feel like a waste of time but it proves to be essential for the full picture.

Vision and mission presentation at XING’s yearly kick-off event

Understanding User Needs is key

All team members must deeply understand the problem space in which potential solutions should fall. In our case, we already had extensive ground research material done by multiple peer teams, and coordinated and offered by a dedicated “users insights” satellite team. They developed “core needs”, that describe various needs of the users in more detail. The results were easily accessible in a printed booklet or as videos online. Other companies use frameworks like jobs-to-be-done (e.g.Intercom) or personas (e.g.N26) to educate about their users’ long-term needs.

With these insights, the general direction of the company and the major pain points of our users, we were able to set boundaries for our continuous discovery process.

Setting the boundaries of the product discovery

What Problem can be Solved by our Teams’ Features?

Typically, the larger the company you work for, the smaller the parts of the product that fall into your teams’ responsibility. So, it’s essential to identify and scope the user problems your team can solve. Solving the big user problem often requires a shared effort from a number of teams, in order to find the right balance between small enough to make it work and large enough to have a global impact.

To understand the user problem in more depth, it helps to get everyone in the team to focus on one main topic. While design sprints are an excellent way to have an initial deep dive, they can be costly and time-consuming, and we found we needed something more lightweight to learn and iterate continually.

For example, we made it a requirement for every team member to test our current live features with real users in short interviews. We provided a few guidelines on how to interview and what to ask, but the team members had to organise the interviews themselves. We then collected all interview outcomes and together decided what to take over to our product backlog. The interviews were a great addition to our general user research and our findings enabled us to see user problem patterns more quickly and spot the “low-hanging fruit” fixes to our products. But for me, the most significant side-effect of the interviews was the change in the mindset of the entire team. As a product person, I was no longer the only one speaking for our users.

A Slack message asking, then how do we explain our user interviews — The Slack message of one of our data engineers

If you want to dive deeper into the topic of interviewing users, I recommend our list of great book recommendations that deal with this topic on The PM Library.

Are we Creating Value?

To understand if features solve user problems is one thing, learning if they also globally make an impact on the company goals is another. Earlier I talked about setting the boundaries of the discovery to fit the direction of the company. We found that taking this direction into consideration and communicating it openly with the team was an essential step to understanding which metrics we wanted to move with our solutions.

We listed all our features, their performances, and how much influence they had on reaching our business goals. By combining this information with the user research results from earlier we were able to see new potential opportunities to improve our product. We also learned that it could be quite beneficial to all team members to get access to these findings, to experiments, and investigations.

Bringing it all Together

By bringing all the findings together and iterating on them regularly, you should get a clear picture of your users’ pain points. You’ll understand where to start looking to solve the problems with the highest potential to serve users needs but also deliver value to the company.

A Venn diagram that shows where user need and business needs overlap — Understanding user and business needs

After you have identified and deeply understood a problem worth solving, you should explore different solutions. The findings from the problem identification phase can also help to shape potential solutions so that hopefully they already fall into the intersection between user needs and business needs.

Finding Your Next bet

Usually, not all solutions that you and your team come up with will automatically fall into the magical intersections. Therefore, it makes sense to iterate on the most promising ones by getting direct feedback from your users and by simulating potential results with previous or existing data.

Every two weeks XING invites in up to eight users for feedback on our solutions. Every product team can register to interview these users and show them prototypes or ask questions. By testing solutions very early in the process (e.g. with paper prototypes) or later with more advanced prototypes, we can better understand what the user finds desirable but also how they would interact with the solution.

If you can run queries on your database, for example, you can also simulate specific solutions and validate them against the highest business value. With the simulations, you can answer questions like “Does this happen frequently enough to have a global impact?” or “What user groups can we trigger with the potential solution?”. You can only get real adoption rates and learn by releasing to real users, but running such queries can give you great insight into which solutions you might want to invest.

However, if you manage to quantify all your findings regularly and weight problems and the potential solutions against each other (e.g. in a value-effort matrix) you can identify and solve the big user problems and have an impact on the global business goals.

A Venn diagram of user needs and business needs showing where different ideas fall on the spectrum — Iterating your way to the intersection

What we Learned

Short and recurring discovery cycles are better than long discovery phases.
Make the full team talk to users if possible.
Base your assumptions on various sources and don’t believe in one A/B experiment to decide in which direction you want to go next.
Please don’t shy away from building stuff to learn something and throw it away afterwards.
Try to quantify as much as possible.

More About Product Discovery

Here you can see one possible way to run a Continuous Product Discovery. In the end, it depends on your team and company setup.

The following books helped me a lot in my research for this article, and I can highly recommend them to anyone who wants to learn more about product discovery.

If you want to check out more “Product Management”-related books feel free to visit my Medium publication The PM Library, where we cluster books by specific topics and feature product leaders from all over the world with their recommendations.