Executive Engagement
By Marty Cagan and Jon Moore
Nomenclature Note: “Senior Leaders” refers here to CEO, Founders, CFO, COO, CMO, CRO, President, etc. “Product Leaders” refers to the managers and leaders of product management, product design, and engineering.
Now that EMPOWERED has been published, we’ve heard from a growing number of senior leaders that realize they have been leading through command and control and/or micro-management, and have seen the level of motivation and innovation that generally results from that model, and seem to genuinely want to change in order to empower their people and teams.
Of course we love hearing that, and the people in the product organization love hearing that too, but changing to an empowered product-team model represents a major cultural and behavioral change, and much of this change necessarily needs to start at the very top.
Unfortunately it’s not as easy as saying “just back off and give the people space to do their work.”
There are very real needs that senior leaders have in order to responsibly and effectively run the company.
And in order to push decisions down to product teams, those teams need to understand the strategic context, much of which needs to come from the senior leaders.
So there’s no question that we need frequent high-quality engagement. It’s just the nature of the interactions that we’re talking about here.
We want to interact in ways that provide the leaders the information they need to run the business, yet empowers the product leaders and the product teams, and provides the environment the product teams need to do good product work.
INTERACTION PRINCIPLES
We’ve found there are a set of interaction principles which can help guide constructive and effective interactions between the senior leaders, and the product leaders and product teams:
Lead With Context Not Control. We want to push decisions down to the product leader or product team in the best position to come up with the best answer – normally that’s the people working directly with the enabling technology, and the users and customers. But teams can only make good decisions when they are provided the necessary strategic context. So senior leaders and product leaders need to share the broader context – vision, strategy, financials, regulatory developments, industry trends, partnerships and more.
Outcomes not Output. Whenever possible, we want to hold people accountable to outcomes rather than output. But this only works if the people are empowered to come up with a solution that works. We want to give product teams as much latitude as possible to come up with the best solution they can.
Knowing What You Can’t Know. It’s important for everyone – but especially senior leadership – to understand that with technology products, there are many things that we simply can’t know in advance. Knowing what you can’t know, and admitting what you don’t know, is essential for strong product organizations.
Data Beats Opinions. The great equalizer in strong product organizations is the ability to run tests and collect data. We teach product teams how to run tests quickly to collect the necessary evidence or even proof. Product teams use this evidence to resolve differences among themselves, and with their leadership.
High-Integrity Commitments. It’s also important for the product leaders and product teams to understand that there will be times when the business needs to know a specific date for a specific deliverable, and the organization needs to be skilled in the techniques for coming up with high-integrity commitments. That said, the senior leaders also need to understand that the need for high-integrity commitments should be the exception and not the rule, and that the time and effort in making a high-integrity commitment is non-trivial.
The Main Thing. As Jim Barksdale famously said: “The main thing is to keep the main thing, the main thing.“ So much of an effective product organization is a result of real focus. There will always be new prospective customers, and new business opportunities, but remember that focus is not saying no to bad opportunities, it’s saying no to other good opportunities.
Missionaries not Mercenaries. Effective teams of missionaries depend on three critical ingredients: the teams must be staffed with competent people with the necessary skills; the people need to be inspired with the strategic context; and the leaders must demonstrate some trust in their product leaders. Nobody is expecting a blank check, but if you want people to take ownership of outcomes, good people need some space to do good work.
Transparency. It is very important to the culture of the entire company that the product and technology organization be as transparent as possible with their reasons for the decisions they must make. This not only means sharing the rationale, but also the successes and failures. We will often have colleagues and stakeholders in the company that disagree with specific decisions, but we never want them to question the integrity or motivation of the product organization.
You Are Not The Customer. In any organization there will be many people that have strong opinions, but strong product organizations need to concentrate on coming up with solutions that our users and customers love, yet work for the business. Many people will think they are representing the customer, and that is an especially dangerous trap for founders, product managers, designers, and sales and services staff, but there is no substitute for going to the true users and customers.
Fix The Team First. When a problem is identified, first we focus on ensuring the right team is in place to successfully address the problem. That may mean ensuring the necessary skill sets are on the team, or coaching one or more members on specific skills, or when necessary, correcting staffing issues.
Empowered Engineers. This principle is a little different than the others but it’s such an important point that we encourage all senior leaders and product leaders alike to constantly keep a focus on this. You want to make sure that in every decision that you make regarding product, that your engineers are truly represented, engaged and empowered. You want to ensure that your individual contributor engineers are used for more than just coding, and they are actively participating in product discovery as well. They are consistently the best source of true innovation, but that’s only if they’re truly empowered, and not just there to implement features conceived by others.
Ideas vs Directives. Senior leaders need to be very cognizant of the power of their words, especially when engaging with individual contributor product managers, designers and engineers. Senior leaders are constantly exposed to many customers and prospects, and many industry trends, and it is not unusual for these senior leaders to get inspired with many different ideas. In a healthy product organization, product teams want to hear these ideas. But they need to know when it’s simply an idea to be considered and possibly explored, or when this is literally a senior leader exercising his or her prerogative to issue a directive. Unless explicitly stated as a directive, all discussions about product ideas are assumed to be just ideas to be considered, along with many others from several valuable sources. During their product discovery work, the product teams will test out many ideas in order to discover a solution that works.
Prototype vs. Product. When we are communicating about product with senior executives, we need to be very clear whether we are talking about something that is being explored in product discovery (prototypes), or whether we are discussing something that is now live and in production and visible to customers (products). When getting feedback on proposed product ideas, we use prototypes, and we do that before building. When we’ve already built something, and we’re now communicating the new capabilities to sales, customer service, marketing, customers, etc., then we use the live product. Confusing these two can be very dangerous.
Minimize Surprises. Sometimes surprises are unavoidable, but we try hard to minimize them. This means that if there’s anything even potentially sensitive, the product manager is expected to recognize this, and to show and discuss (typically with a high-fidelity prototype) with the impacted senior leader(s) before the solution is built. One of the worst forms of waste is when a product team builds a product quality, scalable implementation of some capability, and then finds out afterwards that there is some reason why this is not an acceptable or viable solution. This is the same reason we test usability and value with the target users before building. Similarly, if a senior leader reviews a prototype during discovery, and doesn’t raise any major issues, but once the product is built and in production decides that something is a serious problem, then this is likewise very wasteful and frustrating to the organization. Regardless of the cause, when something gets built but then is deemed to have a serious problem, it is reason to have a post-mortem discussion to see how that type of waste can be avoided going forward.
No Silver Bullets. Finally, be aware that there will always be a constant stream of bright new shiny things when it comes to books, articles, processes, techniques, and methods. Design Sprints, OKR’s, Jobs To Be Done, Hack Days, Opportunity Solution Trees, and countless other techniques all have their place, but it’s essential for everyone to realize that none are silver bullets. There is no real substitute for the hard work of product.
Certainly there are any number of potential types of executive engagement, but in terms of the interactions regarding product and technology, my hope is that these principles can provide a foundation for senior leaders and product leaders alike to understand the needs and concerns of the other.
Great products require strong product teams and strong leadership, so it’s essential that the organization has constructive and effective communication and interactions.