AGILE, case study, Coaching, INHOUSE, Product Discovery Essentials

Case Study 2: Cumbersome and long discovery turned lean

This time we’ll have two different clients in a single case study. The reason for this is that those two companies had so much in common, shared very similar problems, and were burdened with look-alike challenges. Yet, they were from completely different industries. One coming from IT, and the other from the FMCG industry.

For the purpose of this article I’ll call them – “Company I” (for IT), and “Company F” (for the FMCG company).

Meet Our Clients

In a very short time span, we have been approached by those two companies. The first one was “Company I”. They have their own product, which is supported by the back-office platform used by colleagues’ engineers to collect data on users’ behavior. This data is analyzed and used for both determining further steps in the development of the main product, as well as for scheduling regular maintenance works on the app’s infrastructure. They wanted to strengthen the team working on this back-office application. In total, the company had around 300 employees, mainly engineers.

The second company had around 200 employees of different backgrounds, from engineers, and economists to manual workers. The product where they wanted to improve the way of work was a snack targeted to young adults. This wasn’t the main product in their portfolio, however it was exposed to a very dynamic competition. Even more stress was put on the product team because this customer segment was not something where the company was the best.

The Challenges

As said at the beginning, although those companies are rather different, they share the same problem. As a matter of fact, a lot of companies creating their products experience similar problems.
Usually, the problem is formulated in a few bullets:

  • Describing the features we want takes too long
  • Despite us putting in a huge effort, our users are dissatisfied and prone to searching for alternative solutions
  • People working on our product seem uninterested and want to leave, either for some other product in the company or to leave the company.

Although it’s obvious that dissatisfied customers are a severe problem when it comes to end-users, everyone who has been working on supporting products knows how unpleasant the internal customers can be, and how poisonous their arrows can be at internal meetings, especially if members of the board are present.

These were the problems pointed out by both companies. They were put in different words, but the bottom line was there. Now, when speaking with clients, what you get is what they see as a problem, and what is bothering them.

And this, in fact, is a consequence of something dysfunctional in their working process. It is up to us to discover what causes this behavior.

What was the problem?

The “Company I” has heard of the User Story Mapping technique and wanted their team to be educated to utilize this technique. Not to be rushed into a solution for which we don’t have a clear problem we started a discovery, with a well-prepared stakeholder interview.

Our discovery requires several meetings with key stakeholders. Those encompass the team involved, and key stakeholders on their products which includes both the teams who rely on their work and the managerial structure for their product. Through this approach, we get the view of the team from all sides.

When analyzing the interviews we came to the following sum up of the overall sentiment toward the teams:

How did we help

Digging deeper into the root cause of such sentiment we understood that product teams, but also the other parts of those companies severely lacked an understanding of product management.

Week understanding of product discovery was the reason behind the lack of success of teams working on those two products, but also the reason for misaligned and unfulfilled expectations regarding the teams’ performance.

Just a few examples that show what has been said. Management of “Company F” saw product management as a delivery engine for products that were imagined by senior management throwing them to product and manufacturing teams without context or explanation of why they are envisaged in that way. This led the teams into so-called feature factory mode, or pure delivery mode depriving them of any involvement, sense of ownership, or engagement on the product.

In “Company I” the situation was slightly better, still, the product team, although aware of the existence of certain product techniques lacked not only the experience in implementing them but also a thorough and systematic knowledge that would enable them to start experimenting and trying to deploy those techniques in their work.

From here we suggested that the product team, but also key people (leaders, role models, and future leaders) go through the Product discovery essentials training.

Without going into the details of the course I want to stress why this course was well designed for those teams. This course gives an overview of different techniques used for successful product discovery. In addition, it delves deeper into a few selected techniques that have the highest value for concrete teams and their environment. Such a structure allows attendees to comprehend a wider picture of product discovery while giving them deep knowledge combined with practical exercises in the most useful techniques.

With a clear comprehension of product discovery and practical exercises of techniques, product teams become confident in what and how they are performing their tasks, providing them with both practical and theoretical knowledge, so that they can disseminate it throughout the company.


Both teams went through the same training after which they were able to use learned techniques in their everyday work. Worth mentioning is that they didn’t opt for the same techniques to go into details. What is important is that this education equipped them with the tools to perform better. Techniques that those teams studied and started implementing were:

Learning these techniques, and implementing them in their work addressed the main pain points felt by the team and their stakeholders. Transparency is embedded into good product management, hence techniques like opportunity solution trees, and quick decision-making have this value embedded in themselves. But also, other techniques insist on being transparent in applying them.

Maybe the highest value for both organizations lies in the proper prioritization of the work to be done. The prioritization is not only the function of good resource allocation but also of the most significant problem for the user. A proper understanding of users’ priorities is the crucial cornerstone in good prioritization and roadmap setting. An additional benefit from both transparency and a good understanding of user needs is the higher engagement of the team and a sense of ownership.

A natural extension of this training is user story mapping, a technique that helps teams plan their work on the product and create the most valuable and meaningful phase for product delivery.

Supporting the team with an experienced mentor is beneficial on several levels, especially in the initial steps of setting the discovery process well.

If you are facing similar hurdles in your journey, contact us, and let’s chat about how we can help and supercharge your team’s performance.