Skip to content
Engineering Investment and Business Alignment

How to Build a United Front between Product and Engineering

It’s well known that companies struggle to get the dynamic right between Product and Engineering. Pulling from their years of experience in technical leadership, Andrew Lau, CEO and Co-Founder of Jellyfish, and Srinivas Krishnamurti (“SK”), Head of Product at Productboard, divulged their thoughts during a fireside chat on what works and (what doesn’t) when it comes to fostering productive collaboration. You can catch the full replay below, but we would also like to share some of the “best hits” from their discussion a few weeks ago.

Describing the breakdown between Product and Engineering

Andrew and SK started the conversation by describing what a communication and alignment breakdown actually looks like.  

Andrew: People forget that engineering and product are largely constructs that we’ve invented for ourselves as software companies. But when your CFO looks at those buckets from a financial perspective, it’s all the R&D line item. Ultimately, they are a means to achieve something which is to make something that customers want to use, want to buy, really make them happy and delighted and tell their friends about it.

You can start to see these two teams breakdown though when you walk into a management or board meeting. You get to the product and engineering portion of the presentation and the product head says, “These are the things that are going to come out in the next thing.”

Then the mic gets passed to the engineering head, and they’re saying, “Well, actually, those things aren’t actually coming out. There’s actually these three things.”

The net outcome is the company acts tentatively and doesn’t know who to trust. It looks uncoordinated over there. How does anybody else believe that function is operating cleanly?

SK: People at all levels of the company look at that not working. They look at it and say, ‘Well, the adults are not able to get their stuff together.’ I’ve actually seen retention issues come out of that lack of alignment, or just ultimately the product that we ship is just going to be not great. 

But let’s not forget the number one person that you mentioned there is the customer. They can smell it in the product when it feels inconsistent. 

Where the divide between product and engineering comes from

Solving for the relationship challenge requires leaders to identify the source of the conflict. SK gave his thoughts on where the root of the issue may lie.

SK: Two things come to mind. If there’s an imbalance in their seniority or experience between the Heads of Product and Engineering, unconsciously, they will try to push their agenda forward. That’s the biggest one that I’ve seen and also the hardest one to fix.

I’ve also seen some seasoned engineers say some version of, “Yeah, I get it. I talk to a couple customers every quarter. I get what the market needs. I can make decisions.”

And vice versa, PMs look at engineering and think ‘They are not out there talking to customers. They don’t really understand. I’m just going to tell you what to do. They’re just a feature factor. Just go build what I tell you to.’ They’re not empowering them or taking their views into consideration.

Ultimately, the two functional groups need to be equal. And if they’re not equal in whatever way, then stuff goes sideways. 

Why we’re better as a unified front

SK and Andrew agree that it’s important for these two teams to collaborate early and often. When unsure whether to bring your peer in to weigh in on something, they feel strongly that you should ask the question. 

SK: I feel that there is a simplified distinction between Product Management (PM) and Engineering. PM is responsible for defining what to build, why we build it, and why now. Engineering is responsible for how we’re going to build it, and when. So, engineering needs to own and be accountable for the delivery dates. 

But I don’t think it’s the right thing for PMs to go off to an offset, come back with product strategy, and expect engineering to just execute on that. That’s a recipe for disaster. Fundamentally, I believe in getting people involved early, allowing them to put some skin in the game. 

Andrew: You’re emphasizing the buy-in part of it, and I totally agree, but I think there’s potentially an even more business-optimal reason to do so. 

We said earlier that Product is constantly making trade-offs. You’re making trade-offs of a benefit versus cost. But fundamentally, who knows costs better than the engineers? Product has an instinct for the benefits side of the equation, but you may not live in and breathe in on the cost part of it like Engineering does. If engineers can understand the real problem and what you’re trying to get to, they will probably build a better solution than the PM could actually think about. 

These are just a handful of insightful moments from the nearly hour long discussion. For more discussion regarding how to build a united front between these two groups, watch the full webinar replay. But whether you’re an engineering or product leader, there’s one thing that we can all agree on:  Productboard and Jellyfish go together like PB & J. 

For information about Productboard and Jellyfish, visit and