Transcription
Bonjour. I do not speak French, so pardon me. We will do this in English. But I am very excited to be here with you in Paris. Thank you so much for having me. It is my first time speaking in Paris, so I'm very excited to learn more about the French community of technology and hear what you all are up to.
Today, I'm going to tell you a little bit about what I have been seeing and observing regarding trends in technology, specifically in product management. As Piera mentioned, I wrote a book called *Escaping the Bill Trap*, which came out about five years ago. I spent three years writing it, and I hated the process. Now, I'm going to write another book, but it was truly awful. So, I'm very excited that it's out and that people have been reading it. In the book, I explain how to build great product organizations. What is product management? What do we need to do to build great product organizations? How should companies start to operate towards this goal?
Since the book came out, I will say that a lot of strides have been made in product management, which is fantastic. We're doing a pretty good job. When I started consulting and working with companies to learn product management almost eight or nine years ago, I had to fight with everyone just to talk to customers. I'm sure some of you have faced that struggle as well, right? We should be talking to customers. No, we know everything! Now, though, we're getting really good at those types of practices. I see teams excelling at user research, defining personas, building minimum viable products, conducting usability testing, and analyzing data. As product managers, we're getting really good at these individual practices, but we're still not pulling it all together to help make our organizations fully product-led. That's the next piece we need to focus on.
I've started to notice this trend. A couple of years ago, I started a podcast, as everyone does, right? Everybody has a podcast! In my podcast, I have a segment where people can write in and ask me questions. It's called "Dear Melissa." I looked at the questions from 2022 and identified two main inquiries. The first one is: How do I scale product management to the rest of my organization? People say, "I know we need to do MVPs, but sales is not okay with it. Customer service doesn't want it. Our CEOs need to be convinced." That's the second part: How do I actually convince leaders and the rest of the organization to adopt this approach? Those are the two most frequent questions I receive. You can tell when people write in that they're frustrated. I get some really angsty questions, like, "This person won't listen to me. How do I help?" So, I know we are genuinely frustrated with this, and that's what I want to talk to you about today: what it takes to get the rest of the organization on the same page with us.
We all believe that we need to be more product-led in organizations, but when we start to introduce that to the rest of the organization, they often respond with, "No, I don't want to do that." We get frustrated because we say, "Don't you see how amazing this is? It's a great thing! We should all be product-led!" So, why are we facing this kind of resistance from the rest of the organization? Why do we encounter people saying, "No, I don't want to do it"?
When you say "product-led," the rest of the organization hears this: "Product management rules everything." They interpret it as, "No, you peasants, you may not come up with ideas." They hear, "Product management makes all the decisions," and that makes them very scared and uncomfortable because, typically, they were the ones making the decisions. We know that product-led doesn't mean this—well, some of us know. There are some product managers out there, and I can tell by the questions I get, who feel like, "Nobody will listen to me. I make all the decisions, but they're not listening to my decisions." But that's not really product-led. That's not where we're headed. Product-led means that the product leads our growth in the organization. It means that we're not selling things that don't scale or that won't work for a significant portion of our personas. It means that the product actually drives our growth, and we're scaling by building really great products.
And that doesn't just take product managers. We can't do anything by ourselves, right? We need developers to code and put things out there. We need designers to create the designs. We need marketing to promote it. We need sales to sell it. So, we need all of these people to work together, and that's what makes a great product. When we look at building a product as product managers, we need to synthesize a lot of data and inputs from around the organization. We need to understand customer and user research, market research, and data. We need to assess whether there's an opportunity worth pursuing. How much of this market can we capture? Is it worth building into? We need to understand the financial data and implications on sales. If we are road mapping these things, when do we think we can unlock sales? If we build this thing, when can we start selling it, and how fast will sales ramp up? We need to understand user data: What are they doing right now? We also need to know the technology implications, such as, "Hey, we've got AI." I'm sure you're all excited about AI, and we're going to talk about that later in the conference. But we've got AI—what do we do with it? What can we do with it? What kind of problems can we solve? This is a big job. Product management is a really big role, and we need to figure out how to get the rest of the people on board with this.
I think what's happening in organizations where we're still facing this friction is that, as product managers, we're really good at working small, but we're not great at thinking big. We're not thinking about how to scale these things and how to get the rest of the people on board with this or change our organization. So, let's talk about organizational culture for a minute. I found a great definition of what organizational culture really is in companies. It says that while national cultures are based on deeply held values, organizational cultures are more concerned about practices. The repetition of practices or behaviors within a workplace helps define the organization's culture. I hear a lot about cultures being our values, beliefs, or feelings within the organization. But at the end of the day, it's really about what we're doing on a day-to-day basis and how we're interacting with each other. We need to remember that.
Think about your practices and the practices you're implementing in your companies right now. What are you doing on a daily basis? A lot of the time, we focus on product management practices. But how are we involving sales? How are we involving support? How are we involving everyone else in the organization in our practices? That's what we really need to look at.
What happens in organizations is that we're not working together like a great team. I like to liken this to a poorly run kitchen. Imagine you're the product manager, and you're a sous chef in the kitchen. You should actually be the executive chef, but you're a sous chef. You can do your MVPs, you're great at prototyping, and you're fantastic at user research. But you've got sales over there who knows how to sell things, and they're great at those pieces. You've got marketing, who can create a great sauce and market everything, do all the branding. If you don't put those together in a great menu, in a great dish, and if all those pieces don't come together, it's going to taste terrible, right? That's what happens to our products, and this is what happens to our organizations. This is not how well-run kitchens operate, right? This is not a three-star Michelin restaurant if you're working like that. We need to figure out how all these individual pieces come together to create that meal, to create that experience for people. That's what we really need to strive for. We don't want to be McDonald's; we want to be a three-star Michelin restaurant. That's what we're trying to achieve with our product.
As product managers, we need to start taking on the role of executive chef and figure out how to orchestrate a great product experience. Now, that sounds great, but how do we get people on board if they're scared, right? We've got all these people in sales, marketing, and other departments saying, "No, I don't want to do that." The reason they get scared is due to two things: a lack of knowledge and a lack of control. When they don't know how to work with you, they feel out of control, and that's scary, right? You need to empathize with them a little. If you say, "We're going product-led," and they used to be sales-led, and as a salesperson who makes 50% of my salary on commission, you're now telling me I have no control over the product—would you be scared if you said 50% of your salary that you take home to your family every year was on the line? That's what's really causing people to feel scared about these changes. They just don't know what that picture looks like.
We can fill in the gaps for them as product people, and to do that, we need to concentrate on two different things. The first one is product strategy. We need to build a great product strategy to help align the organization around where we are going, so everyone is on the same page about what we're doing and what we're pursuing. The second piece, which you may have heard some buzz about, is product operations. Product strategy tells us what we are doing, where we are going, and why we're going in that direction. Product operations tells us how we're going to get there. This is not just for the product teams; it's for the whole company. This helps align us around how we want to work in a product-led company.
We really want to start with product strategy. Product strategy tells us what we're doing and where we want to go. You can think of it as the meal, the menu, the dish of what we're actually looking at if you're working in that restaurant. But it's not just the dish; it's the experience too. It's the service and all those things that make dining out fantastic. That's what a product strategy is about, and that's what we need to craft and set for the entire organization.
In many places, though, this is missing. I come in and work with companies, and I often hear from executives, "I don't know what's going on. I don't know what people are doing. I've got 5,000 teams out there. What are they doing?" Meanwhile, the teams are running around, working hard, but they're not producing results. When you come into an organization and see a lack of strategy, there are a couple of observable gaps you can look for in behavior. Stephen Bungay wrote a book called *The Art of Action*, which is a great book on strategy if any of you are looking for one. In this book, he explains that we have outcomes, plans, and actions that make up our strategy. When those things do not exist together, there are observable gaps in the way people behave.
The first one is the knowledge gap, which is the difference between our plans and our outcomes. You can tell if you have a knowledge gap if you have salespeople or executives coming to you and saying, "I need more information. Tell me exactly what you're doing." Does anyone have that experience with people coming over asking for information all the time, not leaving you alone, and you're like, "Just leave me alone; let me do my thing"? It's because of the knowledge gap. They don't know what you're doing; they lack transparency into it.
What happens then is that our plans and actions are not aligned, which produces an alignment gap. In an alignment gap, executives have something in their heads about what they want us to do, but we're not doing it. They don't feel like people are aligned, so they come over and start dictating what you should do. They give you more instructions, saying, "Hey, I want you to build this. Make that button purple." They're trying to regain control because they don't have the alignment they need.
The last one is actions to outcomes, which is the effects gap. This is the difference between what we expect our actions to achieve and what they actually achieve. In organizations, we are all doing our work, we're on our product team, and we're doing everything great, but where is our revenue? What are the outcomes for the business? Why aren't we achieving them? That is the effects gap. When we observe the effects gap, everybody starts blaming each other. "It's sales' fault. It's product's fault. It's tech's fault." This happens all the time in organizations, and it's key because it stems from a lack of strategy.
Most organizations have something like this: they have a company vision, and then they have solutions. That's their strategy. The company vision is often something like "make more money." Great! But what am I supposed to do with that? How? We're all frustrated because we don't know how they want us to make more money. It's like, "I could do so many things. Do you want me to sell candy? That will make money, but I don't think that's what you want."
What's happening in many of these organizations is that we're missing what I call the "missing middle." This is a lengthy concept, but we're looking at strategy layers. It's not just about having a vision and having solutions; it's about having the appropriate level of strategy at each part of an organization. Typically, we start with a company vision. The company vision is about where we want to be in five to ten years, what value we provide for our customers, our position in the market, and what our business will look like if we fast-forward five to ten years.
Now, that's not just "be the best bank." What does "best" mean, right? What does it actually mean to "be the best bank"? That's what we want to clarify in the vision. The vision is usually not just a statement; it's carefully crafted through a longer memo that the executives or CEO puts out. They explain what that means and what customers should be doing, and they put slides together. It's not just one statement like, "We are the backbone of healthcare." I once worked with a healthcare company that said that, and I asked, "What does that mean? What's the backbone of healthcare?" Nobody in the organization knew.
Once we have a vision, we look at strategic intents. These strategic intents should be lofty, business-focused goals. They might include things like moving upmarket, moving downmarket, or solving problems for a different type of customer or persona. These intents are focused on the entire company, not just the product or software, and senior leadership sets them. The C-suite collaborates on this, usually looking one to three years out.
Next, we examine our product portfolio and ask what problems we can address to tackle those strategic intents. What do all those products come together to do? Are we building a platform? If we're doing a platform with various products, what does that look like? What should it solve? What should people be able to do? This is usually set by the chief product officer and the VPs of strategy.
Then, we have our product strategy and initiatives for each individual product. Finally, we get into the teams, which is about what solutions we're building for that. All of this is organized by time horizons. The teams will be working three to six months out, while leadership is working one to three years out. If your leadership is working longer-term like that, it doesn't compress the strategy. They're not dictating down to you to build that button, right? That's how we get them to rise up and focus on the longer-term goals.
This approach is for a very large organization with many different products. For a company with a single product line, you won't have a portfolio of products. This scales depending on how big your company is, and for startups, it's not relevant at all. If you're a startup without product-market fit, you need to experiment your way to figure out what the strategy should be later. This is for companies that are scaling, and this is what we need to focus on for scale.
In organizations, the reason we don't operate this way is that teams often work in silos. Product has its own strategy, marketing has its own strategy, technology has its own strategy, and sometimes, in many organizations, there's this business piece. You're left wondering, "What's that?" If you're not in a SaaS company, a lot of times there's the business, and you're like, "What does the business do?" If you've been in a financial company that started to transform into a product company, there's some friction there. The business is used to telling the technology and product teams just what to do, and they still view you as IT. They still think you're back-end people who just take their requests.
However, what we're finding in many of these organizations is that product and the business are actually becoming the same thing. In a lot of financial companies and companies undergoing transformation, we're starting to see this. Think about what you sell with software today. In many organizations, you wouldn't be able to sell anything if you didn't have software. You wouldn't be able to deliver on those things. We're seeing that product strategies and business strategies are becoming very close. This trend is only going to continue.
I was talking to a large bank in the United States a couple of weeks ago with their CTO and CEO, and they said, "I think the product and the business need to be the same for us." I was like, "Yay! We did it! We actually got there!" It's been seven years since I've been working on that, but we got there, right? This is where it's headed. As product managers, we also need to be mindful of the business. We need to communicate in business language to the executives about how much money we're making, where we're going in the market, and bring that up.
If product and business are starting to merge, we need to operate as a team. We need marketing, product, design, sales, and tech to come together to figure out how all these things work. We can't operate in silos. We need to see our executive team start to work together to set goals for everyone and themselves. They typically create these strategic intents, which are often missing in many organizations. These intents might prioritize increasing retention in small and medium businesses before moving upmarket into the enterprise. I would say no more than three strategic intents is a good number. I had one company try to create 87 of them, and it didn't work. But everybody tries.
What this does is align all functions around what we're doing. Now we don't have marketing and product arguing with each other about priorities. If we're going to prioritize, we now have something to prioritize against. That's also a big question I always get from product managers: "How do I prioritize?" You can't prioritize in the absence of strategy. It's impossible. That's what we need to do.
To get to those strategic intents and product initiatives, it takes a lot of work. We can't just lock ourselves in a room in November and say, "Let's build a strategy in two days," which is often what we do. I like to use something called the product Kata to set these strategies and think about how to deploy them. Kata is a framework that came out of Toyota in Japan, and it's how they practice continuous improvement. There are a couple of different steps. Our steps are very similar to what they use in Toyota Kata, but they align closely.
First, strategy comes into our part of the organization, and we understand the direction. As product managers, we ask, "What are the product initiatives? What's the company vision? What's the strategy over here?" We analyze the current state of where we are compared to that direction. Where are we now? Are we solving those problems for our customers? Are we even thinking about those customers? We need to do a lot of data analysis, both quantitative and qualitative, and gather inputs from sales, marketing, and everyone else.
Then, we look at that data and break down what our goals should be and what our direction on our team should be, and then we execute. By executing, we get into those practices I mentioned earlier. That's where we do our MVPs, prototyping, and whatever is appropriate for the context. But this process is not just linear; it wraps around. We look at the execution of that goal, take feedback, and ask, "Are we closer to that direction? Are we closer to that vision?" Then we keep going.
This process is not just happening on teams; it starts to happen at every level of the organization. We need to be aware of where we are and where we want to go and deploy that. In an organization, there are many levels to this. Your teams become each level. For example, executives understand the company vision, analyze the current state of the company, and set the strategic intent. That flows down to the CPOs and VPs of product, who do the same thing. They look at the strategic intents and ask, "Where's my product portfolio compared to that now? Are we solving problems for the enterprise? Do I need to introduce a new product to do that? Do I need to improve the products we have?" They analyze the current state of the strategic intents compared to their product portfolio and set the portfolio strategy.
This flows down into our teams. Another layer of VPs or directors comes in, and they do that for individual products, and then it goes down into teams, where we do that for solutions. Now, we are the only people who can execute—product managers on teams. That's where the execution comes in. We need to feed that information back. We iterate around that direction to understand where we need to go and what solutions we need to bring. We communicate that back, saying, "Okay, I tried this thing. We did this experimentation. We launched these products. Here's where we're at. I think we need to set different product initiatives to get closer to that portfolio strategy." That feedback goes all the way back up to the executives.
If we deploy this well and connect all these dots together with data, it allows us to relate all of these things back to the business better. If you can trace how your option or solution connects back to the strategic intent, that's the business connection you're missing. We can now tell stories when this is deployed well. "I believe that by building this product, it's going to get us closer to solving this problem for our customers, which in turn will allow us to enter the enterprise market. With this first release, we think we can capture this much of the enterprise market and make this much money." That's what many of us struggle to do. We say, "Hey, I could be like a back-end team doing a bunch of data stuff. How does that connect to the higher-level stuff? How does that connect to what we're doing as a company?" This is how we do it. You need the strategy to be able to do those things.
With that, we also need to know how to get that data. This part is so hard, and it's the part that a lot of companies skip. In the absence of data, you will start to make things up, and that's where you get all these product initiatives or solutions that we're building, and you ask, "Why are we doing that?" It's because you didn't have the right data, and someone made a decision based on a guess. This is where we start to involve the rest of the organization. This is where we really begin to collaborate with them, and that is product operations.
Product operations, you can imagine, is like how your kitchen works together. It's how all these pieces come together to build that great menu and create that great experience. Product operations is fairly new, but many companies are doing it successfully. Companies like these, plus many more, are implementing product operations today. This is not just one or two little companies; it applies everywhere. I've seen enterprise companies do it, huge banks are doing it, and smaller companies are doing it. You start to need this when you begin to scale. If you're a startup of five people, not yet, but if you're starting to scale and losing track of what's going on, that's when product operations becomes essential.
Let me tell you a little bit about what that looks like. Product operations has three different facets that we're looking for. The first one is getting business data and insights. This involves looking at what we have in our company that we can pull out and feed into the product team so they can set that strategy. Where are we now? This involves analyzing the current state. We often have a lot of this information locked away in various places in the organization, and it's about getting it out.
Next, we look at customer and market insights. To make decisions, we need to know what our customers are doing, what they're thinking, and what the market is doing. This is another piece. This does not replace you as a product manager doing customer and market insights; it helps you do it better. I'm sure many of you have found it challenging to line up customers to talk to all the time. Product operations helps fix this; it makes it easier for you to get in touch with customers and obtain the market research you need. It doesn't replace it; it's enabling you.
The last facet is process and governance. This involves scaling your product management value with consistent cross-functional practices and frameworks. This means not just within the product team but also outside the product team. It's how sales works with us and how people plug into where we are going as a company and how we develop products. We look at these three areas and want to build them up in an organization.
The first one I usually recommend people start with, especially if you're in a high-growth company, is business data and insights. If you want to grow really fast, you need to look at your business data and insights. Remember, we need all of these inputs to make product decisions. Where do you get them from? A lot of places, right? If we want user research, we have a UX team that probably has insights. User research teams have insights. Sales, believe it or not, can provide valuable customer insights. Support and account management teams are also talking to customers. How do we find out what they know? That's what we're trying to do.
In market research and data, we usually have a go-to-market team. It might be product marketing for you or other people out there. Product marketing or strategy research teams are looking at market trends. These are the folks who calculate your Total Addressable Market (TAM) and your Serviceable Available Market (SAM) and figure out where your opportunities are. But we need to provide them with some direction on what we should be looking at, so they can feed back to you about market trends.
Then we have financial data and implications on sales. We want to look at finance and business units if we're a little bigger. Salespeople can provide a lot of good information. For example, how fast can we sell? If you're modeling out your roadmap and want to go in a certain direction with a product, you also need to know how fast sales can sell it. Some of these decisions come down to whether we should build it and hire different salespeople or expand our sales team. If we build it, can sales sell it? It's not just on us; it's also on them. We need to understand that to model out what we can achieve.
For user data, we have data analysts who can pull it out. We have systems like Pendo and Amplitude to help with that. For technology implications, that's what our tech teams are there for. And then there's compliance and legal—everyone's favorite topic. They will tell us what's happening with regulations and what we should care about. We need to figure out how to get these insights back into the product team, and that's often challenging. But to do our job well, that's what we need to accomplish.
Many companies are already doing this. One great example is Fidelity. Fidelity is huge; I think they have about 45,000 employees. This is a major company in the U.S. that manages retirement accounts. Jen Cardello is their head of UX insights and research. She's a senior vice president of UX research and insights. They set up teams to have both a UX research team and a strategic research team. They help plug into the product development process to provide insights back to the team.
They do this in a couple of ways. For example, when starting with idea creation, they might help product managers craft how they're going to interview people if they're not great at that. They have built a system to collect all the research insights that all the teams are doing. Let's say there are 5,000 product managers at a company. One person goes and does user research with a customer about how they invest. How does the rest of the teams figure out what that research was? What happens is we keep duplicating research over and over again in organizations. A lot of times, the answers might be fresh and right in front of us. This approach brings it all together so we can look at it.
They also train product managers and other business members on good user research. Jen created a certification program where they train people who have not done this before and teach them how to conduct user research. They also built databases of customers to contact for user research. They send out surveys and different requests to find out who wants to opt in for user research and help them get in touch.
We also did something similar when Jen and I worked together at Athenahealth. We built a system in that organization as well, making it easier for product managers to find the people they wanted to test with and conduct user research. This way, it wasn't like pulling teeth, and we weren't contacting the same people repeatedly, which is typically what happens.
Strategic research helps calculate TAM and SAM, look at what our solutions are doing in the market, and how they're solving problems. They can help you quantify your opportunities. These teams plug in throughout the entire area to help gather more insights. It's not just about people; it's also about building the software and tools to enable you to conduct better user research. Many tools are emerging on the market now to assist with this. One example is Dovetail, which I really like. It helps collect and store research across organizations, making it easier to query and find out what people were discussing.
In addition to these types of things, we also need to ensure we're getting feedback from other departments, such as sales and customer support. This is how Pendo started with product operations. Christine was the head of product operations at Pendo. They came to her and said, "Hey, we've got a problem. Sales and product hate each other. Fix it." A very lofty goal! But Christine looked into it and started to figure out how to keep the sales team and product teams aligned.
What was happening was that sales was frustrated because product was not communicating with them and wasn't listening to their feedback. Product was frustrated because sales kept trying to dictate their roadmaps. They were constantly asking, "Where's the roadmap?" So, Christine built the product operations organization to keep that line of communication open. They collected feedback from sales and built a system to track it, ensuring it reached the right product managers at the right time. They created a framework that made it transparent for sales to see how their feedback was being tracked. Are we actually going to do it? Are we not going to do it? Did we experiment around it and find something else? This dialogue remained open.
They also helped craft the right level of roadmaps so that sales could see what was going on and had the transparency they needed. After doing this for a while, it worked really well. Sales and product stopped fighting with each other, and they started to gain valuable insights from sales. Sales began asking the right questions that product needed to make decisions.
We also went one step further when I was working at Athenahealth, a large healthcare company in Boston. I was helping lead a product management transformation there. We had 5,000 people and a $6 billion company. We found that sales was overselling the roadmap. Never happens, right? That's not a common issue! What we discovered was that they did not understand that a prototype was not a finished product. They thought it was ready to go, and it was not.
So, we created a framework to discuss how we were releasing things. We had discovery, experiment, alpha, beta, and generally available stages. We communicated that if something was in discovery and experiment mode, we did not know if we were going to release it. We asked them not to sell it. If it was in alpha and beta, there was a good chance we would release it, but we were fine-tuning the user experience and scaling. We told them they could talk about it, but they could not promise it until we gave them the go-ahead. "Generally available" meant they could sell everything.
We aligned this back into the design teams, and they plugged in at these different levels, just like Jen's team does at Fidelity. This really helped us, and it made it so that sales was not overselling the roadmap. It actually worked. Once we all spoke the same language and had a defined framework for this, we had better conversations and were able to navigate around that issue.
This also allowed us to make information more transparent, so it felt like we weren't hiding things. That helped address the knowledge gap we discussed with executives. We want to put things out there and track them in systems so that executives can evaluate the strategy. We want to use tools like Dragon Boat, Product Board, or any product management software to track what we're doing—not just what the teams are doing in stories or technical data. We need to elevate it to a higher level and look at where our OKRs are going. We should review these OKRs to ensure they work well.
As executives and product managers, we should monitor our progress, but we need to do that with a great framework. That's where our cadences come in. We use agile cadences all the time in organizations, and we talk about that a lot. But agile cadences are only one piece of our strategy. We are only reviewing and monitoring that piece. If we want to scale our strategy, we need different meetings. Monthly, we should gather to look at our product roadmaps, evaluating the options towards a product strategy. Quarterly, we should review our portfolio and product initiatives to decide if we're on track. We might have an internal product meeting and bring sales in as well, tailoring communication so they can see what's coming up.
As executives, we need to conduct quarterly and yearly reviews to evaluate our strategy. Ideally, this creates a nice flow where we say, "Hey, we're almost done with that strategic intent. What's next?" We're not just waiting until November to figure it out. It could be March. We might hit our strategic intent in March and say, "Let's add the next one. Let's think about what's next." Product operations helps design these meetings, invite the right people, and ensure they're held. They can also help standardize templates that are helpful, such as strategy memos, OKR reporting, go-to-market documents, and roadmaps. These should touch not just product management but the rest of the organization. We need a consistent way to communicate that.
What this does is help onboard product managers. It helps everyone get on the same page. You're not using 18,000 templates, which can help you work more consistently and provide transparency for the rest of the organization. We need to focus on these things as well.
If you put all of these elements together with product operations, you get better communication and collaboration, better strategies and business outcomes, and now we can track them. We know how it's laddering up, and we can see the data coming in. We achieve better product launches and better onboarding of product managers in our systems. That's why I'm writing the next book on product operations, which will be out later this year. This is really the glue that I've seen that helps solve these problems for our organizations and brings everything together about how we do things as a company and how we become truly product-led. We need to provide people with that formula.
If you go to productoperations.com and sign up there, we'll notify you when the book is out. My colleague Denise and I are teaching it. Once we put all these things together, let's revisit the beginning. We talked about the lack of knowledge and lack of control—really the things that prevent people from getting on board with being product-led. If you implement product operations and help set the strategy, we can address the lack of knowledge. If you look at the lack of control part, when people see how they plug into the system and how we have that collaboration, it helps with the lack of control.
But at the end of the day, you might still have people who are resistant. You will probably still have naysayers who do not want to go on this journey with you. For that, you really need empathy—empathy for where they're coming from. Let's say you have a crazy founder CEO. Nobody has that, right? Most founder CEOs have never been a CEO before. They do not know what they're supposed to do. I work with a lot of them. So, empathize with that. They have never done this before; they're on this journey. The reason they're going nuts is that they were doing your job, and that's the job they know how to do. They don't actually know how to be a great CEO.
This is their first time doing it. They actually appreciate when product people or product leaders come to them and say, "Hey, I've got this template. Do you think this might help us do this?" Or, "Let me sit down and ask you about your strategy, and I'll type it up." Don't even ask for permission; just say, "Can you tell me about the vision? I'll write it down if it doesn't exist. I'll show it to you and say, 'Hey, I thought it would be good if the rest of the company heard this too. Do you think this is right?'" They actually love that. It's about meeting them where they are and empathizing with their situation, and that goes for everyone across the organization, all of these different stakeholders.
If you want to change a culture, if you want to change an organization to be more product-led, you need that empathy. You also have to ask yourself, what are your practices and behaviors? What are you doing as a product manager? Are you involving sales, or are you telling sales, "No, don't talk to me; I own the product"? Are you discussing the strategy and vision with people, or are you waiting for them to communicate it to you? How are you collaborating with others? If you want to change an organization, you have to change their practices and behaviors, and it starts with you. You are the executive chef, and you have to go out there and start to create that menu and dynamic for all of us to work well together.
Thank you very much for listening to this. If you would like my slides from this presentation, you can go to productslabs.com/beyond and download them there. If any of you are heads of product and want to learn how to be better executives, I have a CPO Accelerator for that, where we train a group of product executives. I also have a Product Institute for product managers who are just learning this. Thank you very much for having me, and I will see you all!