𝗣𝗿𝗼𝗱𝘂𝗰𝘁 𝗠𝗮𝗻𝗮𝗴𝗲𝗿𝘀 – 𝗢𝘂𝗿 𝗲𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝘀 𝗮𝗿𝗲 𝗼𝘂𝗿 𝘀𝘂𝗽𝗲𝗿𝗽𝗼𝘄𝗲𝗿.

I’ve often realized that no matter how great my solution seems initially, when I discuss it with the tech team, they frequently come up with an even better, more scalable solution.

It’s not always easy to involve engineers in every step of the discovery process, but I’ve found that the earlier they are included, the better. Once I’ve identified a problem, involving them in solutioning leads to amazing outcomes. When still in the discovery phase, having engineers—or at least one engineer—join the discussions has proven invaluable. Their perspective is often far more holistic.

Engineers excel at identifying the underlying complexities of a problem. Their ability to think about constraints, edge cases, and future scalability ensures that solutions are both practical and forward-looking.

Recently, I was working on a travel solution focused on developing the Activities product. One of the challenges was integrating transfers with sightseeing. Initially, the solution we designed was tightly coupled with the Activities product itself. However, the tech team suggested a more flexible approach: building the transfer functionality as an independent module that multiple systems could reuse.

This wasn’t just a module anymore—it became a microservice. Now, other products like hotels and flights can also utilize the transfer module. This shift has unlocked new opportunities for the product team to explore.

Could we have thought of this ourselves? Possibly. But this kind of thinking comes naturally to developers when it comes to architectures and scalability. Their ability to design for reusability and long-term growth often leads to outcomes we might not have considered initially.

Developers are highly time-sensitive and consistently strive to optimize the output of their efforts. They focus on applying the 80-20 rule, targeting the most impactful work to achieve maximum results. This mindset often enhances the feedback we receive, pushing us to think critically about our solutions.

In one instance, we were creating a duplicate workflow for users that, from both a product and user perspective, seemed necessary. Since the product was designed for two different departments, having a duplicate UI appeared acceptable, as it was part of two distinct modules serving separate functions within the company. However, the developers flagged this as unnecessary duplication and raised concerns about the effort required.

After hours of discussion, we were both challenged and convinced to reconsider our approach. This led us to a deeper insight: the workflows of these two departments were interconnected, as the work of one department naturally transitioned into the other. By integrating the workflows instead of duplicating them, we created a more cohesive system that required significantly less effort while delivering a more optimized and effective solution.

Another big advantage of presenting ideas to developers is that it pushes me to dig deeper and gather stronger evidence to support my product claims. Developers naturally challenge assumptions by asking for more data, user stories, and anecdotes that justify the need for a feature. They ask pointed questions like, "What problem are you solving?", "What percentage of users will benefit?", and "What metrics will improve as a result?" These questions often reveal gaps in the discovery process, where some data may not have been fully validated or certain assumptions were taken for granted. This level of scrutiny ensures that every decision is rooted in clear, well-supported reasoning.

No matter how thorough the initial product discovery phase was, engaging with developers often uncovers overlooked details or untested assumptions. It’s a humbling yet invaluable process that strengthens the overall product strategy. Developers bring a fresh perspective that ensures features are not only feasible but also impactful and aligned with user needs. While these discussions can be challenging, they lead to more refined solutions and a deeper understanding of the problem. In the end, this collaborative effort results in better products and, most importantly, happier customers who feel their needs are truly addressed.

The next time you’re working on a product feature, consider these key benefits:

Early Involvement = Better Solutions: Engaging engineers early in discovery enables them to understand the "why" behind the problem. They can often identify opportunities for reuse, optimization, or a completely different approach you might not have considered.

Diverse Perspectives Matter: Product managers often focus on the "what" and "why," while engineers bring the "how" into the equation. Their involvement creates a more holistic approach to problem-solving, balancing user needs, technical feasibility, and business goals.

Avoiding Local Maxima: Engineers often have a knack for stepping back and seeing the bigger picture. They may challenge assumptions or constraints that could lead to suboptimal solutions, helping the team explore more ambitious and scalable options.

Building Ownership: When engineers are part of the discovery and solutioning process, they feel a stronger sense of ownership. This engagement leads to better collaboration, motivation, and execution.

Foster Collaboration, Not Silos: Create a culture where engineers feel empowered to challenge ideas and contribute beyond implementation. Show appreciation for their contributions, emphasizing how their insights make a tangible difference for users.

Involving engineers early has always amazed me with the solutions they bring to the table.