The deadline is met, the product is approved and the client is happy. However, the uneasy familiar feeling rises again. Is there a real added value in this new feature?. The team is delivering sprint after sprint, but sometimes it’s hard to measure the impact of what we are building. This may happen because we lacked one essential part of the product development process: .
We can identify two big groups in the product development phase: Discovery and Delivery. These two depend on each other, since we can’t really start to build something without having a plan on what we want to build, how we will build it, and, very importantly, why we need to build it. The importance of answering all of these questions is the centre of The Golden Circle theory, a simple framework that helps product teams stay focused on real user value instead of just features. Focusing on the “why” isn’t just about motivation, it defines the strategic purpose behind a product and builds the foundation that makes pivoting possible when directions need to be changed. Of course we can decide not to perform the discovery phase, but then we are delivering meaningless features, based on bias of stakeholders, not truly reflecting the user needs and without adding real value to the product.
But what is this discovery phase? What does it involve? Discovery is not just a trend, it’s about exploring, testing, and learning our way toward better decisions. When the product teams use the discovery phase in a proper way, this can be indeed almost like magic has just happened! We can create space for purpose, alignment and curiosity, by shifting the main focus from the output to the outcome - and we are product people, so we are curious, we make questions. That is when real impact begins.
What is Product Discovery?
Before we talk about strategy or team happiness, let’s start at the beginning — what exactly is Product Discovery, and why does it matter so much in our daily work?
Product discovery can be described as the initial and cyclical process to build something, where we get to explore the universe where the product and its features will be used and understand better the context of why it needs to exist based on the user and customer’s needs (and, as product team members, we can assure you that this happens frequently, at least from our experience). Basically, we can say that the discovery process can be the operationalisation of the Product Vision, since it’s our Vision that will provide the long-term direction that keeps everyone aligned.
The discovery is a continuous process. But why should we make it a habit rather than a one-time event at the beginning of the project? As Teresa Torres stated in her book, continuous discovery keeps teams in constant contact with their users, allowing them to make small but powerful decisions week after week instead of relying on big and risky changes planned months in advance.
This approach fosters a steady rhythm of learning and validation, reducing uncertainty and, thereby, increasing confidence in every step of development. By weaving discovery into the daily workflow, teams stay aligned with real needs and can adapt faster to change. In the end, continuous discovery isn’t just more efficient; it builds products that genuinely resonate with users because they’ve been shaped with them, not just for them.
The product team must take note of the problems worth solving, prioritise them, elaborate a plan on how to do it, and then start building the solutions. Before any development the questions why, how and what must be answered in order to have a clear build plan. The goal is to reduce uncertainty and ensure our time is being channelled to build the right feature/product.
Why Product Discovery Matters
But what involves discovery? What are the methods we can use to make it more meaningful and valuable? Usually this phase involves user research, testing the hypothesis, prototyping, and constant iteration. There are multiple that can be used in order to make this process streamlined and organised - here we can list some examples:
Design Thinking:
This framework adopts a more empathetic approach involving users and other stakeholders in this process. It is defined by 5 main stages: empathise, define, ideate, prototype and test;
Lean Startup:
It is based on the 3 continuous stage division in the product discovery process - Build, Measure and Learn; this cycle will test the assumptions with a MVP (Minimum Viable Product) that is the simplest version of a product that delivers core value to users while requiring the least effort and resources to build; its purpose is to validate assumptions, test real user behavior, and gather feedback early in the development process; by launching an MVP, teams can learn what works, identify improvements, and reduce the risk of investing heavily in features that may not meet user needs;
Dual-Track Agile:
The product work is divided into two phases: Discovery and Delivery. In Discovery, the product team identifies the ideal product solutions by exploring user needs, validating problems, and testing potential approaches. In Delivery, those solutions are built, shipped, and validated in real environments. To ensure the process is effective, success is measured using predefined metrics, such as adoption, engagement, conversion, or usability indicators, that confirm whether the delivered solutions are meeting expectations and solving the intended problem.
We can apply one of these frameworks, mix them to make the best version for our customers, or create our own approach. The important thing is that we have a structured discovery process established to impact our work in a positive way. We also need to note that Discovery is a team effort, it’s not just a Product Manager or Product Owner responsibility. Discovery happens when the so-called Product Trio - Product, Design and Engineering - work together along the way, to make this process richer and faster by sharing and building things together. This collective ownership leads to better decisions, stronger alignment and final solutions that are aligned with users, business and technology simultaneously.
Strategy vs Discovery: Finding the Balance
It seems that, sometimes, Product Discovery and Product Strategy are the same thing, and we may think that by having a good, structured discovery process we don’t really need a clear and strong strategy. Should we rely only on the discovery or should we focus only on strategy? Or the winning answer is getting both?
Once we understand what is, the next step is connecting it to something even bigger — Product Strategy. Discovery and Strategy shouldn’t be perceived as rivals, but as partners. One will provide focus, the other will provide insight. When these two work together, teams move with increased confidence and clarity on the project they are involved in.
When we refer to Product Strategy, we talk about the definition of why and where. It’s here that we define the vision that will inspire and guide the team, define the goals and priorities that will be aligned with both business and customer needs. This process should give clarity to the team, providing a clear direction to be followed and aligning all the efforts in doing so.

About Product Discovery, we can say that this process makes sure the direction previously traced is aligned with users desires and solves their real problems. We can call it a reality check, since through a defined framework, that may or may not involve interviews, prototypes, mockups, data, the team will validate assumptions periodically and prioritise them according to the user’s needs. Having discovery without strategy would make the process chaotic, since we would lack focus on the path, but strategy without discovery would also not work properly, since we would risk building features based on only assumptions without having it validated.
To make this picture more easier to perceive, let’s imagine that our product team is on a cruise ship through the ocean. The Product Strategy will be the map, it will tell us where we are going to, why we are going there and what we need to do until we get there. But maps are static, on the other hand, the sea we are navigating changes because of the weather and streams. So that’s when we need the compass, to check if we are keeping up with the defined route or if we need to adjust it - that is the Product Discovery. If we don’t have the map we can’t clearly define our destination, but if we don’t have a compass we would get lost until we get there. That is the importance of having strategy and discovery working together alongside, making sure the team navigates with direction but also with adaptability - always moving forward, but always learning.
Discovery can be perceived as a way to keep the strategy more dynamic and linked to reality. Strategies are usually based on assumptions about user needs, business behaviour or technical achievements, and they can quickly become dated. Discovery will appear as a reality check in the process, continually testing hypotheses, collecting user feedback and analysing data, allowing a constant strategy validation or direct to adjustments.
Implementing a Meaningful Approach
So how do we bring this balance between Discovery and Strategy into our product team’s everyday routines? This is where implementation becomes key. A meaningful Product Strategy isn’t just a vision statement, it should be a set of shared decisions that guide what we explore and how we learn. How can we do that in a practical way? Check below some steps we identified as important to an effective implementation of a product strategy approach:
Define measurable results aligned with the defined strategy: OKRs can translate high-level goals into specific results, which will bring clarity about the definition of success and discovery needs;
Make strategy visible and collaborative: share roadmaps, dashboards, everything that allows the team to get the bigger picture and create a sense of belonging and alignment with the process;
Integrate Discovery in the workflow: create a dedicated space for the discovery to happen;
Enable interactive refinement: allow the team to revisit priorities, adjust expectations and iterate on decisions in order to keep strategy as relevant as possible;
Encourage learning and not just delivery: discovery should be as much relevant as the features shipping; every release should teach us something new about our users, our product, or our assumptions.
When strategy is clear and discovery is already included into product teams daily work, something shifts for the team. Decisions are no longer made in the dark, they are grounded in evidence and purpose. This clarity reduces frustration, increases collaboration, and gives everyone a sense of ownership over the results.
Teams feel empowered to experiment, learn, and iterate, knowing their efforts are aligned with real user’s needs and strategic goals. In that environment, work becomes more meaningful, creativity thrives, and motivation grows naturally, which is why a well-implemented Product Strategy approach, paired with continuous discovery, doesn’t just improve products, it also improves the experience of building them.
Discovery and Team Happiness
At this point, we’ve covered frameworks, strategy and execution. But what does discovery mean for the individuals involved?
Discovery is deeply a human work. It is an essential part of the product development process that gets our curiosity and creativity up, turns on our empathy with the user, since we feel their feelings and how to solve their problems, they are also “our” problems as well; we have freedom to ask why and what to make easier to explore all the possibilities before conclude something. But, fundamentally, discovery gives product teams a voice to name a direction rather than just executing task after task without context.
The truth is, Discovery can change more than your backlog, it can change how teams feel. And that shift often brings something product teams want: happiness. Product Discovery is less about the process and more about the mindset. It invites us to slow down before we speed up, to question, to explore, and to connect with the people who use what we build. In one of our recent , we were tasked with building a product for a client who didn’t provide us with direct access to the end users. All communication went through the client’s team, which made it much harder to understand the real needs and pain points of the final users.
Without that direct feedback, we had to rely heavily on internal assumptions and the client’s interpretation of what users wanted. This meant that our discovery process had to be much more intensive, we invested more time in market research, competitive analysis, and reviewing similar tools already in use in the industry.
Even with a solid MVP, once the product was launched, we experienced a high number of change requests and a lot of back and forth. Most of the feedback came after release, through “complaints” or reports on what wasn’t working as expected.
This project showed us how critical it is to get as close as possible to user needs from the beginning, especially when there’s no direct user contact. The more accurate we are in the first iterations, the fewer resources we waste later. It also highlighted how valuable a structured product discovery process is - even when we have to work around constraints.