How A Healthy Product Strategy Keeps Orgs & PMs Alive (with Roman Pichler)

Read The Transcript:

We’re trying out transcribing our podcasts using a software program. Please forgive any typos as the bot isn’t correct 100% of the time.

Hannah Clark: Every organization's success relies on its ability to strategize. And yet, not everyone has the same interpretation of what a strategy is, or for that matter, what makes a good one. This is especially apparent in the digital product world, where the average organization has several layers of strategies that interconnect and evolve together. So when we say 'product strategy', what are we really talking about and how do we use it to drive the outcomes we want? 

My guest today is author and product management expert Roman Pichler, whose book Strategize: Product Strategy and Product Roadmap Practices for the Digital Age, is, as you'd imagine, all about the nuances of product strategy. In the conversation you're about to hear, Roman breaks down the strategy stack, how to nurture strategies to keep them fresh as time goes on, and how to influence those strategies, whether you're working within an empowered product team or something closer to a feature factory. Let's jump in. 

Welcome back to The Product Manager Podcast.

Roman, thank you so much for joining us today. 

Roman Pichler: It's my pleasure, Hannah. Thanks for having me. 

Hannah Clark: So can you tell us a little bit about your background and how you got to where you are today? 

Roman Pichler: Yeah, sure. So I think like, quite a few people I sort of fell into product management. So I was part of a team called in to help with a new product development efforts and originally working on the technical side and then ending up working with the lead product manager, learning a lot in the process. The product wasn't very successful, unfortunately, but I still benefited from doing the work and it certainly taught me an important lesson that there's no point in worrying too much about features and functionality and product details and ranking user stories if the overarching strategy, the approach that we want to choose in order to make our product successful, if that isn't clear. 

That was a key takeaway, a key learning for me, and it was also really a starting point for me that I wanted to learn more about the profession, about product management. That was a while back though, that was I think in 2001.

Hannah Clark: I'm glad that you mentioned product strategy because that'll be the focus for today, and more specifically the elements of product strategy that many organizations struggle with. 

So to kick us off, what exactly do we mean by product strategy and what are some of the ways that we misinterpret that term?

Roman Pichler: That's a really important question. So for me, the strategy for a product strategy describes the overall approach that we've chosen in order to make the product successful, or if the product's been in the market and it's already successful to keep it successful. So you can think of it as a framework or a set of guidelines that enable product teams and generally product people to make effective product decisions.

And an effective strategy facilitates product discovery and product delivery. And I like to capture four elements, describe four elements in a product strategy, the target group, the customers and users, the market segment that we're addressing, the reason why people would want to use or pay for the product.

So the specific need that it addresses or the problem it solves, the benefit it offers. The business goals, the desired business benefits. So the reason ultimately why a company should spend money on developing and providing the product. And then also that's particularly important for commercial revenue generating products, the standout features that set the product apart from competing offerings.

So those are four key elements that, as I said, I find helpful to describe in a product strategy. 

Hannah Clark: The types of strategy, would you say those are differentiated from the elements of strategy or are we kind of talking about the same thing? 

Roman Pichler: That's a very interesting question because the answer that you'll get will depend on who you ask.

Probably true for a lot of questions. So there's some people who believe that you can formulate a kind of universal strategy approach and apply it to any type of strategy. I don't think that's necessarily always beneficial and possible. So I think you should really look at what's entity, so to speak, the strategy describes or covers.

So a strategy for a business for an entire company, I think should be described in a somewhat different way compared to strategy for a portfolio or for a product. And again, if you want to describe a technology strategy, you probably would choose different elements in a different format, again.

I think what all those strategies have in common is that they're not a hard and fast plan. Like, that contains actionable detailed instructions, but as I said, their guardrails, their guidelines, their frameworks. And so the interesting thing, particularly with a product strategy is to be specific enough to offer direction to teams and set the expectations of stakeholders, but not be so detailed that the strategy doesn't open up enough or doesn't give product teams and development teams enough room to determine how to best implement it. 

Hannah Clark: I'd like to kind of dive in a little bit to this concept of the strategy stack and how these different types of strategies interconnect. So how can we develop those harmoniously to achieve our desired outcomes in broad strokes?

Roman Pichler: The strategy stack, at least the one we're talking about is a little framework that I've developed and it's based on my client work in a recurring experience that I have that, it's not always entirely clear in companies, what kind of strategies there are, what kind of strategies are needed.

They're not always clearly distinguished and not always clearly articulated. And so I do think it's important to call out the different strategies and make sure that appropriate strategies are in place in order to ultimately guide detailed decisions in the execution. And so the strategy stack contains of different layers or levels, so that there are five in total and seven elements.

The top layer, top level is the business strategy, sometimes also referred to as corporate strategy. So the question here is, what do we need to do in order to make or keep the business successful? And then underneath it sits the portfolio strategy and the portfolio strategy answers a similar question for a group of products.

Think about something like Microsoft Office or what now officially called Microsoft 365 with PowerPoint, Word and Excel as some of the core members. So it probably makes a lot of sense to consider formulating a strategy for Microsoft Office or Microsoft 365. And then underneath it sits the product strategy and product strategy would then describe the approach chosen to make say Word successful or keep Excel and PowerPoint successful.

And then I like to also add underneath the strategy, the product roadmap. I started talking earlier about the balancing act of making the product strategy sufficiently specific that it offers good enough guidance, but not so specific that it becomes a executable actionable plan, that's where the roadmap sits.

So the product roadmap should be an actionable product plan. It should add specific outcomes or state specific outcomes or specific goals that are in line with the strategy. It might also state some metrics, maybe some key capabilities and possibly some timeframes or even dates, even though that's debatable.

And it'll depend on if it's an external public product roadmap or an internal private product roadmap. And then the final element at the bottom is the product backlog, which isn't really a strategic element or strategic tool. But I like to add it for completeness sake to show you how ultimately the business strategy should drive detailed product decisions that are then captured in the product backlog.

So those are some of the keys, certainly from a product perspective key elements of the strategy stack. 

Hannah Clark: Yeah, I think that really demystifies some of the ways that these things kind of feed into each other. 

I would like to explore the concept of nurturing the strategy while we're talking a little bit about the life cycle of a strategy and some of the ways that those things are guided along. What does nurturing the strategy mean to you and what does that look like in practice? 

Roman Pichler: Yeah. Traditionally people tend to think about strategy and execution. They tend to think about thinking, enacting, right? We figure out our strategy, our big overarching plan, and then we implement it. We execute like hell.

And I think particularly for digital products, but generally in a world where it seems markets become less and less stable, technologies change at an ever faster rate. So I think that kind of notion, that concept in a way is outdated. And so what we really need to do is we need to look at the strategy work less as something that happens once in a blue moon every now and then, but more as an ongoing continued process or workflow or stream. 

So, I like to suggest establishing a continuous strategizing approach where a little bit of strategy work is done at least once a week by the person in charge of the product manager. Usually that only requires two to four hours and it means looking at the product performance, how the product is doing, how much value the product is creating, including looking at any user feedback, looking at the competition, if there are any changes and looking at the technology space again, if there are any changes.

And then having bigger collaborative strategy reviews with the product team members and key stakeholders at least once a quarter, where we look at bigger trends and see if there are bigger developments that we need to respond to. And the whole idea is to avoid being called out, but rather being proactive and seeing opportunities and threats at an early stage.

The strategy stays a helpful forward looking plan that pulls people into the future. And again, as I said, we're not being reactive. We're not fighting ourselves with our backs against the wall. We're being leapfrogged by a competitor who suddenly offers a killer feature or brand new product. And we're thinking like, Oh my God, how did that happen?

Or, competitor offers a new technology. And we're thinking like, yeah, generative AI. Yeah we've thought about that for a while, but no idea how to use any AI technology in our product. So yeah, to be proactive. And again, keep the strategy meaningful, keep it up to date in that sense, keep it adaptive or make it adaptive.

Hannah Clark: And I'm very glad that you brought up threats and some of those challenges, because I think that's something that I'd like to talk about a little bit more. 

So what are some of the common reasons that otherwise really strong product strategies tend to go off the rails during the execution phase?

Roman Pichler: A key reason for me is a misalignment or a gap between the people who articulate the strategy, develop the strategy and the people who are then meant to execute it implemented. So, what's not uncommon traditionally is that a senior manager, like a head of product or VP of product management, director of product management, depending on the organization, it depends on the organization, what the role is called.

So then a senior manager comes up with the product strategy or formulates the product strategy and then other people. Development teams, cross functional development teams, designers, UX designers, and of course, product managers are asked to implement the strategy. And for me, that's suboptimal because it wastes the expertise and creativity of product team members and development team members.

And, it can lead to a lack of clarity and a lack of support and buy in. So I'm a big fan of asking the people who know best about the product and manage the product on a daily basis and work with the product on a daily basis to put those people in charge of making strategic product decisions and enable them, empower them to do so.

For instance, by coaching and mentoring them by giving them the opportunity to attend a training course or in other ways that are helpful. And that also frees up the head of product from possibly becoming a bottleneck and getting overworked. And then the head of product has the opportunity to focus more on people management responsibilities, and maybe also take on the role of a portfolio manager, which is not uncommon in mid sized companies, particularly when the portfolio isn't too big and too complex.

Hannah Clark: On the topic of cross functional collaboration, I think this is something that is a little bit more nuanced. Every product team is so different and all the personalities in the room are always going to be very specific, but do you have any practical advice for improving cross functional collaboration? And especially for remote teams that really experienced some of those challenges, sort of a more amplified state.

Roman Pichler: For me, probably the most helpful technique is to involve a skilled coach or facilitator in the collaboration piece, particularly if you run online workshops, which is something I'm a big fan of.

So, when it comes to looking at the strategy and reviewing the strategy and possibly reworking or adapting the strategy, I think an online collaborative workshop, generally a collaborative workshop, and we're talking about online teams and online collaborative workshop is a great way to bring people together to connect people, to ensure that people hear each other's perspectives and ideas, each other's concerns, understand each other's underlying goals and needs. It's worthwhile spending time carefully preparing this workshop, but then again, having a skilled facilitator, dedicated facilitator, who maybe introduces ground rules.

It reminds people of those ground rules if that's necessary and guides the group, guides the team through collaborative decision making processes. Suggest something like a decision rule, like for making strategic decisions, we probably want to use something like unanimity or consent. So I find that for product people, it can be really hard to actively contribute to such a workshop and shape the strategic decisions, which they should, because, I'd expect the product manager, the person in charge of the product to be the expert on the product, generally speaking, 

but then having to facilitate at the same time, particularly if it's online or if the group maybe hasn't worked together that much and hasn't gelled that well yet. That's really challenging. So, yeah, get a dedicated coach or facilitator who helps you. 

Hannah Clark: I'd like to talk a little bit about empowered product teams. It's something that you mentioned a little earlier, and I think that this is a little bit of a sensitive issue for some. A lot of folks struggle with maybe a promise about an empowered product team that doesn't end up feeling as empowered as we'd like it to be.

In your view, what degree of empowerment sort of strikes that right balance of agency and team cohesiveness? 

Roman Pichler: I think empowerment's been sort of a challenge in product management ever since the profession manifested itself. Depending on who you ask in the 1930s or 1950s, and in, obviously, in the software space, product management is a little bit younger.

We started to see product managers in software companies like Microsoft Emerge in the 1980s. But you know, the minimum level of empowerment, I like to say, and I think I'm in agreement there with a lot of my colleagues that product teams need, is the authority to determine the features and user experience that a product offers.

But personally, for me, that's not enough because that assumes that then somebody else, like a head of product, as mentioned earlier, is in charge of the strategic product decisions. And as we've already briefly discussed, the risk then is that there is a disconnect, a chasm between strategy and possibly execution.

And so for me, the desired level of empowerment is that a product team together with the key stakeholders, and I like to then pull these key stakeholders into the product team and talk about an extended product team or product team plus collectively owns the strategic decisions with the product manager being empowered to have the final say if no agreement can be reached.

And so that gives the product team, as I said, sort of a holistic control or a complete control, you could say over the product, but also then the appropriate responsibility for maximizing the value that the product creates. So that's what I like to suggest. And as I said, the benefit is you tend to end up with better decisions.

You tend to have teams and individuals that are more empowered and more motivated because they feel more empowered where the strategy and strategic decisions are clearer, where they usually are supported better, enhanced, implemented more effectively and said it also has benefits for a head of product who can focus on other important responsibilities.

So that's what I like to suggest, but of course, that's not what necessarily happens in every company, as I've mentioned, empowerment generally is a big issue in product management and often, unfortunately, misunderstood. 

Hannah Clark: We had an episode recently on the topic of feature factories and kind of the situation that a lot of product teams find themselves in, sort of the inverse of an empowered product team.

In your view, is there anything that contributors can do to kind of push back against the feature factory mindset or what are the kind of prescribed ideas that you might have for teams that kind of find themselves in this sort of kind of vicious cycle? 

Roman Pichler: What you're describing very much resonates with some of the experiences that I have when I go and work with companies. I think to a certain extent, a feature based approach and feature based planning is the traditional way of anticipating and organizing work. And if you find yourself in a situation where stakeholders come to you and say like, Oh, we need this feature done.

And somebody else comes and says like, Oh, no, that feature. Then, I think the positive thing is that at least people are interested in the product and at least they want something from the product and want something from you. But of course the big danger is that, in the worst case. We create this Frankenstein product, which is just a loose collection of features that don't really fit together.

It's got a terrible value proposition and a horrible user experience. So as a first step, what I like to suggest is to try and get together with the important stakeholders, the key stakeholders and development team representatives and say, what is the outcome that we'd like to achieve in the next two to three months?

What's the goal or what's the objective we're working towards? So if you work with OKRs objectives and key results, you can use OKRs in order to set an objectives and say like, okay, what are the key results? What are the key features in order to meet this objective? Or, what's the outcome? What's the product goal that we're like that we're trying to achieve here?

And try and get as much buy-in as possible and come up with a product goal that makes sense, that moves your product forward in the right way. Progress is your product effectively, and then try and stick to that and really try and assess any feature requests or any ideas that come up in the context of that objective or outcome protocol and say, well, if it doesn't help us achieve this goal, we're not going to do it.

If it does help us, we'll look at it and see if maybe some of the other items that we thought we want to do, if they have to be dropped or if they have to be in some way or the other, weakened. So that's really the first step. The next step would then be to work with an outcome-based goal oriented roadmap, where, first and foremost, we agree on those outcomes, those goals, those objectives, for the next 6 to 12 months.

And that's really what, ultimately, product teams are being held accountable for, meeting those objectives and delivering those objectives. Not the features. Not the functionality. 

Hannah Clark: Yeah, I think that's a very helpful way to frame it. 

Just to end off with kind of a high note, at a high level, what steps would you recommend an organization take to audit and strengthen its existing product strategies?

Roman Pichler: First of all, making sure that the strategies are in place and by strategies are in place, I mean, strategies are clearly articulated, particularly for the important products. So I'd start with those products that generate revenue, the revenue generators. And then next I'd look at supporting end user facing products.

So, if you, for instance, so we're talking about a bank, a high street bank, then a revenue generating product might be a loan or a mortgage, but then the supporting end user facing product would be the mobile app that customers use in order to administer their loans or mortgages. That's the product category I'd look at next or the type of product I'd look at next.

And then, third, I'd look at internal supporting products like a software platform. And that's also a great opportunity to reflect on the portfolio and see if the portfolio really is well put together, if it's maybe too big, if it's maybe bloated, or if there's maybe something missing. So you systematically move from the outside to the inside, from the customer user to internal supporting products.

But if it is a product, if an asset, if ultimately, a piece of software for talking about digital products. If a piece of software is a product, then it's worthwhile articulating a strategy for it and it's worthwhile considering setting goals and maybe having something like an outcome based product roadmap for it.

And I know there's a certain overhead associated with it, but you know, the alternative then is to say like, well, maybe that product isn't valuable enough for us, or maybe, the entity isn't a product. Maybe it's a feature, maybe it's a component, maybe it's something else. 

Hannah Clark: Such a wonderful talk. I find you're so concise and it's so actionable the way that you speak.

Thank you so much for joining us, Roman. Where can people follow your work online? 

Roman Pichler: So the best place to go to is RomanPichler.com. And so you can find articles, videos, my podcast, books, tools, templates, frameworks, all sorts of stuff.

Hannah Clark: Fantastic. Well, thank you so much for your time. We'd love to have you on.

Roman Pichler: No, pleasure. It was great talking to you. Thank you. 

Hannah Clark: Thanks for listening in. For more great insights, how-to guides, and tool reviews, subscribe to our newsletter at theproductmanager.com/subscribe. You can hear more conversations like this by subscribing to The Product Manager, wherever you get your podcasts.