Product Teams Marty Cagan

The Foundation of Product

Recently I wrote an article about some product ops anti-patterns, but several people pointed out to me that I had buried the lede in that article, and that the most important part of that article applied far beyond the relatively minor topic of product ops.

So in this article, I’d like to focus on this more fundamental topic, which gets to the very nature of product, and the foundation of what it means to be a strong product team.

Recall that an empowered product team exists to solve important problems for our customers or our company, in ways that our users and customers love, with enabling technology that is just now possible, and in ways that work for our business.

Note that this is a very different purpose than a feature team or a delivery team, so this article is specific to empowered product teams.

In order for the product team to come up with effective solutions, there are four constituencies that you will need unencumbered access to, in order to have any real hope of success:

Direct Access To Users and Customers

This really should be obvious, but without direct, unencumbered access to actual users and customers, the product team has little hope of any kind of success in solving for value and usability.  

The users and customers provide not only inspiration for unaddressed problems but also the means to rapidly test our proposed solutions.  A little less obvious is the need for direct access to the data about these users and customers, such as how our users engage with our product, and the feedback these people provide on their experience using our product.

It should be intuitively clear why the product manager and product designer need direct access to users and customers, but less obvious is the importance of providing your engineers with direct access to the users.  

You don’t need all of your engineers to tag along on every customer or user interaction, but “the magic happens” when an engineer sees a user struggling with their product, so the more you can encourage and facilitate this, the better.

But the key here is not to let anyone try to prevent you from direct access to customers – not a sales or marketing person, not a customer success person, not a user researcher, not an Agile Coach, not a customer’s vendor manager, no one. 

Direct Access to Product Data

Similarly, the product manager needs direct access to the product data in order to make good decisions based on that data.

There are usually several data sources that contain different types of data—such as how your users are interacting with your product, how your customers purchase your products, and how your customers’ behaviors are changing over time.

The product team may have access to data analysts and data scientists to help explain complex data patterns, but the decisions based on this data are the responsibility of the product manager, so that person needs this direct data access.

In some companies, there are people that want to restrict access to this data, and it is important that your customer’s privacy and security be maintained.

You can create systems that enforce the appropriate types of governance, access, anonymization, and aggregation that may be required, but still give teams direct access to the essential data.

As with direct access to customers, direct access to data is fundamental to the product model. Without direct access to the data, the product manager is flying blind.

Direct Access to Business Stakeholders

Solving for viability is about solving for the various business constraints – marketing, sales, services, finance, legal, compliance, manufacturing, subject matter experts, and more – and it’s essential that at least the product manager has direct access to the leaders across your business that are responsible for these constraints.  

The product manager must establish relationships with these people, where the product manager has put in real time and effort to learn the concerns and needs of the various stakeholders, and the stakeholder genuinely believes that the product manager understands the relevant constraints, and will ensure they are considered and addressed in any proposed solution.  And for anything in that gray area where the product manager isn’t sure if something is viable or not, the product manager will discuss with the stakeholder before building anything.

This trust between the product team and the stakeholders is critical to the healthy collaboration that’s needed to find effective solutions that solve for both the customer and the business.  Which is also why product teams need to understand when and how to make occasional high-integrity commitments.

Direct Access to Engineers

Finally, we need to ensure that the product manager and product designer have daily, ongoing access to the engineers.  To many of you, this is the most obvious statement in the world.

But to others, such as those working in environments where the engineers are outsourced; or where the engineers are located in timezones where the interaction is difficult, or where the belief is that engineers need to be sheltered so they aren’t interrupted while they code; or where the product team is split up such that the product manager interacts with customers and stakeholders, and some other person, like a product owner or project manager, interacts with the engineers, then this is too often not the case.

Realize that the engineers are working daily with the enabling technology, so they are in the ideal position to understand what’s “just now possible.” But realize this only happens in a way that is actionable when the engineers are interacting with the product manager and product designer every day.

The Inspiration for Innovation

What all this means is that you need to protect the product team’s direct access to these four constituencies, and fight any attempt to place a well-meaning person, or cumbersome process, between the product team and these people.

It is in fact the direct, ongoing access to these four constituencies that enables the product team to discover innovative solutions, and to make good decisions.

I find myself increasingly emphasizing the importance of “picking your battles.”  

If I could only pick one single thing to convince you of, in order to dramatically increase your odds of success, it would be this.  So I truly hope you’ll seriously consider this.

In my opinion, if you’re a product team and you are prevented from accessing any of these four constituencies, then you are very likely going to fail.  So correcting this is a battle worth fighting.  If your company doesn’t understand why this is foundational, and you’ve exhausted all efforts to explain the importance, yet you still wish to practice the craft of product in a strong product company, while I don’t like to say this, the truth is you may need to start considering companies where you’ll have a better chance of success.  It’s that important.