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 you 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.
It's my pleasure, Hannah.
Thanks for having me.
So can you tell us a little bit about your background and how you got to where you are today?
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 effort, 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.
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?
That's a really important question.
So for me, the strategy for a product or 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 -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.
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?
That's a very interesting question, because the answer that you'll get will depend on who you ask, probably through 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 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 a 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, they're guard rails, they're guidelines, they're 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.
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?
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, they're not always clearly articulated.
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 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 365.
And then underneath it sits the product strategy, and product strategy would then describe the approach chosen to make 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 an 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 so 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 key, certainly from a product perspective, key elements of the strategy stack.
Yeah, 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 lifecycle of 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?
Yeah, traditionally, people tend to think about strategy and execution.
They tend to think about thinking and acting, 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 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, the 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 they're 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, you know, competitor offers a new technology and we're thinking like, yeah, generative AI, yeah, we've formed that out there for a while, but no idea how to use any AI technology in our product.
So yeah, to be proactive and again, you know, keep the strategy meaningful, keep it up to date and in that sense, keep it adaptive or make it adaptive.
And I'm very glad that you brought up threats and some of those challenges, because I think that 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?
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, implement it.
So, you know, what's not uncommon traditionally is that a senior manager, like a head of product or VP of product management, director of product management, you know, depending on the organization, you know, 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, you know, 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 you know, 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.
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 experience some of those challenges, sort of a more amplified state?
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 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, a dedicated facilitator who maybe introduces ground rules and reminds people of those ground rules, if that's necessary, and guides the group, guides the team through collaborative decision -making
processes, suggests 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 cultural facilitator who helps you.
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 Empowered Product Teams 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?
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 obviously, in a 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 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 and hence implemented more effectively.
And as I 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.
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 a feature factory mindset or what are the kind of prescribed ideas that you might have for teams to kind of find themselves in this sort of kind of vicious cycle?
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 plan 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 objective and say, OK, 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 trying to achieve here?
And try and get as much buy -in as possible and come up with a protocol that makes sense, that moves your product forward in the right way, progresses 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 will 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 six 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.
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?
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're, for instance, say 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're systematically moved 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, if we're talking about a digital product, 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 the alternative then is to say, 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.
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?
So the best place to go to is romanpichla .com, and so you can find articles, videos, my podcast, books, tools, templates, frameworks, all sorts of stuff.
Fantastic. Well, thank you so much for your time.
We love to have you on.
My pleasure. It was great talking to you.
Thank you. Thanks for listening in.
For more great insights, how -to guides, and tool reviews, subscribe to our newsletter at theproductmanager .com slash subscribe.
You can hear more conversations like this by subscribing to The Product Manager, wherever you get your podcasts.
