In this edition of the trivago tech blog, we sit down with Sören Weber, a product manager at trivago, and discuss continuous product discovery.
Hey Sören! What do you do at trivago?
Hello, I am a product manager here at trivago. I have worked on different parts of the product such as apps, alternative accommodations, landing pages, and search & flow. We work in cross-functional teams that solve problems within a defined scope. My key responsibilities as a product manager are developing a product vision & strategy, defining objectives & outcomes, driving product discovery efforts such as user research, solution ideation, solution testing, and supporting engineering in product delivery. Overall it is about helping the team to ship the right product.
Today we want to focus on the product discovery part. Can you quickly define what product discovery means for you?
Product discovery is about deciding what to build, whereas product delivery is about building it. In product discovery, we need to learn quickly about users’ needs and create ideas for solutions to satisfy them. Product delivery focuses on shipping that solution quickly and with great quality.
Both discovery and delivery are important to ship great products. Product discovery however has a lot of leverage, because it defines what you are going to build. If you decide to work on the wrong thing it doesn’t matter how well you deliver it.
You recently adopted a new product discovery framework. What was the reason for that?
We are always trying to improve our product management capabilities and also look for inspiration from outside. One of the good practices that emerged recently was the continuous discovery framework from Teresa Torres.
Even though we had already adopted many good product management practices such as cross-functional teams, outcome-driven OKRs, and agile software development, the product discovery side felt a bit underemphasized and we saw an opportunity to improve.
Why did you decide on this particular framework?
The continuous discovery approach had a lot of traction in the product community. Our UX lead Marco has also had positive experiences with the framework at his previous company and suggested we try it. We also liked how the framework covers both the principles as well as practical tools and methodologies.
Of course, this framework is not the only approach to product discovery, and we don’t want to restrict ourselves to just this one. Instead, we want to get inspired by different discovery practices to find the best mix for our specific situation at trivago. However, you also have to focus and commit to a few things you want to put into practice, and the continuous discovery framework seemed to have big potential, so that’s why we went all in on continuous discovery.
How did you get started applying the continuous discovery framework?
We initially began with a guerilla approach within our product team after reading the book Continuous Discovery Habits by Teresa Torres. We started conducting user interviews and mapping out opportunities as described in the book. This was a good start, but we struggled with applying it consistently. Additionally, the value of the framework wasn’t immediately obvious to us, or our stakeholders.
We really got started when we took the Master Class offered by Teresa Torres and Hope Gurion. In this class, we learned to apply the framework in detail. It is important to note that we did the training with a large part of the product organization including product and design leadership. This provided the momentum needed to apply the framework in a sustainable way.
An essential part of the continuous discovery framework is the user interview. How did this go for you?
Yes, the idea is to talk to users every week, which was challenging for us to put into practice. First of all, we needed to set up the operational aspects of it, such as recruiting the users and scheduling the weekly interviews, which we did together with our user research and global operations team. Then we had to learn how to run a user interview so that it informs our product discovery. The framework even suggests that all members of the product team are conducting the interviews, including the product manager, designer, and engineers.
This was new to each of us, and we had to learn how to talk to users, how not to bias the user, and how to extract meaningful stories from the interview. In the beginning, it felt a bit awkward to run the interviews, but over time we got a lot better at it. We also got great support from experienced interviewers of our user research team. Still, every interview is a surprise as you can’t know in advance what the interviewee is like and what specific story the user will tell.
What else did you put into practice?
Another key tool we adopted was the opportunity solution tree (OST). The OST is a map of the user needs (=opportunities) and ideas on how to satisfy these needs (=solutions) in pursuit of a desired outcome.
The opportunities are extracted from user interviews and other sources such as product data or complementary user research. The opportunities can then be prioritized and corresponding solution ideas can be generated and tested.
The concept of the OST is simple, but not easy to apply. It took us some time until we had a meaningful tree, but now it helps us in several ways. It is now our central overview for all discovery activities and it forces us to always think about the outcome and opportunities first before discussing solutions. It also supports communication within the product team as well as with the other teams and leadership. Furthermore, it serves as a basis for OKR planning and as a key input for product strategy.
For more details on how we use the OST, you can read the article about opportunity mapping at trivago on Teresa Torres’ blog Product Talk.
You mentioned that you generate solution ideas for each opportunity. How do you do that?
We use the opportunity solution tree to prioritize which opportunities to work on and then generate ideas for these prioritized opportunities. The idea generation is done in one or several ideation sessions with the team. The activities in the workshop can be a simple exercise such as individual “brainwriting” and sharing the ideas afterward or more advanced ideation tools like design thinking methodologies. I think even more important than the methods is the fact that we do the ideation sessions with the whole team, including engineering. So far this works well, and in every session, we come up with new ideas we didn’t have before.
What do you do with all the solution ideas?
We prioritize the solution ideas by how much we think they deliver on the target opportunity, confidence level, and estimated effort. A key principle of the continuous discovery framework is that we don’t know everything for sure, and every solution has underlying assumptions.
To validate the assumptions, we’ve adopted the concept of assumption testing proposed by the framework. This wasn’t completely new to us as we did lightweight testing in various ways before, but not in such a systematic way. We now do much more quick assumption testing such as surveys, low-fidelity prototype tests, or tests with competitor products and it helps us to validate assumptions and solution ideas much faster than before.
Can’t you rely on A/B testing for testing the solution ideas?
A/B testing is very important to us and we run A/B tests for nearly all the features we put out. Sometimes it is the best way to test a solution idea. However, when there is a high level of uncertainty and a low likelihood that the feature will succeed, A/B is way too expensive. You need to implement the feature first, set up the test, and run it for a certain amount of time. You can’t do it for all the different solution ideas you have. That’s why using lightweight testing methods is so important.
You mentioned assumption testing as an alternative to A/B testing. Shouldn’t that be done by the user research team?
Yes and no. Assumption testing does require user research skills and having a trained user researcher can make a big difference. On the other hand, it is one of the principles of the framework that the product team is doing product discovery itself and is not “outsourcing” it to a separate user research team.
We followed the framework approach and empowered each product team to do the user research themselves, but with a twist. We have the luxury of having a user research team with experienced user researchers. These user researchers support the product teams as embedded coaches in conducting the assumption testing.
It sounds like you have gained a lot of value from the framework. What advice would you give to other teams who would like to adopt the framework as well?
I think it is important to commit and stick to it long enough. It is usually a bigger change to the way of working immediately and it will take time to absorb the principles and to learn the tools and methodologies. It helps to have buy-in from leadership to go through the early stages. Once the framework is in place and the learning phase is over, the benefits become more obvious and it gains sustained momentum.
I would also say don’t be too dogmatic about it. The framework is a useful starting point, but you have to tailor it to your situation.
Thank you for the conversation!
Follow us on