Product and Engineering: Who Owns What? ⚖️

Issue No. 25

One thing I've noticed in many product teams or organisations, whether I've been part of them or consulted with them, is a lack of clarity of who owns what between the product and engineering teams.

This often results in misalignment, confusion, and a disjointed operation. In the worst cases, it can feel as if two parallel organisations are operating in vaguely the same direction – one led by the Chief Product Officer (CPO), who holds their meetings and disseminates requests, and the other by the Chief Technology Officer (CTO), who does the same with their, often much larger, team. Team members struggle to match everything up without always knowing what the other is trying to achieve.

It's tragically sad when we set ourselves up like this. While I plan to write more about the relationship between the CTO and CPO in future articles, I want to first focus on the high-level areas of responsibility for product and engineering.

Or, put another way, here are some principles that should underpin the roles of the product and engineering teams.

After all, product and engineering shouldn’t appear on the outside as two teams but rather as a single team, all rowing in the same direction.

This week's issue addresses what product and engineering are classically responsible for. These principles are simple to grasp, and when folks grasp them, it brings a lot of clarity (and can help avoid some crazy alternatives like a weirdly complex RACI matrix).

I'm sharing an adaptation and an amalgamation of documents I've written in previous places where I’ve worked. The concepts and the framing are not my invention but a combination of several great resources listed at the end of this issue that have shaped my thinking on this topic. So, let's dive into it!

💬 In this issue, I cover

• 🧭 A simple set of principles to be clear on who owns what between Product and Engineering
  • 🤔 Why? (Why build this?) - Owned by Product
  • 💡 What? (What are we building?) - Owned by Product
  • ⚙️ How? (How will we build it?) - Owned by Engineering
  • 👥 Who? (Who will build it?) - Owned by Engineering
  • ⏳ When? (When will it be ready?) - Owned by Engineering
• ⚠️ Common pitfalls that prevent great collaboration despite the clarity these principles can bring.
• 📚 Articles for further reading on this subject.
• 🔦 Highlight of the Week

📝 Areas of Ownership Between Product and Engineering

☝️ Bottom Line Up Front

There are several key areas of ownership needed to build successful products. Either Product or Engineering can own each, and the owner should take responsibility for getting their partner’s input and alignment on key decisions.

• 🤔 Why? (Why build this?) - Owned by Product
• 💡 What? (What are we building?) - Owned by Product
• ⚙️ How? (How will we build it?) - Owned by Engineering
• 👥 Who? (Who will build it?) - Owned by Engineering
• ⏳ When? (When will it be ready?) - Owned by Engineering

❗ Each has different areas of responsibility or concern. They overlap. We are ALL trying to work towards the same goal of building products that delight our customers. For example - Engineering wants to work on technical debt because it also impacts the user experience. We all need to obsess over UX together.

🤔 The Why? Owned by Product

The “Why?” question is at the heart of the Product vision and strategy. Why are we working on this area? Why is this a problem worth solving? What change are we as a team hoping to produce in the world?

Example: Our business must expand into the healthcare industry to support its revenue growth goals. To purchase our software, all healthcare companies require that the product is HIPAA compliant, which it isn’t today. No HIPAA means no revenue from healthcare, which means not hitting our growth goals.

Answering this “Why?” question with conviction requires a strong understanding of our customers' wants (present and future), the market direction, the overall business strategy, and a deep understanding of the current product. The importance of the vision and strategy fueling the team can’t be underestimated. It gets teams through the hard times and is what the company ultimately measures success against.

Developing the product vision and strategy is the job of Product Leadership and the Product team. However, true success is when product and engineering clearly understand and contribute to this narrative. A team that understands and is bought into their direction will get there twice as fast, and the end product will be much higher quality.

I strongly believe in discovering the “Why” together, even though Product will always make the final call.

💡 The What? Owned by Product

The “What?” relates to the specific features or products a team plans to release. What are we building to solve the problem we have pinpointed in the “Why”?

Example: We need to build HIPAA compliance into our product ASAP to hit our growth goals as a company for the year.

The “What?” goes beyond the basic functional requirements (we need to be HIPAA compliant) and into the specific requirements of a product to be ready for general availability (what specifically needs to happen for us to be HIPPA compliant). These details are critical to inform the key decisions Engineering must make, like “When?” “How?” and “Who?”. More on these below.

I personally believe that the “Why?” and “What?” are best encapsulated in a Project One Pager. A Project One Pager is a document that covers the problem the team is trying to solve, the outcomes or resulting human behaviour we expect to see that will impact our business, and the metrics of success.

⚙️ The How? Owned by Engineering

The “How?” defines the technical solution that delivers on the “Why” and the “What” for a Project. This is codified in our architecture and design documentation, along with the “Who?” and the “When?” visualised in our project management tooling.

Though all three areas, “How?” “Who?” and “When?” are distinctly important decisions; the solution a team chooses to ship is very tightly coupled to who builds it and when it will be available. As such, it’s common to decide these simultaneously, after close collaboration and iteration with the Product Manager and the broader team.

Example: There are three viable paths for the team to build HIPAA compliance into the product:

• Option 1: Integrate with a 3rd-party HIPAA compliance tool. It’s expensive, but we can do it quickly in 3 months.
• Option 2: Build compliance into our existing systems. It’s inexpensive, introduces more tech debt, and takes six months.
• Option 3: Rewrite key systems to allow for HIPAA compliance and remove tech debt. It’s inexpensive but takes eight months.

To decide which option to choose, Engineering needs input from Product on things like the cost and timeline sensitivity of the organization. However, to choose the optimal solution, we need to look beyond the stated requirements and consider the architecture of the solution and its impact on:

1. Developer velocity: a particular architecture can make certain changes easy while inhibiting other types.
2. Developer experience: Certain architecture decisions influence the experience that developers have when building and interacting with the solution (e.g. The number of manual steps when deploying a small change).

Not adequately considering the above leads to the accumulation of technical debt. Engineering is the ultimate custodian of this technical debt and brokers the conversation between Product and Engineering.

These factors require Engineering to have the final say on the “How?”.

👥 The Who? Owned by Engineering (and often causes the most Product/Engineering tension)

The “Who?” question answers which engineers will lead the project to deliver the agreed-upon solution (“What?”) by the timeline decided (“When?”). This is codified in an organisation's architecture and design documentation and visualised through their project management tooling.

Example: If we pursue Option 1, the required team is Albert, Vanessa, and Sarah. If we pursue Option 2, the required team is Alan, Osama, Tracy, Albert, Vanessa, and Tatiana.

On the surface, this is an easy decision for a Product person. Just pick the next engineer(s) with the relevant skills to get started on the project. This might be a reasonable approach if we were purely optimizing for short-term product velocity.

However, there are other constraints that engineering needs to balance. Career development, team dynamics, and work-life preferences must be weighed in staffing a project and contributing to the team's long-term success.

⏳ The When? Owned by Engineering (Based on Trade-off Conversations with Product)

The “When?” question answers the date we can expect a shipped feature or solution. Shipped here means it is available to the relevant subset of customers (e.g. pushing a feature to beta availability for a limited subset of customers).

Although engineering owns the decision on the timeline, there should be close and iterative collaboration with the product.

Example: According to the options outlined above, three possible timelines exist. Option 1: 3 months; Option 2: 6 months; Option 3: 8 months.

In the example above, you can see both options have different timelines. To decide in the example above, Engineering will require Product to weigh in on the relative importance of speed vs. cost, which is a business context they likely won’t have.

💔 Where It All Falls Apart

I recommend that every product team or organisation write up a version of these principles, adapted for their context.

🤝 Focusing on a strict delineation of ownership instead of collaborating towards a common goal

Some folks will read this article, take it the wrong way, draw thick lines around the parts they own, and limit cross-functional collaboration and the opportunity for team members to contribute outside their defined roles - that would go completely against the intent of the ideas in this document.

If we make the mistake of creating a strict division of roles, we will inadvertently create communication silos. We should focus on open communication and collaboration where team members work together towards common goals and work with trust and respect for each other's expertise.

By strictly dividing responsibilities, there's a risk that innovative ideas from engineers on the "What?" or from product managers on the "How?" might be disregarded. Innovation can come from anywhere within an organisation, and all team members should be encouraged to contribute ideas.

Staff, when given freedom, will perform at their best. We should encourage and empower employees to take the initiative and contribute to areas beyond their strict job descriptions.

Worse, if team members feel pigeonholed into their roles without the ability to influence other areas, it could reduce job satisfaction since job satisfaction comes from fulfilling work that challenges staff and allows for creativity and problem-solving.

🙋 The People Factor

However, when a document like this is not enough and team members create a RACI matrix that gets increasingly complex, then it might not be the principles or the matrix that you should be looking at.

The principles here are pretty simple to grasp. Things fall apart, not because people can't understand them but because we are human and human relationships can get complicated.

This is why I've already written about Baseline Principles for Teams. None of this will work without a foundation of psychological safety and trust. Team members need to be vulnerable with each other without fear of repercussion.

If only life were as easy as putting in place some clear principles! 🤷

Inspiration and Further Reading

If you would like to do further reading on this topic to create your version of this document, here are some great articles I found.

🔖 PM & EM: Rules of Engagement
🔖How product managers and engineers at Asana develop great relationships
🔖 VP Engineering & VP Product: How to create a united front
🔖 TBM 31/52: The Weeds
🔖 The VPP/VPE Relationship - Jacob Kaplan-Moss
🔖 Value and Viability - Silicon Valley Product Group

💬 If you had some thoughts while reading this, I would love to hear them in the comments.

🔦 Highlight of the Week

This week's quote is taken from an article by Zarar Siddiqi called "Backlog Size Is Inversely Proportional to How Often You Talk to Customers". Here is a version of the article with my other highlights. The original can be found here.