Building a united front between product and engineering

Building 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, and really makes 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 next.”

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 ultimately the product that we ship is not going to be 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 the 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 factory. 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 peers in to weigh in on something, they feel strongly that you should bring them into the loop. 

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 and 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 and breathe 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 a head of product, or a head of engineering, there’s one thing that we can all agree on, Productboard and Jellyfish go together like PB & J. 

For information about Jellyfish, visit jellyfish.co

You might also like

How to Craft an Effective Enterprise Product Strategy
Product Management

How to Craft an Effective Enterprise Product Strategy

Productboard Editorial
Productboard Editorial
Product Portfolio Management 101
Product Management

Product Portfolio Management 101

Productboard Editorial
Productboard Editorial
Tips & Strategies for Mastering Agile Product Management
Product Management

Tips & Strategies for Mastering Agile Product Management

Productboard Editorial
Productboard Editorial