I have been presenting “Discovery Misconceptions” at product conferences and in-company talks to my clients, helping them make product discovery more effective. In this talk, I talk about the 4 most common mistakes I see product teams make:

• Misconception #1: Thinking that discovery is a process. No, discovery is not a process. It is a set of risk mitigation tools and a mindset.
• Misconception #2: Thinking that you need to do discovery for everything. Not necessarily. Example: if it is something known, regulatory issues, or urgent needs.
• Misconception #3: Thinking that discovery is about understanding the problem. Yes, but discovery is also about creating hypotheses for solutions. Not doing solution discovery is the reason why many products fail. Solution discovery is where the magic of innovation happens.
• Misconception #4: Thinking that engineering should focus on delivery. Engineering is essential in solution discovery, working together with Product and Design to create and test solution hypotheses and choose the one that will yield results more quickly.

Reviewing my articles, I noticed that I hadn’t written about misconception #4, so here it is!

Engineering is much more than a focus on delivery

In a scenario where “focus on delivery” is often extolled as the leading indicator of success, it is easy to fall into the trap of believing that engineering’s work is limited to transforming requirements into code. However, this view is limited and can hinder innovation. When we understand that engineering is a fundamental part of the discovery process, we realize that its role extends far beyond “delivering” a finished product; it involves discovering, testing, and validating solutions, in collaboration with the Design and Product areas.

The belief that engineering should focus only on delivery is common in environments where the pressure for immediate results overrides the need to think deeply about the solution. This narrow view overlooks the fact that, by focusing solely on execution, the team tends to repeat the same patterns without exploring alternatives that could generate more robust and innovative results. Reducing engineering to a mere executor prevents it from exercising its technical expertise from the beginning, creating a cycle of “deliver and fix” that rarely leads to the ideal solution.

This separation, in which Design and Products focus on discovery while Engineering focuses on Delivery, comes from this image:

Discovery and Delivery

Although we call the core trio of a product team Design, Products, and Engineering, we separate their responsibilities with Design and Product focused on discovery and Engineering on delivery. It turns out that the focus of Design and Product ends up being centered on the problem, on understanding more about the problem, who has this problem, and what is the motivation to solve this problem. Then, an idea for a solution emerges that is quickly transformed into a prototype, and the requirements are passed on to Engineering to make the Delivery.

Solution discovery

When engineering is seen as an integral part of discovery, it becomes a strategic ally in identifying and validating solution hypotheses. Instead of waiting for decisions to be pre-defined by Product or Design, engineers can contribute technical insights on new approaches possible thanks to technological advances, and which approaches are viable and scalable.

The real magic point in the discovery process happens in Solution Discovery, when Product, Design, and Engineering work together. It is not enough for Product and Design to simply discuss hypotheses and then pass them on to engineering as a task. Engineering needs to be involved from the beginning, bringing technical vision, exploring possibilities, and, often, proposing the most innovative solutions.

The solution discovery

The most significant value generated by Engineering is not in delivery. It is in solution discovery. It is in this space of co-creation between Product, Design and Engineering that the most innovative solutions emerge, and this is precisely where Engineering needs to be present from the beginning.

Solution discovery is the most fun part of the product development team’s work, and, as shown in the figure above, it should have equal participation from Product, Design, and Engineering people. Not everyone on the Engineering team needs to participate. Still, it is essential to have at least one or two engineers working closely with Product and Design to create and evaluate solution hypotheses.

Practical Example: Lopes Brokers App

This point becomes clear with the example of the app development for brokers at Lopes. When I arrived, the app was being treated as an “MVP”, but it had already been seven months of development, something that does not match the concept of an MVP. An MVP that had already been in development for seven months and would take a year to be delivered completely loses the “M” for minimum and the “V” for viable. The team spent five months on discovery, expanding the scope by identifying the various actions that the broker needed to perform, such as:

• Querying the database to verify or register the client.
• Searching for similar properties to present to the client.
• Drawing an area on the map to delimit where to look for properties.

These functionalities, although useful, diverted focus from the core problem: ensuring that the broker received the lead quickly to increase the chances of conversion. This diluted focus led to an MVP that was expected to take a year to be delivered. The situation only changed when engineering asked a fundamental question: “Why do we need to make an app for this?”

The solution proposed by engineering was simple and effective: instead of a complex app, they suggested sending notifications via SMS. In just 10 days, the solution was implemented, allowing brokers to receive leads instantly. What seemed like a year-long project was solved in days, thanks to engineering’s strategic vision during discovery.

This example shows how engineering is more than an execution agent. It has the power to contribute to creative and efficient solutions, anticipate technical risks and avoid long development cycles. When we involve engineering from the beginning, we can:

• Accelerate innovation: The exchange of ideas between Product, Design and Engineering generates more innovative and agile approaches.
• Reduce risks: Anticipating potential technical challenges avoids unpleasant surprises in the future.
• Save time and resources: Rapid validations and well-informed decisions ensure focus on what really matters.

Conclusion

Engineering should not be seen only as responsible for delivering what has been decided by others. When Product, Design and Engineering work together, we carry out a more powerful and efficient discovery, focused on finding viable and scalable solutions that truly generate impact.

The true value of Engineering lies in its ability to contribute to Solution Discovery and propose solutions that often go unnoticed by Product and Design. By abandoning the limited vision of “engineering as delivery” and adopting a collaborative approach, we can transform complex challenges into real opportunities for success.

Lopes’ example is just one among many. When we stop treating discovery and delivery as separate processes and start seeing them as an ongoing collaboration, we unlock the true potential of product teams and, especially, Engineering.

For those who are curious to see the talk about the “Discovery Misconceptions”, it is available here:

Workshops, coaching, and advisory services

I’ve been helping companies and their leaders (CPOs, heads of product, CTOs, CEOs, tech founders, and heads of digital transformation) bridge the gap between business and technology through workshops, coaching, and advisory services on product management and digital transformation.

Digital Product Management Books

Do you work with digital products? Do you want to know more about managing a digital product to increase its chances of success, solve its user’s problems, and achieve the company objectives? Check out my Digital Product Management books, where I share what I learned during my 30+ years of experience in creating and managing digital products:

• Digital transformation and product culture: How to put technology at the center of your company’s strategy
• Leading Product Development: The art and science of managing product teams
• Product Management: How to increase the chances of success of your digital product
• Startup Guide: How startups and established companies can create profitable digital products