Dual Track: The Journey of Discovery and Delivery in Product Development

As I shared here [Product Management: Balancing the Possible, the Feasible and the Desirable], I am continuing my crusade along new paths of learning and experience, now with a sharper focus on product development. And on this journey, besides a great deal of practice drawn from our day-to-day reality at Valcann, I have also been digging deeper into the theoretical foundations of the subject — into what lies behind each of the practices, tools and concepts of this discipline.

I can say that product development is like a great adventure full of questions. And if I could suggest a map for this adventure, a compass to guide the process, I would choose Dual Track.

Dual Track is an approach to product development that treats Discovery and Delivery as parallel yet complementary activities. In the traditional development model, it is common to go through an initial planning phase (Discovery) and only then begin development (Delivery). In Dual Track, by contrast, the two processes run simultaneously and continuously, allowing what is learned in Discovery to feed Delivery and vice versa, in a more dynamic and iterative way.

An overview of the approach

The Dual Track approach combines the Discovery and Delivery processes and helps us find our way through the labyrinth that is building a product. These two paths are like two sides of the same coin: one focuses on discovering what needs to be done, the other on making sure it is delivered in the best possible way. The balance between these two dimensions is what leads us to success.

Problem Discovery

But I’ll tell you, the Discovery side — where it all begins — is especially challenging. It is the space where ideas take shape, but also where we face the chaos of uncertainty. Here we are dealing with the famous “what if…?”. What if customers don’t like it? Will we be able to generate revenue with this solution? Or, in the second stage of Discovery: can we actually build this? Will people know how to use it?

These are the questions that guide our process. Richard Feynman, whom I always make a point of citing, taught us that the path to finding answers begins with a guess. First we make a hypothesis; then we experiment, test and compare it against reality. If it holds up, we move forward. If not, we go back to the drawing board and try again. The catch is that, contrary to what many might think, that first guess is not easy. The confidence born of not knowing is a treacherous trap. And this is where a line I often repeat comes in:

“A guess, though it is the first step of science, must never underestimate the confidence born of not knowing.”

This “not knowing” can lead us to believe we know more than we actually do — a phenomenon very well explained by the Dunning-Kruger Effect, which I discussed here [The Dunning-Krugger Effect in Learning Computer Science]. When we are unskilled at something, we lack the very awareness needed to recognize how unskilled we are. In short, the less we know, the more confident we are. This happens in product development all the time.

At the start, when an idea seems brilliant, we get excited, but we don’t yet know enough to see the traps and challenges ahead. Sometimes we believe the problem is clear and the solution obvious — and that is exactly when Discovery humbles us (in a good way). That is why Problem Discovery matters so much. It forces us to stop and genuinely ask: “Is this something people really want? Will they pay for it? Are we solving the right problem?”

Solution Discovery

Then comes Solution Discovery, where we ask ourselves: “Now that we’ve found the right problem, can we solve it efficiently? Will the solution be intuitive for users? Can our technology handle it?” On this journey, we need to be open to criticism and ready to change when the evidence shows us we are wrong. And that brings me to another reflection: as I said before, had we been taught from an early age to embrace criticism and to change our minds in the face of new evidence, our society would be very different.

This openness to the new is the heart of Discovery. Deep down, we are not merely discovering a product; we are discovering more about the problem, about our ability to solve it and, above all, about our own limitations. And when we finally make it through Discovery and into Delivery, we are not merely building a product. We are building something that has been tested and validated along the way, with the humility of those who know that new evidence may always surface and make us rethink. Because, as Feynman said, “it is not the law itself that matters, but how it compares with reality.”

We can conclude that Dual Track is not merely a design or development process. It is a process of self-knowledge. And as long as you are willing to test, to get things wrong and to learn from what the world shows you, you will be on the right path to building something that truly matters.

Delivery

If Discovery is the realm of uncertainty and hard questions, Delivery is the stage for execution and concrete results. In product development, Delivery is where the ideas that were discovered and validated take shape, leave the drawing board and reach users’ hands. That does not mean, however, that Delivery is merely mechanical execution; on the contrary, it is a process that demands as much care, adaptation and learning as Discovery does.

The essence of Delivery is to ensure that the solutions identified in Discovery are implemented with quality, efficiency and focus on the defined goals. This is where engineering practices, project management, agile methodologies and, above all, a mindset of continuous improvement come in. Here, teamwork becomes vital, because it is the collaboration among designers, engineers, product managers and other stakeholders that turns abstract visions into real, impactful products.

A critical aspect of Delivery is constant feedback. Although it is a process of execution, it must not be cut off from new discoveries. Tools such as performance metrics, success indicators and direct interaction with users help identify needed improvements and adjustments, creating a continuous learning loop that connects Delivery back to Discovery.

Delivery also reminds us of the importance of balancing scope, schedule and quality. It is often necessary to prioritize and negotiate, shipping incremental versions that solve the core problems while paving the way for future improvements. This is not a sign of poor planning, but rather of the dynamic reality that characterizes product development.

Conclusions

Dual Track is not merely a methodology; it is a philosophy of work that combines the rigor of Discovery with the discipline of Delivery. This approach teaches us that success in product development depends not only on good ideas or flawless execution, but on the ability to integrate learning and building into a continuous, dynamic cycle.

Discovery challenges us to face uncertainty, to question our assumptions and to embrace criticism as part of growth. Delivery, in turn, invites us to turn those discoveries into reality, keeping an open mind to adjust and improve whenever necessary. Together, these two processes create a flow that delivers not just functional products but meaningful solutions that genuinely make a difference in people’s lives.

In the end, Dual Track shows us that product development is, above all, a journey of learning and growth. By balancing the possible, the feasible and the desirable, we are able to build not only better products, but better processes and better teams. And that, more than anything else, is what makes product development work so challenging and so rewarding.

References

[1] C. D. C. P., "Product Management: Balancing the Possible, the Feasible and the Desirable," Blog. Available at: https://www.cdiego.com. Accessed: Sept. 18, 2024.

[2] R. P. Feynman, O Fantástico Sr. Feynman. Documentary. Available at:https://www.youtube.com/watch?v=BHoPO4qrRGA. Accessed: Sept. 18, 2024.

[3] D. Dunning and J. Kruger, "Unskilled and unaware of it: how difficulties in recognizing one’s own incompetence lead to inflated self-assessments," Journal of Personality and Social Psychology, vol. 77, no. 6, pp. 1121–1134, 1999. DOI: 10.1037/0022-3514.77.6.1121.

[4] C. D. C. P., "The Dunning-Kruger Effect in Learning Computer Science," Blog. Available at:https://www.cdiego.blog. Accessed: Sept. 18, 2024.

[5] J. Gothelf, Lean UX: Applying Lean Principles to Improve User Experience. Sebastopol: O’Reilly Media, 2013.

[6] T. Brown, Change by Design: How Design Thinking Creates New Alternatives for Business and Society. New York: Harper Business, 2009.

[7] R. K. Yin, Case Study Research: Design and Methods. 5th ed. Thousand Oaks: SAGE Publications, 2014.