10x Product Tensions

How to Manage Product Manager Expectations and Foster Effective Team Collaboration

A frequent source of tension in technology organizations arises when a Product Manager (PM) questions the efficiency of an engineering team—even when that team consistently meets its agreed-upon milestones. Imagine a scenario where Allison, a development lead, finds herself in just such a predicament. Her team was tasked with creating a new inventory management tool, spending significant time exploring various technical approaches before settling on a clear direction. They then established milestones, shared estimates, and systematically delivered on each target. Despite all this, the PM accuses Allison’s team of being “underperforming.” His rationale? “I’ve seen a similar project done much faster before.”

Why do such disconnects happen, and how can leaders address them? In this blog, we’ll delve into the root causes of these perception gaps and propose strategies for improving cross-functional understanding. We’ll draw on key insights about scoping, communication best practices, and leadership principles to support a healthier dynamic between PMs and engineering teams.

1. Understanding the Core Conflict

In Allison’s case, her team only had a high-level directive at the outset: “build an inventory management tool.” Precise specifications and business requirements were still evolving. The project’s initial phase required significant experimentation to confirm architectural choices and validate different feature ideas. Once the approach was defined, the team:

1. Broke down the work into clear milestones.

2. Provided time estimates for each milestone.

3. Consistently met those milestones on schedule.

Yet, the PM expressed ongoing dissatisfaction. He claimed the team was “underperforming” based on how quickly he had seen “similar” projects completed in the past. From Allison’s viewpoint, the complexity of the new system, the experimentation phase, and unanticipated challenges all contributed to realistic timelines. To the PM, however, these explanations sounded like excuses.

Such clashes can arise for several reasons:

• Misaligned Perceptions of Complexity: The PM might underestimate the scope or overestimate the similarity to past efforts.

• Ambiguous Comparisons: Another project that appears identical at a glance might differ significantly in architecture, resources, or organizational support.

• Communication Gaps: Daily stand-ups may focus on micro-level tasks, leaving strategic or big-picture misalignments unaddressed.

• External Pressures: The PM may be under intense executive scrutiny or facing unspoken deadlines that ratchet up timeline anxiety.

Both sides can have valid perspectives. The PM wants faster results, possibly due to stakeholder expectations, while Allison’s team faces technical realities and hidden complexities. Bridging these viewpoints constructively is the key to moving forward.

2. Leading With Empathy and Curiosity

When a PM questions a team’s pace, it’s easy for engineering leads to become defensive—especially if they believe they’ve been transparent and on time. Yet effective leadership frequently starts with empathy and curiosity.

1. Listen Openly
   Invite the PM to share details about his frustrations:

   • “Which part of the timeline seems too lengthy?”

   • “Can you detail the previous project you’re comparing this to?”
     This conversation can uncover hidden pressures or highlight real differences between the projects.

2. Seek Shared Objectives
   Emphasize that everyone wants a robust, successful inventory management tool. The question is how to reach that goal effectively, not whether it should be reached at all. Identifying common ground helps recast the discussion into a mutual problem-solving exercise.

3. Stay Curious
   Consider the possibility that the PM’s feedback is based on valid experience. Perhaps some best practices from the past can apply now. By approaching his critique with an open mind, you maintain goodwill and might discover overlooked shortcuts.

3. Clarity From the Start: Why Scoping Matters

Many product-development conflicts stem from failing to define a project’s nature and constraints at the outset. One experienced engineering manager emphasized that projects typically fit into categories like:

1. Must-Do at Any Cost
   Critical initiatives with inflexible deadlines or compliance requirements.

2. Do for Good ROI
   Projects aimed at a strong return on investment within a negotiable timeframe.

3. Do Within a Fixed Budget
   Strictly resource-limited efforts.

4. Do to Create Movement
   Early-stage or exploratory work whose primary purpose is learning rather than immediate full-scale delivery.

In Allison’s scenario, the initial phase was clearly exploratory. Her team had to determine whether to integrate with existing databases or build an entirely new system, how to handle real-time stock updates, and how best to structure the front-end dashboards. If the PM assumed it was a straightforward “execute these steps” effort, disappointment was almost guaranteed.

Practical Steps to Improve Scoping

• Document Assumptions: Outline any assumptions about data sources, required integrations, security mandates, and performance metrics.

• Define Success Criteria: Specify what a successful outcome looks like—whether it’s meeting a deadline, achieving a certain throughput, or delighting a particular user base.

• Collaborative Timeline Creation: Rather than engineering alone producing the schedule, involve the PM in milestone planning. This joint effort allows immediate discussion of feasibility and risk.

4. Comparing the Past vs. Building Something New

One of the PM’s central points is, “We’ve done something similar before, and it didn’t take this long.” Comparing present progress to previous projects can be misleading if they are not truly alike. For instance:

• Different Technology Stacks
  The older solution might have been built with simpler tools, fewer features, or an existing framework that accelerated development.

• Team Composition Disparities
  Maybe that prior team boasted multiple senior specialists, or it was an entirely different company with different resource levels.

• Varying Complexity
  The previous tool might have served a single department with fewer functional requirements, while this new tool spans multiple business units and must support complex workflows.

Instead of dismissing the PM’s claim outright, Allison can pivot to a constructive conversation:

1. Contextualize Past Successes
   Sit down with the PM to dissect what truly made the previous project “faster.” Was it a narrower scope? Existing components? Better funding?

2. Highlight Platform Investments
   If Allison’s team is creating foundational modules that will speed future expansions or integrations, clarifying how these modules pay off long-term helps justify the current timeline.

3. Show Your Work
   Sharing velocity data, sprint burndown charts, or a list of completed features can sometimes ground the debate in tangible metrics, demonstrating the team’s steady productivity.

5. Constructing Solutions Through Open Communication

Allison’s team has been candid about milestones and day-to-day progress, but the PM’s concern persists. Stand-ups, while useful, often don’t surface deeper strategic issues or shifting stakeholder demands.

Tactics for Enhanced Communication

1. Weekly or Bi-Weekly Roadmap Reviews
   Beyond daily stand-ups, establish a recurring meeting dedicated to the bigger picture. Discuss upcoming milestones, potential risks, and any changes in priorities or scope.

2. Regular Demos
   Show tangible progress at sprint reviews. This gives the PM and other stakeholders direct visibility into what’s been completed, helping them appreciate the complexity of the delivered features.

3. Solicit Concrete Feedback
   Ask the PM: “What specific indicators would help you feel we’re on track?” or “Can you define what underperformance looks like to you?” This helps shift from generic frustration to measurable expectations.

6. When Prior Experience Doesn’t Match Reality

A PM’s past success with a seemingly comparable project may not apply if organizational structures or supporting tools have changed. Some typical reasons include:

• Organizational Evolution
  Stricter quality assurance processes, additional compliance checks, or new leadership reviews can all slow development compared to a time when fewer hurdles existed.

• Different Skill Sets
  The other project might have benefitted from a seasoned team that had worked together for years. A newer team could still be forming effective collaboration practices.

• Updated Technologies
  Tools, libraries, and frameworks evolve quickly. Building with more modern or specialized approaches can offer long-term advantages but requires new expertise.

Allison can engage these complexities by:

1. Analyzing Project Architecture
   If there’s documentation from the old project, review it side by side with the new approach. Point out any shortcuts the old project took or advanced capabilities required now that demand more effort.

2. Proposing Resource Adjustments
   If the main difference is staffing, ask whether bringing on additional specialists or reassigning certain tasks could reconcile the PM’s expectations with reality.

3. Escalating With Evidence
   If the PM persists in stating the team is “underperforming” despite hitting milestones, consider escalating to senior leadership. Provide data on feature delivery, complexity, and resource constraints.

7. Fostering a Culture of Mutual Respect

Continually labeling a team “underperforming” can sap morale, especially if they meet agreed-upon milestones. High-performing teams expect recognition for delivering results. Leadership needs to balance the PM’s frustrations with affirming the team’s accomplishments.

Strategies to Build Respect

1. Publicly Acknowledge Successes
   Whenever a milestone is achieved, share the achievement throughout the organization. Emphasize the technical hurdles overcome and the value now available to users or other teams.

2. Offer Transparent Insights
   Host “knowledge-sharing” sessions where developers outline the system’s architecture, highlight challenges, and detail work completed. Understanding the complexity can reshape a PM’s perception of “slow” progress.

3. Address Negative Feedback Directly
   If the PM continues to voice discontent, address it head-on in one-on-one sessions or through mediation. Persistent negativity undermines team cohesion and needs resolution at a leadership level if it persists.

8. Lessons in Effective Collaboration

Allison’s story isn’t unique—it’s a scenario replayed in countless companies. Drawing out lessons helps other teams preempt or resolve these conflicts:

1. Ambiguity Needs Discovery
   Projects with vague requirements need dedicated discovery phases. Make it clear that timelines will remain estimates until experimentation validates direction.

2. Scoping Avoids Misalignment
   Clarifying project scope, constraints, and success criteria before coding begins is crucial to prevent surprise or disappointment later on.

3. Varied Communication Channels
   Daily stand-ups alone don’t ensure full alignment. Supplement them with roadmap reviews, demos, and retrospectives.

4. Use Data Thoughtfully
   Metrics like velocity or cumulative flow can lend objectivity, but remember that no single metric captures all nuances. Combine data with open dialogue.

5. Invest in Foundations
   Sometimes building new frameworks or services yields slower initial delivery yet leads to faster follow-up phases. Emphasize these longer-term benefits to the PM.

6. Keep Improving Continuously
   Even if you believe you’ve done everything right, treat any complaints as opportunities for reflection or refinement.

9. A Practical Path Forward

How can teams transcend conflict to foster better understanding? Consider these steps:

1. Set Up a Direct Conversation
   In a one-on-one with the PM, invite him to detail his specific concerns, then present how the team has met each milestone and why certain tasks took the time they did.

2. Facilitate a Retrospective
   Bring in the whole team, the PM, and possibly a neutral facilitator to discuss what’s working, what’s not, and how to improve communications and processes.

3. Revise Milestones if Needed
   If the scope has grown or shifted, align on a new timeline. Document these changes and confirm mutual understanding.

4. Escalate with Transparency
   If the PM’s criticisms persist without acknowledging the evidence, engage senior engineering or product leadership to reevaluate priorities, resource allocation, and scope.

5. Implement an Ongoing Feedback Loop
   Consider monthly or quarterly syncs focused on cross-department collaboration. Such forums prevent misunderstandings from festering between major milestones.

Conclusion

Even a disciplined team that meets every milestone can be labeled as “underperforming” if the Product Manager’s expectations aren’t well aligned with realities. Often, the disconnect stems from comparing unlike situations, overlooking the complexity of brand-new systems, or failing to establish open and varied communication channels.

By approaching conflicts with empathy, curiosity, and a willingness to showcase tangible progress, engineering leaders can bring clarity to the PM’s concerns. Aligning on scope at the outset, sharing metrics that reflect real progress, and collaboratively defining success all help remove ambiguity. Leaders who follow these principles foster a culture where trust and respect flourish—and where PMs and engineers alike can take pride in building innovative solutions together.

Ultimately, product development thrives on cross-functional harmony. Balancing realistic timelines with transparent communication fosters sustainable, high-quality outcomes—no matter how “fast” a seemingly similar project looked in the past. By incorporating these practices, teams can navigate contentious moments, emerge stronger, and consistently deliver business value that satisfies both internal stakeholders and end users.

~10xManager