Product Development & Management

Where’s the Fine Line Between the Product Team and the Engineering Team?

By |

Product Team

A product team and an engineering team could be viewed as two sides of the same product development coin. So, ask yourself, “Who only uses half a coin?” It’d be like using just one side of your brain.

In a perfect product development world, communications are seamless, specifications are clear, and product and engineering teams work without friction. Except, we live in the real world where life is messy, responsibilities overlap, specifications change, and the way teams interact can introduce friction.

In the rush of product development, it’s important to establish boundaries for each team while also working as a unit and develop processes to head off trouble before it begins. This only gets more complicated with bigger and more technical projects.

The Product Team

Before the first line of code is written, someone needs to own the product and fully understand what’s being built and why.

It’s the product team that should understand the why, inside and out. From ideas that turn into research that guides specifications to conversations with customers, the product team is lining up the rubber ducks in neat little rows so engineers can focus on the technical problems. What do the ducks look like? How do they sound when squeezed? And what do users want?

Product teams tend to dream big, but they must also manage expectations and align goals with those of the overall business. That’s why it’s a good idea to get an engineering lead involved early in the planning process to build cross-team cohesion.

For example, if you’re building the next great blogging platform, maybe your commenting mechanism is the “killer feature” and the engineering team needs to focus on issues like authentication and moderation tools. How much of the apple can we bite off at a time? Such questions circle back to product team responsibilities like the business goals and strategy. Prioritization is the byproduct of open talks between teams to determine what is needed and what can be delivered on time.

It’s also worth noting that tension between teams is a natural and healthy aspect of working cross-functionally. Each team has its own set of internal goals, but those must align with overall strategic goals for the company (or product).

The product manager serves as the CEO for whatever is being built. If he or she asks for the moon, there must also be the understanding of the challenges that await.

We’ve probably all been in a meeting where something ambitious is proposed and the engineering team rolls their eyes, thinking, “If we could build that we’d all be zillionaires.” The balance here is one of awareness.

Technical teams need to be just as ambitious as their product counterparts, and that means understanding a little bit of each other’s worlds to know what’s feasible and what will cause deadlines to crash.

https://resources.jamasoftware.com/blog/a-guide-to-good-systems-engineering-practices-the-basics-and-beyond

RELATED: A Guide to Good Systems Engineering Practices: The Basics and Beyond

The Engineering Team

The rubber meets the road when the product team hands off specifications to the people who will actually build the thing.

Engineering is the technical team of developers and managers who write the code and create the front end, so the clearer the guidance they get upfront, the better. That doesn’t mean micromanaging from the product team, but it does mean regular check-ins to increase buy-in, build cohesion, and avoid surprises.

Going back to our blogging platform example, let’s say there are some whiz-bang features on the front end that will dazzle users. A product manager might tell engineering to focus on those features. If the product team has done its job, the tech leads can accurately inform them how long it will take to implement the features.

However, they could just as easily warn the product team that there are backend issues to tackle to enable those frontend goodies. There’s no way to have one without the other, and this is another area where the tension comes in, as timelines might have to be readjusted.

When teams understand that they’re on the same side, everyone can take a step back to see the full map and make sure they’re headed to the same destination. It’s also where teams who understand each other excel.

Product must comprehend the engineering team’s needs, and engineering must grasp the importance of the product planning that came before. Maybe it’s a matter of a few sprints to see where the marquee feature is in a week. Or perhaps a lower-priority feature that really puts a kink in the line just needs to be delayed.

Either way, the only solution is to drop the egos and hash things out in realistic terms. Again, if product has done the job, both teams should be like looking at the release like a big X on a treasure map and walking there together.

RELATED: The Complete Guide to the Systems Engineering Body of Knowledge (SEBoK)

One Team

If all of this sounds familiar, you’re not alone. Everyone in these teams is working under a number of different dynamics.

It could be that product feels it has defined everything so thoroughly that the engineering team can take the ball to the goal after a simple handoff. Of course, that is rarely the case.

More likely, there’s a stream of reviews to comb through and see how things are advancing (which, if you’re using the right solutions, can be handled faster and with less meetings) while moving the goalposts when one side reports a change in the variables.

So, what do you do? Learn to function as one team while respecting each other’s territory. After all, you’re all headed to the same goal. Even if your organization compartmentalizes each side, find a way to cross the streams. For many, the move from Waterfall development to Agile created a more efficient, functional model for developers, and a variation on that theme can serve you here as well.

First, create a great set of fundamentals with your product team by bringing in engineers as early in the planning stages as possible. Ask what’s feasible and go to lunch and dream about unlimited budgets. Integrate the engineering team as best you can, because their insight will save squabbling down the road. Then create specifications that are realistic.

Next, empower each side of the table with respect. Product may want the moon tomorrow and engineering will explain how much lift is needed to get there, so friction is inevitable. In the big picture though, both sides are arguing for the same goal, so keep that front-of-mind and allow room for either side to concede territory as needed. Conflict is normal and necessary, but if one side is utterly powerless and is continuously overrun, the “team” notion falls apart and the idea of collaboration breaks down.

If both teams are aligned, truly listening and making necessary adjustments, there’s no reason even large, complex projects can’t be finished on time and on budget. It takes work, especially if an organization is averse to cross-functional teamwork.

The payoff, though, is happier, more productive teams who share in the product’s success. It’s up to both sides to come to the table ready to cooperate.

Does that mean having certain boundaries? Yes! It’s unlikely the engineering team has done the market research to say whether a feature is desired by users. And it’s equally unlikely that the product team will accept a major delay for technical implementation if it was in the original specification.

Each side has a job to do, but the key is understanding that everyone is marching under the same umbrella in the end. That’s why it’s important to play the role you’re in while listening and accepting the experience and knowledge of the entire team.


Jama Software
Latest posts by Jama Software (see all)