Engineering x Product Collaboration

In my practice as an Engineer over the years, I have had ample opportunity to collaborate with many talented Product leaders at many companies. This week, I sat down to note patterns that have emerged during such collaboration. I'm sharing them here in hopes that I can help move successful collaboration forward for you and your organization.

Proviso

What follows is a discussion of Engineering and Product collaboration under certain ideal conditions. I'd like to mention that I have experienced healthy collaboration even when all the conditions I discuss are not met. This includes cases where I have partnered with Product leaders to iterate on ambiguous or loosely defined problem spaces. This can be particularly true in the infancy of a new feature, where foundational or enabling work must first be undertaken, necessarily with Engineering involvement.

Also, while I refer to the need for explicit ownership and accountability, I think the best collaboration happens when there is an implicit attitude that we all play as a team. While we may have a single point of contact when it comes to measuring outcome, that does not preclude that we are all in it together, and the best team members have each other's backs, at all times.

The Benefit of Structure

First of all, when collaboration fails, it is rarely interpersonal. Rather it tends to be structural, and degrades when one or more of the following are missing:

• A measurable outcome
• A defined baseline
• Clear ownership
• Explicit constraints
• A stable definition of "done"

Measure Success

If success cannot be measured, then collaboration cannot be stable. All initiatives must define:

• What number moves?
• What is the current state?
• Over what time window?
• Who owns and is accountable for the movement?

If any one of these are missing, work become merely aspirational, "done" becomes subjective, and often Engineering absorbs that ambiguity by default.

Define Your Baseline

Without a starting baseline, tradeoffs and improvement cannot be validated, and Engineering cannot be expected to properly scope effort responsibly. As a rule of thumb, I try to push back on committing to delivery if a current state has not been established, quantified, and agreed upon as the shared starting point.

Clarify Ownership

Unowned metrics become aspirational and default to something along the lines of "Engineering should just make it better". Ultimately these metrics fade into noise. Although Engineering my influence and deliver, and Product may define, collaboration requires that every outcome metric has a named owner.

Surface Constraints

Engineering has a responsibility not just to build, but also to stabilize the system. This requires that technical constraints, architectural tradeoffs, and operational risk are surfaced early. Clarity about constraints can ward off artificial optimism. Such artificial optimism can result in system instability.

Avoid Premature Solutioning

A common anti-pattern is to define a feature, assume a timeline, and have vague or wholly undefined metrics, then dive directly into building. Instead, I recommend the following sequence (taking the above suggestions into consideration):

1. Define the problem
2. Define measurable success
3. Validate the baseline
4. Surface constraints
5. Design the solution

Healthy Collaboration

So, to summarize, what does healthy Engineering and Product collaboration look like? In my experience, it is when:

• Metrics are numeric.
• Tradeoffs are discussed explicitly.
• Timelines are negotiated.
• Ownership is named.
• Scope changes are visible and intentional.

Remove any one of these signals of healthy collaboration, and it could be a sign that entropy around the initiative is increasing. I believe one responsibility of Engineering is reducing this entropy. I hope that the framework I have outlined here aids in that mission.