Building true product-engineering partnership at scale

Marty Cagan says you need one product manager for every 6-10 developers. I currently work with a ratio of 1:16, coordinating engineers across the US, Mexico, India, and Kenya to build products that serve millions of customers. Traditional PM wisdom would suggest this is challenging.

It's not — but only if you completely rethink the product-engineering relationship.

Most companies treat product managers as translators and engineers as implementers, creating a coordinator-executor dynamic that breaks down the moment you try to build anything complex. The most successful technical products don't emerge from PMs "managing" engineers or engineers building in isolation. They come from true intellectual partnership where both sides co-create solutions.

This requires fundamentally rethinking the PM-engineering relationship from handoffs to strategic collaboration. And when you get it right, it doesn't just work — it scales exponentially.

Why handoffs fail

Walk into most tech companies and you'll find the same tired dynamic: Product managers present wireframes and user stories to engineering teams who take notes, ask clarifying questions, and head back to their desks to start building, while product managers move on to the next feature or strategy without staying engaged throughout the process.

The result? Products that technically work but miss the mark. Solutions that address symptoms rather than root problems. Features that meet the written specifications but don't actually solve the customer need. Both sides end up frustrated. Engineers wonder why product decisions seem disconnected from technical reality, while product managers struggle to understand why perfectly reasonable requirements are so difficult to implement.

This coordinator-executor model assumes that product strategy and technical implementation are separate concerns. That product managers think about the "what" while engineers think about the "how." That we can draw clean lines between business logic and technical architecture.

But from my experience working closely with engineering teams, the "what" and the "how" are inseparable. The best products emerge when product managers and engineers think together about both.

What true partnership actually looks like

Real partnership isn't just better communication or more frequent standups. It's a fundamental shift in how decisions get made.

In the partnership model, engineers are problem solvers who understand customer needs and business constraints as deeply as you do. Product managers are technical collaborators who can engage meaningfully in architecture discussions.

At Tala, a financial platform serving millions of underserved customers globally, this meant bringing our tech leads directly into conversations with credit and legal teams to understand regulatory constraints around our new installments product.

Instead of me liaising between teams and handing off feedback to engineering, we collaborated directly. Tech leads could ask pointed questions about requirements while I pushed on what was absolutely required versus flexible. This shared foundation led to a robust technical design that saved us implementation headaches later on.

We took the same approach with our analytics engineering team, spending 3-4 hours across multiple sessions defining data requirements and success metrics. Working upfront with analytics engineering, credit, data science, and my product engineering leads crystallized how our metrics and terminology would evolve across different products.

The analytics engineering team later told us this front-loaded investment made their data infrastructure design remarkably smooth — one of the most successful product analytics partnerships at Tala.

The magic happens in these collaborative moments. Engineers bring insights about technical possibilities and scalability. Product managers bring perspective on user behavior and business priorities. Together, we create solutions that neither side could have imagined alone.

The partnership playbook

Building this kind of partnership doesn't happen overnight, especially when working with large, distributed teams. But there are practical approaches that can accelerate the process.

Start with shared understanding

At the beginning of our instalments project, I spent significant time articulating why this mattered for our customers and for Tala as a company and what success looked like, before diving into product requirements or technical specifications. My engineering manager and tech leads joined our weekly cross-functional working sessions, where we discussed other aspects of the project like go-to-market strategy, learning plans, and test design. This ensured they saw the full picture of the project throughout the months of implementation and development, not just at the beginning. They were involved in weekly meetings with cross-functional teams, maintaining context and giving feedback on how we were bringing this product to life.

Crucially, engineering had meaningful input when setting timelines and deadlines. Rather than top-down deadline mandates, we collaborated closely to define the MVP scope we believed we should launch to customers. From there, we estimated effort together and worked with program management to project realistic timelines based on our team size. This collaborative approach to scoping and estimation meant we set deadlines we were confident we could meet while delivering quality.

This foundation becomes the bedrock for every decision that follows. When we hit inevitable trade-offs during development, everyone can reason from first principles rather than blindly following a pre-written spec.

Create rituals for joint problem-solving

Traditional agile ceremonies optimize for coordination: standup updates, sprint planning, retrospectives. Partnership requires different rituals designed for collaborative thinking.

We instituted twice-weekly "Tech Syncs" where engineers and I spend 30 minutes to an hour exploring and working through complex technical problems. Not planning how to implement a predetermined solution, but genuinely exploring the problem space together. In these sessions, we made decisions like deprecating an endpoint from the original design after realizing another endpoint could handle multiple scenarios, or refining amortization calculation logic to ensure it captured edge cases and remained foolproof.

We also established no-meeting days during the week, protected time for engineers to do deep work without distractions. This created a culture of trust, empowering engineers with dedicated focus time while knowing we have regular ceremonies and tech syncs to connect as a team. Because we honored these rituals throughout most of the project, it felt natural to be more flexible with scheduling when we hit crunch time and needed quick calls as needed.

Create a culture of safe accountability

The tactical stuff only works if you have the right team culture. Working with my engineering manager and tech leads, we intentionally built an environment centered on three pillars: ownership and accountability, psychological safety, and executional excellence.

This means engineers can safely challenge product decisions when they see better technical solutions. It means I can push back on implementation approaches that potentially add scope creep for scenarios that have less likelihood of happening. Everyone feels empowered to ask hard questions, propose alternatives, and have honest conversations about trade-offs.

But psychological safety without accountability breeds mediocrity. We pair that openness with clear ownership and high execution standards. When someone commits to delivering something, the team trusts it will happen with excellence.

This culture becomes crucial when we hit difficult moments. When tensions rise around timeline pressures or technical complexity, we can address issues directly instead of letting them fester into broader team dysfunction.

The multiplier effect: Why this approach scales

The benefits of true product-engineering partnership extend far beyond any individual project. Engineers who understand customer problems make better technical decisions, identifying improvements that directly impact user satisfaction and business performance. Product managers who develop technical intuition scope projects more accurately and communicate more effectively with product and engineering leadership about resources and timelines.

Most importantly, the partnership model creates shared ownership. Everyone feels accountable for building something that works beautifully for customers and scales for the business.

The transition from coordination to partnership isn't always smooth. It requires vulnerability, patience when communication styles clash, and a willingness to challenge assumptions about how product development should work.

But when it clicks — when you're collaborating with engineers who feel as invested in customer outcomes as you do, solving problems you couldn't tackle alone — you realize you've unlocked something powerful.

True partnership builds better teams, accelerates delivery, and creates sustainable competitive advantages that compound over time. Your customers deserve that level of collaboration. Your engineering team is probably craving it too.