Skip to main content

Working with Product and Developers

Prerequisites: Coaching Leads to: After this, you'll be ready for Working with DevOps and Stakeholder Management.

Why This Matters​

A QA Lead who treats product and engineering as obstacles to route around. A QA Lead, frustrated by requirements that arrive without enough detail to design good test coverage, and by developers who push back on every flagged edge case, starts treating both relationships adversarially — quietly working around gaps rather than raising them, and treating pushback on defect severity as something to win rather than discuss. Over time, both relationships erode: product stops involving QA early, since QA seems to only ever raise problems, and developers start viewing QA's input as friction to manage rather than genuine signal.

A QA Lead who builds each relationship around its actual shared interest. A peer facing similar friction instead identifies what each group actually cares about — product wants confidence a release won't damage the user experience or business metrics they're accountable for; developers want to ship code that works and not get blindsided by late-discovered issues — and frames QA's own contribution in those terms specifically, rather than in QA's own internal vocabulary. Both relationships strengthen over time, because each group sees QA's input as directly serving something they already care about, not as an external check imposed on them.

Both leads wanted the same outcome: better collaboration. Only one built it by understanding what the other side actually cares about — the same interest-based reasoning from Conflict Resolution, applied here to ongoing cross-functional relationships rather than a single disagreement.

What Each Relationship Actually Needs​

Working with Product: product management is accountable for user experience, business outcomes, and timeline — QA's most effective framing connects testing findings directly to those concerns ("this edge case affects a checkout flow tied to revenue," not "this violates a formal testing principle"). Getting involved early, at the requirements stage, is usually more valuable than being thorough late — the same shift-left reasoning from Shift Left at Scale, applied at the relationship level: earlier QA involvement in requirements conversations catches ambiguity before it becomes an expensive late-stage disagreement.

Working with Developers: developers are accountable for code quality and want confidence their work is genuinely solid, not just "waiting to be caught." QA's most effective framing treats developers as a genuine partner in quality, not an adversary to police — sharing risk reasoning, not just defect reports, and being precise and evidence-based (see Presenting Your Testing Work Credibly) rather than vague or alarmist about severity.

Common Mistakes​

Mistake 1: Treating product and engineering relationships adversarially, as obstacles to route around. This module's opening scenario — an adversarial framing erodes trust over time, and both groups eventually route around QA rather than involve it early, which is the opposite of what good testing relationships need.

Mistake 2: Communicating in QA's own internal vocabulary rather than the terms the other group actually cares about. "This violates our test coverage standard" means little to a product manager focused on user experience and revenue; "this affects a checkout flow tied to revenue" speaks directly to what they're accountable for.

Mistake 3: Engaging with product only late, after requirements are finalized, rather than during the requirements stage itself. Late engagement means QA can only flag problems after they're expensive to fix — the same shift-left principle that applies to code applies to relationships with the people who define requirements.

Mistake 4: Treating every flagged issue as equally worth pushing on, rather than reserving real pushback for genuinely high-risk findings. Consistently pushing hard on every issue, regardless of actual severity, erodes credibility for the times pushback genuinely matters — calibrate insistence to actual risk, per Risk-Based Strategy.

Best Practices​

Practice 1: Frame testing findings in terms of what the other group is actually accountable for. Connect a specific issue to user experience or business impact for product, and to code quality and confidence for developers — not to QA's own internal standards.

Practice 2: Get involved at the requirements stage, not just at testing time. Early involvement catches ambiguity and risk before it's expensive to address, and builds the relationship as a genuine partnership rather than a late-stage gate.

Practice 3: Share reasoning and risk assessment, not just conclusions, when communicating with developers. The same visible-reasoning discipline from Developing Leadership Skills and Technical Credibility builds trust that QA's judgment is sound, not just asserted.

Practice 4: Calibrate how hard to push based on genuine risk, not on principle alone. Reserving strong pushback for genuinely high-risk findings, per Risk-Based Strategy, keeps that pushback credible and taken seriously when it matters most.

From the Field

At AtlasBank, the QA team on the Internet Banking product had, for some time, been brought into requirements conversations only after a feature's specification was finalized — resulting in QA repeatedly flagging ambiguous or untestable requirements late, generating friction with a product team that experienced this as QA blocking progress rather than helping. A new QA Lead negotiated a small process change: QA would join requirements review meetings directly, asking specifically about testability and edge-case handling before the specification was finalized. Within two quarters, the friction had measurably decreased — not because QA raised fewer concerns, but because those concerns now surfaced when they were still cheap to address, and the product team began experiencing QA's early involvement as genuinely useful rather than as a late-stage obstacle.

Mini Challenge​

Scenario: Your QA team is currently only involved once a feature is built and ready for testing, leading to frequent late-stage disagreements with both product and engineering about scope and severity.

Your task: Describe the specific process change you'd propose to get QA involved earlier, and explain how you'd frame the value of that change to a product manager specifically, in their own terms.

Key Takeaways​

  • Effective relationships with product and engineering are built around what each group actually cares about, not QA's own internal vocabulary.
  • Early involvement at the requirements stage catches issues before they're expensive to fix and builds partnership rather than late-stage friction.
  • Sharing reasoning, not just conclusions, builds developer trust in QA's judgment.
  • Calibrating how hard to push based on genuine risk keeps pushback credible when it matters most.

What You Just Learned​

  • How to frame testing findings in terms each cross-functional partner actually cares about
  • Why early involvement at the requirements stage matters more than thoroughness late
  • The same interest-based reasoning from conflict resolution, applied here to ongoing relationships
  • The AtlasBank Internet Banking example of earlier QA involvement reducing friction without reducing rigor

Interview Questions​

Q1: How do you build an effective working relationship with product management as a QA leader?

What to look for: An answer framed around understanding product's actual concerns (user experience, business outcomes) and early involvement, not just "good communication" in the abstract.

Q2: Tell me about a time you had friction with engineering over a testing finding. How did you resolve it?

What to look for: A real example showing evidence-based, risk-calibrated communication rather than simply asserting QA's authority — strong answers show genuine partnership-building, not a QA-wins-the-argument framing.

Common Interview Mistake

Some candidates describe QA's relationship with product and engineering in terms of QA acting as a gatekeeper or final check. A strong answer frames QA as a genuine partner contributing to shared goals — user experience, code quality — not an external authority imposing standards on other groups.

Q3: How do you decide when to push back hard on a testing concern versus let something go?

What to look for: An answer connecting the decision to genuine risk assessment, not principle or consistency alone — showing the candidate reserves strong pushback for what actually matters, preserving credibility for those moments.

Glossary​

Interest-Based Cross-Functional Communication: Framing testing findings and QA's own contribution in terms of what a product or engineering partner is actually accountable for, rather than QA's internal vocabulary or standards.

Quick Revision​

Remember these five points:

✓ Effective relationships with product and engineering are built around what each group actually cares about, not QA's own internal vocabulary.

✓ Early involvement at the requirements stage catches issues before they're expensive to fix.

✓ Sharing reasoning, not just conclusions, builds developer trust in QA's judgment.

✓ Calibrating pushback intensity to genuine risk keeps it credible when it matters most.

✓ Treating product and engineering as partners, not obstacles, is what actually improves cross-functional collaboration over time.