![\"Product](\"https:\/\/www.jamasoftware.com\/media\/2019\/07\/the-fine-line-product-engineering-teams_1024x512.jpg\")
<\/p>\n<\/p>\n
A product team and an engineering team could be viewed as two sides of the same product development coin. So, ask yourself, \u201cWho only uses half a coin?\u201d It\u2019d be like using just one side of your brain.<\/p>\n
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.<\/p>\n
In the rush of product development, it\u2019s 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.<\/p>\n
Before the first line of code is written, someone needs to own the product and fully understand what\u2019s being built and why.<\/em><\/p>\n It\u2019s 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<\/em> want?<\/p>\n Product teams tend to dream big, but they must also manage expectations and align goals with those of the overall business. That\u2019s why it\u2019s a good idea to get an engineering lead involved early in the planning process to build cross-team cohesion.<\/p>\n For example, if you\u2019re building the next great blogging platform, maybe your commenting mechanism is the \u201ckiller feature\u201d 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.<\/p>\n It\u2019s 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).<\/p>\n 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.<\/p>\n We\u2019ve probably all been in a meeting where something ambitious is proposed and the engineering team rolls their eyes, thinking, \u201cIf we could build that we\u2019d all be zillionaires.\u201d The balance here is one of awareness.<\/p>\n Technical teams need to be just as ambitious as their product counterparts, and that means understanding a little bit of each other\u2019s worlds to know what\u2019s feasible and what will cause deadlines to crash.<\/p>\n https:\/\/resources.jamasoftware.com\/blog\/a-guide-to-good-systems-engineering-practices-the-basics-and-beyond<\/p>\n The rubber meets the road when the product team hands off specifications to the people who will actually build the thing.<\/p>\n 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\u2019t mean micromanaging from the product team, but it does mean regular check-ins to increase buy-in, build cohesion, and avoid surprises.<\/p>\n Going back to our blogging platform example, let\u2019s 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.<\/p>\n However, they could just as easily warn the product team that there are backend issues to tackle to enable those frontend goodies. There\u2019s 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.<\/p>\n When teams understand that they\u2019re on the same side, everyone can take a step back to see the full map and make sure they\u2019re headed to the same destination. It\u2019s also where teams who understand each other excel.<\/p>\n Product must comprehend the engineering team\u2019s needs, and engineering must grasp the importance of the product planning that came before. Maybe it\u2019s 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.<\/p>\n 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.<\/p>\n If all of this sounds familiar, you\u2019re not alone. Everyone in these teams is working under a number of different dynamics.<\/p>\n 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.<\/p>\n
\nRELATED: <\/strong>A Guide to Good Systems Engineering Practices: The Basics and Beyond<\/a><\/span><\/span><\/h4>\n
\nThe Engineering Team<\/strong><\/h2>\n
\nRELATED: <\/strong>The Complete Guide to the Systems Engineering Body of Knowledge (SEBoK)<\/a><\/span><\/span><\/h4>\n
\nOne Team<\/strong><\/h2>\n