Introduction
In any technology organization, large or small, you are bound to run into “healthy friction” between groups. This is inevitable because different organizations are incentivized on different (and sometimes conflicting) outcomes. Even with good intentions, those incentives often cause tension and disagreements across teams. If not addressed early, these disconnects can quickly escalate and derail an organization’s culture while impacting the bottom line. Let’s take a look at one of the more common areas of organizational conflict: Product Management vs Engineering.
Do any of these sound familiar?
-
“The requirements from product management are too fuzzy and it’s causing us to miss our deadlines.”
-
“Engineering is too hard to work with; they aren’t flexible at all as we keep getting revised inputs from customers on what they want.”
-
“You can’t put a placeholder for a feature on a product roadmap just because customers want it – we need to fully vet it first.”
-
“We’re losing market share to our competitors because they launched first, even if the quality wasn’t perfect.”
-
“Do you want me to fix the bugs or add new features?”
-
“The release date is the release date; fit whatever you can into it, and we’ll do a minor release afterwards.”
What’s Happening Now
Whether in a large company or a startup, evolving a mature product or creating a brand-new market-disrupting solution, there is always some friction between product managers who design the product (or service) and the engineers who bring it to life. You cannot have movement without friction. In cases of services development, the product could be an offer related to subscription services consumed digitally, professional services packaged around outcomes, or support services that meet specific service level agreements.
Regardless of the methodology, organization structure, or industry, there is usually a clear delineation between these roles. What is rarely understood, however, is that healthy tension between product management and engineering is REQUIRED to turn out the best possible product or service. Finding the perfect and negotiated balance between engineering’s quality and speed of development vs. product management’s customer-centricity and market imperatives will ensure a product that is high quality, ahead of the market, and meets customers’ emerging needs.
Product Management vs Engineering
Product managers are (or should be) completely customer-centric – answering questions like, What is the experience of the end user using the platform? How can we provide the best outcome, most efficiently? They are responsible for looking at market dynamics including competitor roadmaps and features, pricing, and market segmentation (for example, how does the product fit into a large enterprise’s buying motion vs. a small/mid-sized business?). They are measured on metrics like the revenue and profitability of a product or service, market share, product launch dates, and adoption.
Engineering teams are responsible for building the solution per the product team’s requirements, while meeting product quality, performance, scalability, security, and compatibility objectives. They must also support the product, provide enhancements, perform different types of testing to ensure product quality, and tackle any security risks that arise. Especially in smaller companies, engineering teams struggle to find a balance between meeting product management feature requests and time-to-market goals, meeting product quality requirements, providing second- and third-level product support, working through bugs and issue backlogs, and addressing critical security alerts.
The Challenges
Let’s take a typical product development cycle. Things usually start off well, like in a honeymoon phase, when everyone is seeing the bright possibilities of what could be a market-defining product – everyone is bought into the vision, the market gap, and the concept of what will definitely be a hit in the market. Even the first few iterations of ideation, design, and prototyping usually go smoothly, with the first epics and user stories resulting in a broad realization of the product vision.
Then the problems start. The backlog starts to grow and the development teams are busy building the elements of the solution that will eventually grow into the full-scale feature set. But then the product managers start to get more details from customer surveys and early adopters about how they plan to use the product, and changes are introduced. Also budgets change, and senior leaders start asking to accelerate revenue to achieve quarterly goals, or to cut costs to hit margin targets. Product owners in the scrum teams are caught in the middle, trying to ensure the development teams stay on track and deliver tested, high-quality code and hardware. Scrum calls and retrospectives start to get a bit tense, maybe even heated, as different viewpoints emerge about how to continue to build the solution. At this point, Sales team members may start to interject and ask for changes as they start to show the solution to customers in order to build pipeline and hit their own quota targets. After a few weeks, things could spiral out of control with different factions being very vocal and arguing about the inhibitors to success being caused by the other groups.
Some Potential Solutions
So what can you do to fix this and get the teams working cohesively again – or, better yet, avoid the problems in the first place? While there is no simple answer, the key is to make sure the problem does not grow too big to begin with. Here are some ways to get ahead of this critical issue.
If you’re the general manager or executive sponsor/owner of the program, ensure that there is frequent and open communication across all stakeholder groups. Try to eliminate any surprises; if there is a customer survey being done in a few weeks, ensure that there is representation from Engineering (and Sales and any other key stakeholders) in the survey process, and ideally include them in the design of the survey. Review the results of the survey with the teams together, with the product team leading the discussion. Craft a plan to act upon the survey results with buy-in from all the teams, so it is a group effort rather than a single team’s initiative. Through effective communication, collaboration becomes a natural outcome.
Have Aligned Targets and Metrics
Find metrics that align both PM and Engineering and provide incentives when those metrics are met. For example, don’t just have a release target deadline that the Product team sets; also include a specific quality target aligned to that specific release; for example: Release version 1.5 on June 1, meeting all product defect standards, and achieve a minimum score of 7.5 out of 10 in the subsequent customer satisfaction survey. This will ensure that the leaders of both the product management and engineering teams are invested in both the time and quality aspects of the release.
Speak to Executive Management as One Team
For large or public companies, regular reporting to the executive leadership team is common; with start-ups, reporting is often to the board of directors and/or investors. Regardless, one tactic to drive alignment between product management and engineering is to have them jointly report on the product roadmap and its status. Even if they have to position challenges for board feedback, doing it together reinforces the leadership behavior that needs to be pervasive to drive healthy problem solving and rapid progress.
Implement Role Rotations
One of the best methods to avoid an us - vs. - them mentality is to do periodic rotations of key people across different roles, particularly in Product Management and Engineering. There is no better way to understand and appreciate someone else’s point of view than to walk a mile in their shoes. Even spending one or two sprints on the other team, or giving a technical developer an assignment to interview and document feedback from your top ten customers, or traveling with a salesperson to customer sites and seeing how the end users actually use your products, will help bring the larger perspective into focus. Then you will start to seed cross-functional behaviors and perspectives, and this will also give you the added bonus of developing the next generation of general managers.
Utilize Technical Project Managers
In typical Agile development teams, the product owners interface between the development (Engineering) teams and the other functional teams including Product Management. For large programs, especially transformation initiatives that impact large product portfolios, there are also project and program managers that oversee the development progress, eliminate obstacles across teams, communicate progress, and provide cross-team coordination. One common trap that organizations fall into is to assume that these project managers are highly interchangeable across any type of program. Not so! The most valuable project managers speak the language of the product and development teams, and can quickly resolve issues with the right stakeholders because they understand the environment, terminology, and overall objectives of the program. Ensure that the project managers working on your most critical initiatives have a solid background in that field, and ideally have worked on similar programs. A good way to source these key resources is to invest in rotations (above) and grow your team members vertically (within a particular domain) as well as horizontally (across domains). After a few rotations, they will have a much better appreciation for the “big picture” as well a better idea of where they would like to specialize in their career.
Some Final Thoughts
The above examples are a few ways for leaders to ensure healthy checks and balances across teams. Pressure to deliver results, especially from other groups within your organization, can be a great stimulant to foster innovation and growth. However, it can quickly degrade into animosity and distrust between teams if not managed effectively. While some proposed solutions are easier to implement than others, it is imperative that you tackle cross-team collaboration issues very early in the lifecycle of any large program, and check the pulse of the dynamics frequently to catch any issues before they become disruptive. A culture of collaboration starts with appreciating the other roles in the organization, and it is up to the leadership team to provide an environment where innovation and talent can thrive, while allowing healthy interplay. Once you set up your teams so that they trust each other and work together to overcome obstacles, innovation and great products are a natural outcome.
Have you experienced challenges like these on your teams? If so, please leave a comment and let us know what worked in your situation. We would love to hear from you.