In this thought leadership article, I’m speaking with Chief Product Officer, Spencer Parker, about how founders and product managers can become better at product strategy. Spencer has spent more than 26 years in product management, and in this article, he will share his advice and thoughts from his experience leading product strategy at startups and publicly traded companies.

Many of the founders I speak with struggle with product strategy. Why do you think so many startups find it difficult to create a product strategy?

“I think there’s a whole number of different reasons. First, you need to ask the question: what is strategy? Because from a company perspective, there are two main strategies: there is the company strategy, and then there is the product strategy. And you can never have a product strategy without a company strategy. And I think a lot of startups run headlong into trying to create a product strategy before they even sort out their company strategy. And then they get things wrong at the company strategy level.”

But it’s not only product strategy that companies often get wrong. According to Spencer, startups often confuse goals with strategy:

“When I talk to a lot of startups, they will tell me their company strategy is to reach $100 million ARR within the first five years. That is not a strategy; it’s a goal. Goals and strategy are two very different things. Strategy is about how you are going to get somewhere, not the signposts along the way.”

Spencer goes on to emphasize that the first thing a company needs to do is sort out its company strategy:

“The company strategy is more than just the product. It needs to be done by the founders fairly early on, even before they have an MVP out there. It involves how the leadership team should lead, how the company should present itself, and its very reason for being.”

But starting early on the company strategy doesn’t mean that it needs to be written in stone. In fact, Spencer emphasizes that a strategy rarely stays the same:

“Often it takes a good year into a startup company’s life before the company strategy is solidified. Over time, the strategy can morph and change a bit. Different decisions are made that take the company in different directions. Markets change, and there are all sorts of external influences. So, things change. Nothing ever stays the same when it comes to strategy.”

But once the company strategy is in place, then Spencer recommends creating a product strategy, which defines how the company strategy is going to become a reality through a product itself. However, Spencer mentions one common mistake to avoid when creating the product strategy:

“A lot of founders make the mistake of going too far out in the future. People start thinking in five-year strategies. You need to think more short-term. Where do we go after the MVP? What use cases are we trying to build towards? I think the very first product strategy should be no longer than a year. This will help you set the wheels in motion while moving forward with a three- and then five-year strategy later on.”

Now we’ve covered a bit about how startups should go about product strategy, but what is it about strategy that makes it so difficult for product managers in general?

“Strategy is really the one thing you can’t teach people. You can inspire people with as much knowledge as possible, but everybody’s brains work in different ways. Some people are very good at delivery, some people are very good at abstract thinking. Strategic thinking is another type of thinking altogether. And I have only come across a very small subset of product managers in my time that really gets strategy.”

As a leader in product, Spencer describes how he has experienced great strategic thinkers:

“When I see staff that are really good at strategic thinking, it’s like a hallelujah moment. Finally, we’ve got someone who is thinking outside the box here. It’s someone who is thinking five steps ahead rather than what we are delivering this quarter. When this happens, as a leader, I make sure that person gets on a fast track, because it’s a rare trait.”

According to Spencer, many product managers think and call themselves strategic.

“Working out a roadmap using RICE or any other techniques is not strategic thinking. This is not a diss to anybody who thinks like that. And it’s absolutely a valuable part of any product management team. You need analytical, data-backed decisions. But you also need to play into the strategic world, where some of it is more gut feeling than anything else.”

Spencer also mentions that if you want to do strategy, you have to be able to explain yourself clearly.

“You need to explain why you are making these strategic decisions and what made you go down certain paths. You don’t have to justify them, but you have to be able to explain them. Again, there is a big difference between justifying and explaining.”

But what are the signs that a product manager is good at strategy?

“First of all, certainly in the more junior product managers, it’s how much they question the roadmap. It’s the minute that a junior product manager comes to me and says, you know what? We could do all of these things, but we could also do something over here that is different from what our competition is doing. We can change the conversation with customers.”

Spencer calls those moments a lightbulb moment.

“It’s a lightbulb moment because they are not just thinking about it analytically, they are thinking about strategically, how do I beat that competition? And do I beat that competition by just copying everything they have? Or do I do something drastically different that changes the conversation with the customer? I’m always looking for those little shoots of people thinking differently, thinking outside of the analytical box.”

Now, I know you said earlier in this interview that strategy is not something that can be taught, but what would you recommend product managers and leaders do in order to become better at strategic thinking in their jobs?

“You need to have a bedrock of knowledge. The more knowledge you have in you, the better you get at starting to use that as your sort of bedrock of strategic thinking. So there is nothing wrong with reading books about strategic thinking and strategy. One of the traits of PM’s is that we are an information sponge. We love reading new books about stuff. We love bringing new data and knowledge into our heads.”

Spencer goes on to add:

“Starting out, you probably don’t have all of the knowledge you need. To start building up that knowledge, I recommend joining relevant book clubs. Next, I would recommend employing people around you who know more about things than you do. Know what you don’t know. Fill those holes with people that have better knowledge on certain topics and rely on their guidance in certain cases. Don’t think it’s all on you to run strategy.”

I asked Spencer if he could give some examples of what he meant by employing people around you with better knowledge than you in a product management context?

“You might be in charge, you might be the CPO or the VP of product, you might be the strategic person in the company. But don’t be afraid to bring knowledge out of people. Salespeople are going to be telling you stuff from the street all the time. Marketing is going to be telling you all about the competition, how they’re talking about it to customers, things like that. Suck that knowledge in, but then apply it strategically rather than analytically.”

But if you are not a CPO or VP, how should you go about presenting your strategic thinking to them?

“Put a meeting in the diary with the person that runs strategy, the CPO, or whoever might welcome these types of conversations. But be prepared. Don’t just say, ‘Oh, I’ve sort of got this idea.’ Do your research. Be a PM. Go talk to customers. Go talk to the sales team. Go talk to the sales engineers. Sales engineers are brilliant for this. They are the hidden gems in most companies. They do all the work for salespeople and don’t get paid anywhere near as much as they do, and they have all the knowledge needed to succeed.”

Spencer also mentions the importance of patience after presenting your thinking:

“The CPO’s time is precious. Go straight to the point. Deliver the details, deliver the data in a way that they can consume. Don’t always expect an answer there and then, because most strategic thinkers mull on things for time. And it could be suddenly, two weeks later, that the CPO comes back and tells you that was a great idea. How can we spike this thing?”

Now, earlier in this conversation, you brought up the importance of having a thirst for knowledge and constantly learning. As we are coming to the end of this interview, what is something you learned along the way that you have carried with you ever since?

“One of the best things I have done is to get the whole team to do a DISC assessment and put them all up on a MIRO board or something like that. You don’t have to go into the finite details, but just have a box with information like, this is how I like to be talked to, etc. That way you can go into any one to one with somebody and get the best out of them.”

Spencer goes on to add:

“We have to talk to a lot of different people in product management, and sometimes we have to have some very hard conversations. So knowing how that person likes to be spoken to in a hard conversation makes it a lot easier. This means you can prevent them from switching off or getting defensive. Often people respect you more and perceive you as fair because you come across to them like, “although we have a problem, we can solve this problem.”

In this thought leadership article, I’m speaking with senior product manager, Vanessa Desi Damblemont, about how product managers can build better products by crafting a strong product story. Vanessa has spent years managing products for everything from SMBs to large enterprise customers, and in this article she is sharing her best practices and advice for product managers who want to improve their decision-making process.

One of the challenges many product managers face when involving customers in their decision-making process is that their product might have many companies using it and within those companies many users.

When it comes to involving users and customers in the decision-making process, Vanessa recommends balancing different feedback sources to get a more comprehensive understanding.

When you have many customers and users using your product, you want to avoid getting biased by only focusing on a few customer interviews. I always try to balance feedback from different sources and customers. I go through feedback provided through our feedback buttons, tickets raised to support, notes from customer success managers, and conduct customer interviews.

But when do you have enough customer feedback to make a product decision? According to Vanessa, you have to collect feedback until you start seeing a key direction to solve a problem:

I collect feedback, bottom-up, until I have enough evidence to see a key direction for solving a problem. Then, I try to match the key direction with everything I know to make sure I haven’t forgotten anything. Afterwards, I will refine and iterate on the solution, then craft a short and clear story about what it does.

And there’s a really good reason behind why Vanessa starts building the story around the solution early in the process:Creating a story around what you are building gives you a long-term direction and helps the people you’re interacting with get more connected to the vision. It gives a common view of where you’re going and provides something people can easily buy into.

According to Vanessa, it’s important to craft a story that will make people excited to follow you. But as she also mentions, you need to do your homework and never start by presenting a blank page:

Creating a story is an interactive and collaborative process. But I had a manager a long time ago that gave me great advice: ‘Never start from a blank page, always have something to showcase.’ So make sure you always have something to start off with. Just start, do something to craft the narrative. Look at your data, do some quick user interviews. So I really try to apply that method of working. In France, we have a saying that says, ‘Say something wrong and you get to the truth.’ Because if you say the wrong things and talk with enough smart people, then at some point you get to the truth.

However, this approach of seeking the truth is not only helpful in building a strong product story, it also helps drive awareness and decision-making in the process.

When you involve people in the process, you build a certain level of confidence in what you have discovered. And by interacting with the right stakeholders and creating visibility, they will also be able to tell you if they believe you are wrong or going in the wrong direction early on, instead of too late.

In this pursuit of not starting from a blank page and getting to the truth, one thing to keep in mind is the influence of your own intuition as a product manager. Vanessa believes product managers need to be aware that their intuition is always part of the process.

You always make a decision about how much data and what kind of effort you put into understanding a specific problem. In fact, even before you get the data, you already have an idea in mind. Maybe the data will change your mind, or maybe it will help you get a better understanding. So what’s important is to have an iterative mindset. When you have no data, what do you think about this problem and why? And then when you have the data, how does it change your thinking and why? At some point, your views on the problem get stronger and stronger and help you create a strong story.

But what do you do when you craft a strong story and stakeholders disagree with the solution you come up with? How do you handle that disagreement?

It depends. But generally, it is important to always have a mindset of being as objective as possible and do your best to understand the rationale behind the disagreement. Be open minded to the fact that sometimes you can be wrong. Always remember that it is your job to give as much clarity and information as needed to make the right decision. And more importantly, always remind stakeholders that not making a decision is in fact a decision by itself, and that not making a decision can have real consequences for our customers, users and business.

While many bottlenecks on decision making can often be resolved in a timely manner, sometimes situations may arrive that are hard to unblock. For those situations Vanessa recommends thinking beyond the decision at hand:

The biggest problem is when people completely disagree with each other and are misaligned. There can be different things that are at stake at different levels. It’s not always about the solution. Sometimes it’s something unresolved in the company strategy and then you need to escalate to people involved in more high-level discussions. 

What’s one piece of advice you would like to give to other product managers and aspiring product managers?

It’s important that you like people. You will spend so much time interacting with people in groups, individually, and so on, and you will never be perfect at dealing with people. So it’s important to genuinely like people, get to know them well, and appreciate that everyone has a role to play. Never forget to be nice to people. This job simply has too much people interaction to only focus on figures and documents. Embrace the people and everything else will become easier in the role.

In this thought leadership article, I’m speaking with Lead Product Manager, Conor Murphy, about what he learned from interviewing more than 100 product leaders as part of his startup discovery process. In this article he shares the biggest misconceptions between the ‘Linkedin reality’ and that of the Product Managers actual ‘day to day’ reality.

In 2023, Conor was exploring a startup idea called Olta. He then decided to go on a 6-month journey to better understand how product teams work together. During that time, he pivoted again and again as he tried to find a niche that clicked. And in the process of doing so, Conor interviewed more than 100 product managers.

According to Conor, one of the first insights was that what he called LinkedIn product management vs the real world:

“The quickest and strongest insight that came out was that nobody was doing the very framework-based and objective-based product management that you always hear about from LinkedIn influencers in the product management space. Out of the 100 people I interviewed, I never found anyone who worked that cookie cutter way, and only very few people would get near it.”

Conor also mentions how most product managers believed that everyone else were working the way you often hear about from LinkedIn influencers:

“There were a fair amount of people I interviewed who believed they did a terrible job because LinkedIn influencers were telling them that this is how good companies should work.”

In addition to that, Conor experienced firsthand how people who worked at companies that supposedly used all of these modern frameworks didn’t use them at all:

“They would sometimes say this is how great companies like Google work. I had to tell people no, it’s not. I interviewed people from Google, and that was not the case at all. Sometimes I would have calls where people would spend 5 minutes at the end just thanking me for telling them that fact. Some of the product managers I spoke with were shipping fast and measuring their impact. I told them that just trying to do that is in the top 10% of teams.”

Throughout his interviews, people repeatedly expressed anxiety about not doing product management the right way. So if you’re reading this and feel the same way, Conor feels we should be easier on ourselves. Most product managers don’t work with frameworks or totally outcome-based product management.

However, Conor learned a lot more than just that during his research. According to Conor, many product teams have a simple and clear idea of what they want to do on a high level:

“Roughly speaking, they want a fast shipping team and some metric goal to prioritize most of the work around. Next, they want to be a fast learning team. And in that fast learning arena, a lot of product managers are looking towards continuous discovery.”

And when it comes to talking to users and product discovery, Conor made some interesting findings:

“Most product managers are very aware of the term product discovery. Many product managers at least want to do something like it. But it’s still very few who actually do it. Most of them are still busy getting to a fast shipping product team.”

In fact, in Conor’s discovery process, he was quite surprised by just how few product managers just talked to users on a regular basis:

“It is quite shocking. That is probably the one thing that surprised me the most. I would have guessed that maybe half of the product managers I would speak to would talk to users on a regular basis. In reality, I would say it’s only about 20%.”

But what were some of the reasons behind product managers not talking to users? According to Conor, there were several reasons most don’t talk to their users.

“It is definitely not a dislike of it. Everyone told me how they felt re-energized whenever they actually go and talk to customers. In a small number of companies, they explained how the culture of the company is blocking it or you have to go through sales. But the major reason from my conversations was that if you are on a roadmap anyway, what’s the point? If you have a three-month backlog, then you are probably going to execute it as is with only minor variations. In this case the leverage of talking to users constantly and learning is perceived quite low.”

Conor also mentions how time pressure appears to be the enemy of customer discovery:

“You can imagine the ideal process is you go talk to users, synthesize and document insights. But as time pressure happens, product managers stop doing the synthesis and documenting the insights. And then you stop talking to users as you don’t really get the end results out of it anymore. So between a culture of the company that does not reward talking to users and it just being time-consuming, customer discovery is always one of the first things to fall and one of the easiest habits to drop in the short term.”

But what about the product managers who do talk to users? What were the insights from those teams? According to Conor, the culture is often key:

“They have a culture and characteristics that allow them to. It can be things like designers being happy to pitch in, or sometimes developers jump on the call if it’s user research on the analytics side. It’s much easier to stay consistent on user interviewing if everyone helps and pitches in, and things can be picked up.”

And when it comes to ways to improve how they conduct user interviews, according to Conor, product managers are often very honest with their managers:

“Often, product managers would be honest about their shortcomings with their managers. And definitely, a decent amount of product managers explained how they were always wary of whether their research was good enough. But, I would say it’s often one of those things that if you are self-aware enough to think your research might be bad, it is probably not that bad. But there definitely is a bit of fear there.”

Throughout his interviews, Conor learned a lot, but one thing that he did not expect was how most product managers were trying to use frameworks:

“The final area that I found interesting was that no one uses frameworks as they are “meant” to be used. No one does the Jobs To be Done framework by the book. No one does opportunity solution trees by the book. That is largely because even if you followed the framework of the Jobs To be Done framework, then you had to spend your whole life explaining to everyone else in the company how it works. And eventually you get tired of that if use it religiously. So you just come back to talking about user problems. The same happens with opportunity solution trees.”

What is one piece of advice you would like to give to other product managers and aspiring product managers?

“There was a point in my career I was getting quite annoyed at being blocked. I was working on this big company transformation from the ground up. It was a very CEO-driven company, and suddenly one year’s work was blocked when the transformation appeared out of nowhere at the CEO’s level. He just blocked it. And I was furious at the time. But then someone who was advising me asked me why I acted as if the company was perfect, that nowhere is perfect and yet I had acted as if doing purely logical arguments will always win rather than working with the companies structures a bit. No one likes a fundamentalist preacher. You need to recognize both who you are and what the company is, not what it says it is, and match those two things as much as possible.”

In this thought leadership article, I’m speaking with senior product manager, Karen González Fernández, about the role of empathy in product management. Karen has spent years managing products for everything from startups to scale-ups. In this article, she is sharing her best practices and advice for product managers who want to get better at dealing with difficult stakeholders at work.

I often speak to product managers who tell me they are struggling to create great collaborations with sales, support, and customer success teams. Why do you think that so many product managers find it hard to create great collaborations with customer-facing teams?

“Something that I like to remind myself is that product management is all about tension. It’s really hard to manage tension. Everyone is pulling you in a different direction, and the product manager is the person in the middle that needs to make sure that everything is connected.”

While we are on the topic of tension, Karen goes on to add:

“The tension also depends on how much everyone is pulling in you, and how good you are at making sure that everyone understands the other side of the arguments. Many times, it’s really about making people see the full picture and decide on the trade-offs.”

According to Karen, it’s not only about helping people see the full picture, but it’s also equally important to build mutual respect and understand where people are coming from:

“For example, I have always felt tremendous respect for sales. It must be super tough to knock on cold doors every day, constantly getting rejected. So when sales comes to me with feature requests blocking deals, I can imagine how much effort it has taken them to get to this point with the client.”

But what would Karen advise product managers who feel like they are already doing everything she is recommending, but still have stakeholders coming back every time they need a feature request?

“A manager once gave me this great advice: What works best to create a more healthy culture is to open the doors to product. Product can easily be perceived as something that happens behind closed doors. Instead, product should be this open, transparent door, where everyone knows what is going on and how we prioritize.”

Karen goes on to give a concrete example of how the open doors to Product can benefit product managers:

“If someone brings a feature request, we should educate them on the trade-offs. What would we need to stop doing in order to do it? What are our business goals, strategy, and vision for the product? We could prioritize this feature at the expense of all of those things, but maybe two years from now, we can’t sell anything because we are not important in the market anymore. We need to own that conversation as product managers.”

But that is not always an easy conversation to own as a product manager. Sometimes these conversations can get heated and emotional. So how do product managers own those conversations with tough stakeholders?

“As product managers, we always have the toughest stakeholders. Every time we present something, it can be torn apart by stakeholders. So you have to find a way to deal with the tension. Tension is emotion, and below every emotion, there is a concern. So we have to find ways to calm emotions and get into the concern that our stakeholders have.”

When it comes to finding ways to calm down emotions, Karen recommends to always lead with empathy:

“I believe empathy is the antidote to getting triggered. Going into a stakeholder call with an empathic mindset can make the difference between success and failure. You have to be able to feel what the other person is feeling. When people feel understood, things always come down a bit. It’s not always easy to be empathetic, but it’s something all product managers need to practice.”

And if you want to practice becoming better at being empathic, then Karen has a great exercise to help you with difficult situations and stakeholders at work:

“If things start escalating with stakeholders, I always recommend doing the exercise of coming up with ten reasons why you wouldn’t like to be that person. It sounds like a really negative exercise, but when you get to reason number nine, then you begin to empathize a lot with the person. For example, I would not want to be the CEO and have all the weight of the company on my shoulders. You begin feeling how it is to be that person and understand their arguments better.”

But what do you do in those rare situations where a stakeholder gets more and more emotional regardless of what you do? According to Karen you should always use time as a buffer when things get too heated:

“You always want to try to move your stakeholders from emotions to their concerns. But sometimes it’s not possible to get past the emotions, and that is where it’s good to ask for some time to think. You won’t have any good outcomes if your stakeholder continues in a state of emotions, but sometimes, just having a couple of hours to think things through can do wonders on both sides of the conversation.”

However, if you find yourself in a situation where things often escalate with stakeholders, then Karen recommends to make sure you begin working on building better relationships:

“Building relationships is super important. It’s not about having transactional relationships, but building genuinely good relationships that people don’t want to damage. When your relationship overall is positive; a few bad interactions don’t matter, but when you don’t build it, a bad interaction can really break it.”

We have spent some time now talking about the emotions of other people. So I asked Karen what her best advice was when it came to managing your own emotions as product manager?

“This advice is not only for product management, but for life in general. If the other person notices that you are taking things personally, then you have already lost the battle at this point. Because either they will be thinking it’s personal, so we are no longer having a neutral conversation, or they will increase the volume of the tension because it’s about who wins from now on. That is why it’s key to understand your own triggers and don’t take things personally, or do your best to not show that you take it personally.”

But how do you get to know your triggers well and get ahead of them? According to Karen, there are some simple steps you can take to get better at this:

“First, you need to learn from failing. There is always an opportunity to repair things when you fail, and you need to make sure you reflect about what triggered you when you fail. Second, once you are aware of what triggers you, then you need to learn to take a breath when you feel the tension inside of you is growing. Just take a breath. Calm yourself down.”

As we approached the end of our interview, I asked Karen what one piece of advice she would give to other product managers when it comes to dealing with stakeholders?

“Don’t get scared of confrontations with stakeholders. Don’t be scared by emotions. Embrace emotion in order to get to the concern behind it. And remember, we are equals. You should not feel above or below anyone else because you are a product manager. Come into every stakeholder conversation with the mindset that they might tell you something important about the product that you don’t want to miss.”

In this thought leadership article, I’m speaking with senior product manager, Josefine Johansson. She has spent more than 10 years in product development across multiple industries. Customer obsession and customer focus is what all PMs aspire to. Josefine is here to share her actionable, replicable steps on how to actually get close to your customers. From booking your first meeting, to how to get the most value from every such interaction. The key – a close collaboration with the sales team.

One challenge I hear quite often from product managers is that they want to get closer to their customers, but don’t have a formal process internally to do so. What is your advice to those product managers?

“I have few things that can help kick it off. First of all, it can be a bit hard and you need to really work for it. Customer meetings are not going to happen on its own and you might have to ask multiple times before you get your first yes. First thing, which is very basic, is to start building relationships with customer-facing teams.”

I asked Josefine if she can elaborate on why it’s important to build these internal relationships:

“If you want to go on sales meetings like prospect meetings, you have to realize that this is what sales does for a living. A lot of their compensation is based on those meetings going in the right direction. So just bringing someone onboard without trusting them or knowing who they are and what they want, will make it unlikely for them to say yes to let you join the meeting.”

Josefine stresses that beyond building these relationships, you need to put an effort into aligning before each meeting:

“So you have to build a relationship with your sales team and go through the meeting rules beforehand. Ask the sales rep some questions to align on expectations: What are you going to do in this meeting? When do you not want me to interfere? Are there some do’s and don’ts for this meeting? I want to make sure that they feel comfortable having me onboard in this meeting.”

On the topic of setting up meetings, Josefine also emphasizes not to make the mistake of asking sales reps to schedule new meetings. Instead she recommends joining existing meetings:

“Don’t ask your sales rep to set up new meetings because you want to gather insights. Few sales reps want to add more meetings for the sake of adding meetings. Instead of that, join existing meetings, both internally and externally, where they are discussing relevant challenges.”

But Josefine also emphasizes the importance of not just being the fly on the wall in meetings. Always add value, this way they would be motivated to invite you again. Or spread the word to other sales people.

“Don’t just join meetings and say you want to be the fly on the wall, but rather ask yourself and the sales rep how you can be of use in this meeting? Make sure you always bring something to add value to the meeting. It could be a roadmap or feature presentation, or anything that you could do that can help your sales colleagues drive a better customer conversation.”

As Josefine mentioned in the beginning, you have to put in the work if you want to attend customer meetings. And she specifically mentions one pitfall to be aware of when it comes to scheduling meetings:

“If you get invited to a meeting, then never be like, oh I can’t join because I have another meeting that time, unfortunately. If someone invites you to go to a customer meeting, then you better make sure to skip whatever you have on the agenda if possible. Otherwise, it’s very unlikely that the customer meeting will be rescheduled to a slot that fits your schedule.”

Now you mentioned do’s and don’ts a bit earlier. What are some obvious ones in your experience?

“Generally speaking, I think you should really try to take a step back and remember you are not leading the meeting. If you are on a sales call with an account executive then let them lead the conversation. The most important thing is to build trust and continuously discuss how you can make them comfortable with you being in the meeting. Every sales rep will have their own do’s and don’ts depending on a certain process they want to follow.”

Now, if you’re lucky that you built a relationship and the sales rep trusts you and invites you to a meeting and you let them lead the meeting, but when it comes to your turn, how do you sort of approach asking questions?

“I would prepare a few questions. Normally there is something you’re investigating and a hypothesis you are trying to validate. So I would prepare a few questions and then also be on the lookout for insights. Most of the time, there is a conversation going on between the sales rep and the prospect, and then I would chip in with maybe a follow up question to get them to clarify or dig a little bit deeper into something. I always make sure I take as little space as possible. A lot of these meetings are also about being open to see where the conversation goes. Remember it’s not your research meeting, but rather time for you to hear what your customers’ challenges are.”

Is there anything else that is important to remember when you attend as a product manager in customer meetings?

“Never end up in a place where you promise things you can’t deliver on. Make sure it’s not perceived as a meeting where they can order improvements and whatnot. But rather be open about how the feedback is going to be treated. Make sure they understand how their feedback is part of a research project, and always thank them for taking the time to contribute to it.”

Now once you get the customer meetings rolling, how many of them should you actually conduct and how frequently in your experience?

“I don’t think there is an exact number as it depends on every situation. In general I think you should try to conduct as many meetings as possible, making sure you continuously build knowledge about your customers. But let’s say you are in a discovery process, as a rule of thumb, when you start seeing patterns you know that you have spoken to enough customers. You can conduct customer interviews in all eternity if you want to. I think the trick is to look at customer meetings as one piece of the puzzle. There are many other signals you need to factor into your research.”

As we approached the end of the interview I asked Josefine, what’s some advice that she has been given that she has carried with her in her everyday life as a senior product manager?

“Learn to speak executive language. Normally you are not 100% in charge of your resources and need some kind of sign off from people involved in the strategy process. You need to learn how to speak in bullet points and only highlight the most important parts first. If you want to get buy-in for what you believe in then you need to be able to persuade stakeholders higher up in the organization.”

In this thought leadership article, I’m speaking with Director of Product Management, Rikke Knutzen, about the transition from a private to a public roadmap, and how to work with outcomes rather than feature deadlines. This article only scratches the surface of the wealth of practical knowledge Rikke has on these topics, but nevertheless, it’s full of great advice and perspective.

Let’s jump straight into it. A lot of companies like the idea of having a public roadmap, but the product leaders often mention they are hesitant to do so for competitive reasons. What are your thoughts on that concern?

“One of the main concerns I hear from product leaders is that they are afraid of competitors copying them. My perspective is that you can either spend your time defending yourself from competitors or to get ahead of them. It all comes down to how you execute with features that can solve problems, not the ten lines you use to describe them on your public roadmap. That’s your differentiator. I would rather spend our time making sure we have great alignment with customers and execute well than defending that no one knows what we do and sort of keeping those defenses up.”

Rikke goes on to add:

“In a way, our product roadmap is our execution of our strategy in terms of how the product delivers on the strategy. And our purpose is to eliminate downtime, to build the most useful industry for the world. And if we don’t have that in transparent format, then how are customers and partners going to be part of the movement to eliminate downside? It’s our core principle around collaboration and transforming the ecosystem. We simply have to be transparent, otherwise that’s never going to happen.”

How does the public roadmap impact internal teams like, for example, customer success?

“We make sure to show customer success the benefit of not having to relay roadmap information. Instead of spending time on communicating features on the roadmap, they can spend their time getting customers to adopt existing features. The roadmap is right there in public. They don’t have an outdated PowerPoint presentation. Customers can just read it themselves and comment to learn more about upcoming features from the product teams.”

Speaking of the product teams. How do you make sure new product managers who aren’t familiar with public roadmap work correctly with it?

“We heard very few concerns from product managers we hired over the last few years since we adopted a public roadmap. But we do have a governance model around it. If something is 6 months or less from launch, you can just go ahead and launch roadmap items on our roadmap as a product team. If it’s more than 6 months out, then you get some sparring to make sure we don’t put anything out there that we don’t want to display broadly, such as new things that can be perceived as cannibalizing existing products, or that we might put back on the shelf again etc.”

According to Rikke, it’s about creating an empowering culture, where people are not afraid of being transparent about what they are working on and making changes to it in public:

“If we did not have a public roadmap, then it would be hard to change anything quickly. Now, if a colleague decides they made a mistake or want to make a change, they can just change it quickly and it’s updated. We had a colleague who posted something the other day. I actually did not believe it belonged there. We had a few talks, no harm done. Then he decided to take it down. But if he hadn’t posted it and asked for permission first, then we would stall the process of creating transparency and utility.”

I noticed that you also generally don’t work with deadlines on your public roadmap. What are your thoughts on putting deadlines on things?

“I think deadlines will never go away. We still make high integrity commitments to large customers. I don’t think empowered product teams shouldn’t do any customer commitments at all. At least, I never saw that in the real world.”

Rikke goes on to add:

“When the team knows the customer’s problems and the value that they want to drive, they are the right ones to make those detailed priorities. We don’t want to put dates in our public roadmap. I think a lot of the product managers are relieved that they shouldn’t keep deadlines, but they have also realized that they are now more accountable than when you just have a deadline. Now they are actually accountable for solving the problems they believed in. You can’t just say that you were given this scope and time and had to execute on it. So with that great freedom comes responsibility.”

I think many product managers who aren’t used to working this way might be a bit anxious about what happens if they don’t deliver on outcomes. How do you make your product managers comfortable with the risk involved in having the responsibility of driving outcomes rather than outputs?

“We have a few frameworks we use and talk a lot about the importance of working hypothesis-based. It’s okay to say that “I don’t know” or “I’m not sure this is working right now”. When we onboard new product managers who come from a culture with deadlines, then you have to go through a process with them where they change the language they use. They need to learn how to say this is what I believe in based on these insights, and this is what I am unsure about. So getting comfortable with talking about risk and what you are unsure about because you never know until you launch.”

But how do you make product managers comfortable with sharing those sometimes very vulnerable thoughts?

“We have a culture of surfacing risk and sharing mistakes early, broad and loud. We as leaders role model this culture when we make mistakes. I just made a mistake last week, and found out that we had a mistake in one of our processes that prevented us from delivering something for three months. I took accountability, shared it with my team and explained how we could move forward and fix it.”

Coming back to the public roadmap again. How do you manage situations where something launches according to the roadmap and then you need to spend more time iterating on it?

“Our public roadmaps are very ideal descriptions of the value we want to deliver. We don’t have click-through prototypes, so if we need to spend more time iterating, then we talk more into the problem we want to solve rather than the solution itself. So rather than showcasing a detailed feature set, we stick to describing the problem we want to solve instead, and that gives us the flexibility to iterate if we don’t hit the mark on the first try.”

Now, we talked a lot about the public roadmap and deadlines so far. If we take a step back, what would be your general advice to companies considering changing to a public roadmap?

“You have to strategically consider what version of a public roadmap you feel safe enough with that is then good enough to try. You can always add more to it and take more risks later on. You can even start with just launching very high-level descriptions. So choose the level of depth that you feel comfortable with as a product leader.”

Rikke goes on to add how they started themselves:

“You have to find the courage to start somewhere. When we launched our public roadmap it first had a private link that our CS colleagues could share to customers. That was our first attempt that felt safe enough back then. And just earlier last year, my marketing team reached out to ask if we could put our roadmap on our website? And I was like, oh, I’m not sure I’m comfortable with that. And they challenged me and asked why not, Rikke? Now we are at the stage where we can be more courageous. The thing is, you have to build your courage and add transparency as you get more courageous as a company.”

And there is one more important piece of advice from Rikke if you want to do public roadmaps. She recommends not having pseudo roadmaps. I asked her to elaborate on what she meant:

“So we have different types of transparent roadmaps. One is directly to customers, which is the one with high-level descriptions. The other one is more internal for colleagues to get a sense of when these features are coming out. We tell customer success  that if they share the internal one, then they are on the hook for managing expectations as we know deadlines always shift around. If you share the public one then it’s always updated and you can actually mitigate the risk of telling a story that later will change.”

Finally, Rikke mentions the importance of having some internal champions who really believe in having public roadmaps:

“You need to have a few colleagues who love the public roadmap so deeply because they are passionate about making sure we are as transparent as possible, even if it’s not their job, they make sure people are using it and everything is up to date. Nudging people to keep using it. Because if it’s just something that is pushed down from leadership that will never create that natural attraction to doing it. Some people will of course love it more than others, but as long as you have your internal champions it works smoothly.”

Here at the end, I would like to focus on something else that public roadmaps. And that’s one piece of advice that has always stuck with you? Something you keep coming back to and use in your day-to-day life?

“Yes, it’s hard to be curious if you are reacting to frustration or emotional discomfort. Whether it’s a customer problem or feedback from your manager or a peer, you have to remember to reflect before reacting. Be empathetic, understanding, and curious to learn more about the context instead of just reacting to it.”

Rikkes goes on to add a specific example and the importance of having a concept of what she calls 200% accountability:

“If I get feedback personally, I want to make sure I understand the specific situation and context instead of just reacting to it. But we also have an important concept called 200% accountability. It means that both the person giving the feedback and receiving the feedback are accountable for understanding and making changes needed. There is never just one side. You have to be accountable for how you give the feedback as well as receiving it.”

In this thought leadership article, I’m speaking with product operation manager, Matias Bruhn Klenz, about what it’s like working on product operations. Matias has spent years as a senior product manager and later transitioned into the role of product operations manager. In this article, he shares his learnings and advice on what it’s like working in product operations and how to be successful in it.

To kick things off, what is product operations about? What does it actually mean to you at Pleo?

“In our team and at Pleo, we actually don’t call it ProductOps. We are mixed up a bit in something we call Maker Operations, which actually covers more than just products. It’s about everything we make, build and product, so not just in product management, but also in engineering, design, analytics and how we play together. The mission in our team is to make it easy to run high performing teams and carry out individual work.”

But how do you actually make it easy to run high performing teams? What does the reality of that mission look like in practice?

“In reality, it’s about both supporting the things we do well and making them easier to do by offering tooling, processes, documentation, and standardization where it needs to be used.”

Matias went on to add a bit more context to how it works in practice:

“And then it’s also about the enablement part. Once in a while we need to be out there digging into a specific topic, helping and coaching, or do workshops to help enablement.”

I was intrigued about the potentially broad range of tasks that you could do as a product operations manager and asked if Matias could give some concrete examples:

“It can be anything from helping to describe how we can most easily do some A/B tests in this setup we have, to how you can become more outcome-driven and work well with outcomes. It’s also tasks like redefining how we do continuous planning in close collaboration with people in senior leadership. So it’s a really broad range of tasks you do in product ops.”

So how does Matias look at himself as a product operations manager in the context of his colleagues?

“You are often the glue that is needed for everything to function. Something happens at a point where the company becomes a certain size. Maybe you are suddenly 10 teams, and you all have to create roadmaps together, navigating different stakeholders with different needs, and things suddenly become slightly more complex to organize and service. Who sets up processes? Who makes sure it works? Who helps educate and teach people how to use the tools required? And it’s things like that we take care of.”

It makes sense, but at the same time, it seems like the complexity of some of the tasks can be difficult to approach. How do you approach these tasks as a product operations manager?

“Yes it’s definitely complex and something I think about. I use my past experience as a product manager a lot. The reality is that many of the things we do are exactly the same as when you sit in a product team. If we were to create a roadmap process to service 35 product teams and 500 consumers, then there is discovery involved. You need to talk to users, make a prototype and test it with a few teams to start with, run a beta program, roll it out to the rest of the company with a go-to-market strategy. In reality, I think it’s many of the same things you do as a product manager.”

For someone contemplating to go into the role of product operations manager, based on your experience, what is something you need to get really good at?

“First of all, you need to be really sharp in your communication, because regardless of what we do and how well it ends up working, you have to understand the context you operate in. Everyone we work with already has their hands full, so when we come to them with some initiative, it’s going to require some time from them and break their rhythm. It’s the absolute hardest part of our job to figure out how we can plant new initiatives successfully.”

I asked Matias if he could elaborate a bit on what makes it the hardest part of the job?

“Because it doesn’t really matter that we make all sorts of cool solutions if we can’t figure out how to put them in the hands of the users. It’s extremely important that people don’t have a bad onboarding experience, where they never experience the value of the solution. So it’s a lot about figuring out when teams can take the time to absorb things that we are doing.”

Matias also emphasized that the role is not always about big projects and implementations:

“Sometimes it’s about if you can just help a team stay on track in terms of understanding how they should use some tool, or how they can get hold of some data, or who to ask about something. As a product operations manager you have a big network of contacts and it’s essential to create great relationships where you become the team’s trusted partner.”

Matias goes on to add:

“So sometimes you get to have some interactions during the day where you feel a bit like a support agent in reality. And that’s fine. And then sometimes you have to pick up on it when you’ve been asked the same questions 10 times. It could be an opportunity to improve something in our documentation or how we surface it. So the role provides a super wide palette of work and you should probably be someone who enjoys working on many different things.”

Now we talked a lot about all the different things you can do and the wide range of tasks that can land at your desk. What is something you should be cautious about doing as a product operations manager?

“Yes, you have to avoid getting caught up in always trying to make things better tomorrow. Because while you might see how it needs to be done, and you might be able to execute quickly, you still have to understand the context you are operating in. All teams are fully engaged in what they need to do in their day to day and you need to make sure they have the capacity and energy to absorb it.”

Matias goes on to add:

“If we just launch new systems and tools and processes, then people can’t keep up with that change. And they are not supposed to spend all their energy absorbing what we bring. So you need to be quite careful sometimes with how optimistic you are and how much you can change. The job requires respect for the fact that their primary task is not to have to learn new tools and new processes. Their job is to build great products, and we must support them in that in the best possible way. Part of that is to be aware of their context often and to make sure we don’t overextend, but deliver things in a way that helps them.”

We talked a lot about your role, but the role of product operations manager is fairly new in Denmark and let alone Europe. What is your perception of the role in Denmark and the European context?

“That is actually a good question. I must admit, there is not too much out there and requires some searching. I’m not aware of any communities out there. It’s not like having the role of product manager on LinkedIn, where you probably get some outbound requests and maybe get invited to product events. So for me at least, it’s still very much a niche role in Denmark and Europe broadly speaking.”

Matias goes on to add:

“It’s actually interesting why it’s taken so long for product operations to get mainstream, because in all other areas it’s taken off quite quickly, like revenue operations, marketing operations etc. But for some reason, it’s moving slower in product. Maybe it’s because there are fewer product managers than engineers. And historically, the role of a product manager has been quite broad, and sometimes they take upon themselves a lot of the work in product operations.”

So how do you get better as a product operations manager?

“A long answer short, I think it’s important to really just learn from the challenges your teams are having. And then in addition, I follow some podcasts with product operation people attending. I’m very much into product enablement. So for me it’s not challenging that the community in Denmark is not big, I think there are a lot of resources you can use from different places. I personally like to follow John Cutler on the topic of product enablement, and another vital resource for me is svpg.com.”

As we approached the end of the interview, I asked Matias if he had any advice that he personally took to heart and wanted to share with us?

“Yes, the first thing that came to my mind was from my first manager. He often said to move ahead and be prepared to take the heat if it comes.. Or in other words, once in a while you have to just act and believe in the direction you have set out to do something. Reflecting whether something is a type 1 or type 2 decision usually helps me navigate applying this approach. If it’s a type 2 decision we can change direction later without too much drama so “go ahead and take the heat” is often the most effective approach. ”

Matias goes on to add:

“It doesn’t matter much if we hit it 100% right the first time. It’s actually better that we move forward and then iterate or change things later. I think that mentality is important because in big setups things can quickly feel too complex to do anything in. And sometimes you just have to move forward and believe that you will find a solution along the way.”