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 three 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 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 three 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 three 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 three 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.