How engineering and product should work together

You’ve probably heard the phrase: “Great products are built at the intersection of product, design, and engineering.” It’s neat and logical but very hard to replicate in reality. In reality, this intersection can feel more like a roundabout.

Misalignment between product and engineering is one of the most common (and costly) issues in startups. Roadmaps can slip and features can launch half-baked, leading to frustrated teams, customers and investors. The root cause isn’t bad intentions – more often, it’s a lack of shared understanding about how these two functions should actually work together.

Jono Hey, one of our Brighteye Product mentors, commented:

"The key point here is Engineering and Product need to collaborate, not work separately."

What does good collaboration between product and engineering look like and how do you create it?

Start with trust, not tickets

The best product–engineering relationships begin with trust.

For a product manager, this means ensuring engineers are a part of product conversations as early as possible, anything is specifications, prioritised, or committed. It means treating them not just as executors, but as partners in solving problems.

Jono shared:

"Product won’t know the best solutions because they don’t know what’s possible. And engineering won’t know what the right problems are to solve without context. Product must ensure that Engineering has enough context to bring their full problem-solving expertise to the table. Treating Engineering like a machine that delivers tickets is like working with one hand tied behind your back."

When product leads share context about users, business goals, and constraints, product and engineering teams can bring ideas to the table and be a valuable part of the decision-making process.

They also want to build things that matter, both to the company’s success and to your customers. The more impactful the project, the more excited your teams will be to bring it to life.

As Jono puts it:

"The best engineers don’t want to just build things - they want to solve real problems. That starts with giving them context."

If teams are constantly being handed a list of pre-defined tasks, you're not using their full set of skills and also likely not motivating them in the most effective way. Building great companies and great products is a team sport, so you’ll need to know when to engage and support progress and when to not.

And on the flip side, product managers need to earn trust too. That starts with being clear about goals, transparent about trade-offs, and willing to listen when engineering pushes back.

Define roles, but stay flexible

You’ll hear a lot of debates about roles: Who owns “the what”? Who owns “the how”?

But there does need to be a default. In our view:

• Product leads the “what” - the problem to solve, the user it matters to, and the outcome you’re aiming for.

• Engineering leads the “how” - the technical approach, architecture decisions, and delivery plan.

In Jono’s words:

"Product gives context, engineering gives possibility. You need both to build anything great."

In practice, the best teams blur those lines while still maintaining accountability. Product managers should deeply understand feasibility. Engineers should care about user impact. Everyone should feel empowered to challenge assumptions.

The danger isn’t in overlap, it’s in ambiguity. Inertia arises when no one knows who’s accountable.

Communication: more than stand-ups

Strong product–engineering partnerships don’t rely on process alone and instead rely on communication.

In practice, this means real-time chats about ideas, risks and decisions. It means shared documents, early feedback, and constant iteration. It also means surfacing tension before it festers…

A good test: Can your PM and tech lead disagree without derailing the team? If not, you’ve got a trust issue to fix.

Jono shared this pearl:

"Healthy teams disagree all the time - but about the work, not the people. That’s the difference between conflict and dysfunction."

Also: if the only time your engineers hear about user feedback is in a retro, we think you’re missing a trick. Engineers build better things when they feel the user’s pain.

Jono Hey gave us his take:

"The best way to give engineers context is to get them close to customers. Invite engineers to customer visits and interviews. Listen to customer calls together. Have them spend time with sales, operations and customer support. Watch user recordings together. Build and review dashboards to measure feature impact together. The more context engineers have, the better motivated and better positioned they will be to solve problems in the smartest way. The more engineers can appreciate the customer’s pain, the better their solutions will be."

Get them into user interviews, share recordings and help them see the impact of their work. This enables them to be more critical and thoughtful during the building process, bearing user voices in mind throughout the process.

Avoiding the “Us vs. Them” trap

The most damaging dynamic in any team is when product and engineering start blaming each other. “Product doesn’t understand how long things take.” “Engineering always says no.” Once that divide sets in, collaboration breaks down.

Jono commented:

"The closer everyone feels to the company's mission, the easier it is for teams to keep conflict from being personal and make it healthy conflict about what's best to do, as you all ask, 'What would be better for our customers?'"

Culture matters here and it’s important to celebrate and enjoy shared wins. Failure happens, too, so share those failures too. Success is collective - and so is accountability.

As Jono puts it:

"The closer everyone feels to your customers, the easier it is to make decisions without internal tensions."

Founders should be setting the tone and should both challenge and trust the decisions of their teams, on estimates, roadmaps and apparent perceptions of teams. If a founder appears to favour one team over another, it can ripple through the whole team. Founders should try to avoid being perceived king- or queen-makers.

As you scale

In early-stage startups, product and engineering are often one messy blur. But as teams grow, they’ll need clearer rituals and expectations.

Start with:

• Joint sprint planning that includes both product goals and technical considerations.

• A shared product–engineering plan or doc for each big initiative.

• Regular syncs between product and engineering leadership (even if that’s just two people).

It’s worth bearing in mind, though, that the goal isn’t a perfect playbook. It’s healthy tension, mutual respect, and a shared obsession with building the right thing well!