The Roman Pichler Hypothesis: Establishing an Effective Agile Product Management Organization Takes Time
In this episode of the Product Science Podcast, we cover agile and product transformations, what’s wrong with the focus on features, and saying no.
Holly Hester-Reilly
Roman Pichler is a leading product management expert specialized in product strategy, leadership, and agility. He has advised product leaders and he has taught product managers and product owners for more than 15 years. Roman has pioneered agile product management practices, and he has developed a range of models, methods, and tools to help organizations create successful products. Roman shares his knowledge through his training courses, his four books, his popular blog, podcast, and talks, and his product management tools, including his widely used Product Vision Board.
In this episode of the Product Science Podcast, we cover agile and product transformations, what’s wrong with the focus on features, and saying no.
Subscribe for the full episode on Apple, Google Play, Spotify, Stitcher, YouTube and more. Love what you hear? Leave us a review, it means a lot.
Resource Links
Questions we explore in this episode
What are some of the common challenges Roman sees in organizations trying to do agile and product management transformations?
- It’s a long and difficult process that sometimes takes several attempts.
- Many product managers and product functions lack the empowerment they need.
- Many product managers lack the skils and support they need to be great at their job.
- Organizations focus on the wrong things, like tool selection, instead of training PMs in the core skills they need to succeed.
What are some of the bad practices that Roman has encountered in his practice?
- Too much focus on grooming the backlog and curating perfect user stories with not enough vision and strategy work.
- Sometimes people aren’t clear on what part of the product suite they manage or even how to define what a product is.
- People focus too much on features, even going so far as to create a feature strategy and of course, feature roadmaps.
How does Roman recommend that product managers say no to feature requests that they can’t commit to?
- Remember that if we say yes to every idea, we may build a Frankenstien product that doesn’t do a good job for anybody.
- Be attentive and show appreciation for the individual showing initiative and making a request.
- Explain the reasons why their idea won’t be helpful or doesn’t align with the strategy.
- Develop your vision and strategy in collaboration with key stakeholders so that they buy-in.
Quotes from Roman Pichler in this episode
Establishing an effective product management organization takes time. It takes commitment. It takes commitment from the organization, from a senior executive management, and it also takes, in a way, commitment from the people then that work in the organization to show some perseverance, show some patience, and also to be willing to develop and learn and grow.
I've seen companies who create strategies for features. To me, that doesn't make any sense to have a feature strategy and a feature roadmap, even if it's a bigger product. I don't think that's effective to do. You end up with lots of plans, lots of bureaucracy, lots of strategies and roadmaps that have to be synchronized. It's like, I wouldn't do that. I'd really always focus on the product.
It comes with the job of being a product manager, product owner, and taking charge of strategic decisions or generally product decisions. Part of that is saying no, and that can be difficult. It can be difficult when the stakeholder is powerful, is a senior stakeholder, influential person. It can be difficult if we don't want to disappoint the person, maybe because we have a good connection with the stakeholder and like the person, and we'd like to be helpful. But if we say yes to every idea, then we're likely to end up with a product that doesn't help anybody and doesn't really do a good job for anybody.
The Product Science Podcast Season 5 is brought to you by Productboard
Check out their eBook: 10 Dysfunctions of Product Management
If your product team is struggling, it could be one of the 10 dysfunctions of product management. Learn more about each dysfunction and how a product management system can help you address and avoid them.
Transcription
Holly Hester-Reilly:
Hi, and welcome to the Product Science Podcast, where we're helping startup founders and product leaders build high growth products, teams and companies through real conversations with people who have tried it and aren't afraid to share lessons learned from their failures along the way. I'm your host, Holly Hester-Reilly, founder and CEO of H2R Product Science.This week on the Product Science podcast, I'm excited to have a conversation with Roman Pichler. Roman is a leading product management expert, specialized in product strategy, leadership and agility. He has advised product leaders and he has taught product managers and product owners for more than 15 years. Roman has pioneered agile product management practices, and he has developed a range of models, methods and tools to help organizations create successful products. Roman shares his knowledge through his training courses, his four books, his popular blog, podcast and talks, and his product management tools, including his widely-used product vision board. Welcome, Roman.
Roman Pichler:
Thank you. Nice to be on the show, Holly.
Holly Hester-Reilly:
Yeah, I'm so excited to have you. So I'm going to start with something that I don't know if I've told you yet, which is your book, Agile Product Management with Scrum was one of the earliest product management books that I read.
Roman Pichler:
Oh, wow.
Holly Hester-Reilly:
Yeah. So I still remember back in 2010 or so, and I had a Safari Bookshelf subscription and was reading all the agile and product management books and software development books that I could find, because I was just a few years into working in tech. And I came across yours and it was one of the ones that influenced me to say, "Hey, I think product is a good place to be."
Roman Pichler:
Oh, cool. Well, that's great. That's really nice to hear. Thank you for sharing.
Holly Hester-Reilly:
Yeah, absolutely. I know how great it is when you hear that you've impacted somebody with your work. That's one of the best things. So I'd love to hear more about, let's go back to that far. How did you come to write that book? What led up to that?
Roman Pichler:
Yeah, how did I end up writing this book? For me, product management's been a strong interest, a passion ever since I first started working with a product manager on a healthcare new product development effort back, I think it was 2001. And I was called in as part of a group in order to help sort out this development effort. It wasn't going too well. And originally, our job was to help with the technologies, but we quickly figured that the way they tried to develop this new healthcare product wasn't really very effective. So we thought, "Hey, why not try to use some agile practices?" And so that was the first time that ended up working with a product manager and trying to explain, "This is what I believe agile is. This is how it might be able to help us."And this is how it might help us avoid creating hundreds and hundreds of use cases, and then just pushing them over to development and overloading them completely and going into hope and pray mode, hoping that they'll deliver something after, what, two years or so? And then I ended up working with more product people. I was working at Siemens, I should say, back then, at a central technology function. Which was really nice for me, very interesting because I had access to different business groups, and Siemens was a little bit more diverse a company than it is today. Ended up working with healthcare, but also ended up with Telco. Back then it was still part of the company, still part of the business.And ended up working with more product people around agile practices and helping product managers understand what's this brave new agile world, how can we leverage it? How can we use agile practices? How can we work with development teams? And that really gave rise to the book Agile Product Management with Scrum. When I now look at it, I still think there are some useful pieces of advice in there. But when I look at it now and when I look back, I think, wow, it's amazing how far we've come as a profession, not only in the agile space, but particularly in the product management space. And I think I'd write that book probably it'd be different today if I wrote it again.
Holly Hester-Reilly:
Yeah, absolutely. Everything evolves, and I think most authors that I talk to tell me things like that. They're like, "Oh, when I look back on it now, I'm embarrassed about what I wrote back then." Ideas evolve just like software does.
Roman Pichler:
That's right. That's right.
Holly Hester-Reilly:
One of the things that's wild to me about hearing you talk about that is that some of what you just said, I feel like you could absolutely still say today. You can still go into a company and be like, "Let me teach you how agile can help you." And how wild is it that it's been 20 years and there are still companies all over the world that need this?
Roman Pichler:
Absolutely, yeah. And I guess we can say the same thing about product management. Loads of companies have started to, at least by name, embrace agile and create some sort of product management organization. But agile practices aren't always employed effectively, and product management organizations don't always work as well as they maybe could and should. The people aren't fully empowered, people aren't maybe as knowledgeable, as qualified as they could be. Don't have the time to really dedicate themselves a hundred percent to playing the role. And the list goes on and on.And I think it shows agile practices, but also establishing an effective product management function are major organizational challenges that aren't easy to implement. You can't just say, that's at least my experience, "We're going agile," and you're done in a few weeks or a few months time, it's really a long process. And some companies don't get it right. Some companies have to attempt more than once to go through a successful agile transformation. And I think to a certain extent, the same thing is true for product management.I've certainly seen quite a few companies where product management was introduced, but the product management maturity was really low. And so then yes, you have a function. People can't really do what they maybe should do, maybe because they don't know or because the organizational environment is lacking, it's not quite there. They don't have the support, they don't have the authority, they don't have the right interactions with the right people. And they're being told by the stakeholders what to put on their product backlogs and roadmaps.
Holly Hester-Reilly:
Yeah. So do you have any specific stories that you're able to share?
Roman Pichler:
Yeah, I think I've got a few stories. One story that comes to mind is I was working with a large American publisher, but their organization here in the United Kingdom a few years back. And they had just introduced a product management organization, and they asked me, can I help them with product strategy and roadmapping practices. And so it was really interesting, but at the same time, it was a little bit sad to see that yes, they had a product management group, yes, they had a head of product. But still their project managers were super influential, their engineering group was really running the show, and then they had a UX group that also told the product people what to do. And they just really lacked the empowerment, but they also lacked, I think I mentioned it earlier, they lacked the skills, they lacked the knowledge to really take full ownership of their products. And it wasn't a very effective organization.
Holly Hester-Reilly:
What did you help them with? How did you help them change?
Roman Pichler:
I did a piece for them around strategy and roadmapping, and I hope that was a little bit useful. They came back then to me and said, "Oh, we need some more help. We now subscribe to this roadmapping tool. Can you help us with that?" So that was the solution. The solution is, oh, we've got some issues that we can't solve easily. Now let's choose a tool. I don't know, fortunately or unfortunately, that was the end of the interaction I had with this specific organization. But I think it goes to show that, as I said earlier, at least that's my takeaway, that establishing an effective product management organization takes time. It takes commitment. It takes commitment from the organization, from a senior executive management, and it also takes, in a way, commitment from the people then that work in the organization to show some perseverance, show some patience, and also to be willing to develop and learn and grow.
Holly Hester-Reilly:
Yeah, it does. And that's super top of mind for me right now because I recently went through a training workshop where we were learning about transformations that have worked. And perseverance is one of the words that just really resonated. It's a lot of perseverance. Do you have any stories of times where you've helped somebody make that change?
Roman Pichler:
I used to be more involved in transformations, particularly around agile practices. But maybe it's because I wasn't very successful in helping organizations, guiding organizations through it.
Holly Hester-Reilly:
It's very hard.
Roman Pichler:
I now tend to focus more helping companies with specific product management practices or areas like, for instance, strategy and roadmapping, or roles and responsibilities, and appropriate skills and career paths, and learning and development programs that are associated with those roles. I find that's often more tangible. It's more tangible, but also it's more focused and it's clearer for the client, and it gives the clients some more reachable benefits. And transformations, I find, require long-term engagement, require real dedication from everyone involved. And I'm not always able to give that time to client projects.
Holly Hester-Reilly:
Yeah, I can understand that for sure. How long ago did you start out on your own as opposed to working inside a company?
Roman Pichler:
Yeah, so I started out in 2006, and that was in a way, sort of more coincidence. The last permanent job I held, which was an engineering manager's role, didn't really work out as I'd imagined it. And I didn't really enjoy the work that much anymore. And I was looking for an alternative, but I couldn't really find a job that I really fancied. And so I talked to a few people, and people said to me, "Why don't you try and go solo?" And I said, "Really? You sure that would work out?" And they said, "Yeah, give it a go." My wife was pregnant with our second child, our daughter, at the time.So she wasn't initially overly enthusiastic, nor were my parents and my parents-in-law. My father-in-law had this idea that I'd come knocking at his door anytime soon and ask him to be put up, and then probably would've put me in his shed or something. No, he's a great guy. I've got a great relationship with him. But in the end, we decided, okay, let's give it a go. And it was more initially intended as an intermediate step and then turned into something that I really enjoyed and that's become a permanent job for me.
Holly Hester-Reilly:
That really resonates with me because I think my own father thought that was going to happen when I started doing that. I would tell him about my successes and he'd be like, "Yeah, when are you going to get a job?"
Roman Pichler:
I had this for years that my father-in-law used to say, "Look, how's business going? You're still keeping busy?"
Holly Hester-Reilly:
Yep.
Roman Pichler:
And it's, "Yeah, Colin. Yeah, everything's going fine. Thank you." He stopped a few years back, so everything's fine now.
Holly Hester-Reilly:
Oh, that's good, that's good. 15 years into it, he finally stopped.
Roman Pichler:
That's it. That's it.
Holly Hester-Reilly:
So, tell us some stories from before you started that, stories about some things that you got done inside a company before you struck out on your own.
Roman Pichler:
One of the things that I did is help organizations apply agile practices, particularly during my time at Siemens. And working with development organizations, working with product management groups showed me how important it is to pay attention to the details. And in an agile space, make sure that you've got a product backlog, that the meaningful items in the product backlog, and maybe if it's end user-facing product, that you write effective user stories and that you prioritize your product backlog and you keep it updated and all those good things. But it's only of little value if you're not clear on the big picture, if you don't really know where you're going, if you don't really know why you're building the product in the first place, or why you're progressing it, why you're evolving it, and why people would want to use it, what value it creates for the business and who those people are anyway.And for commercial revenue generating product, what makes the product stand out? What sets it apart from competing products, from alternative offerings? So for me, that was a very big learning, and that's influenced my work, in a way, my career, quite significantly. So I really believe that we have to pay attention to the details as product people, but at the same time, we must not lose sight of the big picture. We have to have something like an overarching, what I would call vision and strategy. And I think maybe something like a roadmap that makes it a little bit more tangible, in order to create the context then to make the right tactical or execution or development or delivery-related decisions, whichever term you prefer.
Holly Hester-Reilly:
Yeah. So tell me more about how you define a vision and strategy in product.
Roman Pichler:
Yeah, sure. So vision and strategy, I think, like many terms in product management, mean different things to different people. So for me, vision describes the overarching purpose that a product has, the intention behind the product, the positive change it should bring about. And I like to use a very brief, ideally somewhat inspiring, motivating vision statement. An example I like to use is healthy eating for a product that helps people become more aware of maybe what they eat and how much they eat.And it could then create the benefit of, say, losing weight or maybe reducing the risk of developing type 2 diabetes. But the vision should be independent of the actual solution, the actual product idea, in order to ensure that it lasts. So it's this big inspiring goal, and I tend to say it should stay stable for at least five to 10 years, and only expect small, if any, adjustments to the vision during that timeframe.And then the strategy for me describes the path that we've chosen in order to attain the vision, and ultimately our way to make the product successful or keep it successful. And I find it helpful to capture four key elements in a strategy: the target markets, the target group, the market or market segments that we'd like to address, so the users and customers who are the beneficiaries of the product, the reason why people would want to use the product, so the specific problem it should solve or the benefit it should create, the need that it should address, the standout features, those elements, those aspects, those qualities of the product that make it stand out, and then the business goals that the product should help meet.So for me, those are key elements that I would capture in a product strategy. And for me, vision and a strategy, really, they form the foundation then to make more detailed and execution-related decisions. I don't think anybody can really write a user story without resorting to speculation if it's not clear who the users are in the first place and why they would want to use the product.
Holly Hester-Reilly:
And how often do you see teams that don't have that clarity?
Roman Pichler:
Unfortunately, I see those teams fairly regularly. it's not uncommon to me to work with product people and development teams and then asking, "So, who are the users and who are the customers?" And there's no shared answer, there's no clarity. Or why do people use the product in the first place? And again, there's at least a certain element of confusion. Sometimes it's even worse, and people aren't clear what they're managing, what they're owning. So I was recently working with an insurance company and I ran a strategy workshop with them, and it was awful.
Holly Hester-Reilly:
Oh, no.
Roman Pichler:
It was really awful. It was an awful engagement. And so I spoke to the head of product afterwards and said, "Wow, that was awful. I've never experienced anything like that." And we talked a little bit more, and it turned out that the majority of the people who attended the workshop didn't own any products. They didn't manage any products, but they managed workflows, parts of the value stream. And so they were really struggling with some of the concepts and some of the techniques and tools that I presented and asked them to apply. And there was a real confusion in this organization around what is a product, and how do you define a product? And I'm mentioning this because if that's unclear, then it'll be very hard, as the example shows, to come up with a meaningful vision and an effective product strategy and roadmap. So I see companies sometimes jump to conclusions and think, yeah, that must be a product.But when you look at it, and maybe I should say, what is a product for me, a product is a value creating vehicle. It's something that exists to create value for a group of people, users, possibly customers and the business. And sometimes organizations say, "Oh, here's a piece of software. It must be a product." It may or may not be a product, but if it does create value for those two parties, users, possibly customers, and the business, and I can clearly call out the value, I can clearly describe that value, then yes, it is a product. But otherwise it's a piece of software. It might be part of a product, it might be a component, it might represent a feature.
Holly Hester-Reilly:
So it sounds like maybe one of the things that team was struggling with was the team topology or the way that they divided up ownership. Did they have a fairly complex software system that was involved?
Roman Pichler:
They had a fairly complex organization. I think that was the issue. And they had a large, well-known consulting company that helped them with the agile transformation that advised them to set up their product roles in a very interesting, and I would ultimately say, not very effective way, for whatever reason. And so yeah, they just had people, as I said, managing, owning, parts of value streams.And for me there's a real difference between being a value stream manager or managing a workflow and being a product manager or being a product owner in an agile scrum-based context. For me, a product manager, a product owner, always manages, owns, has responsibility for, looks after a product. And so I have to clearly be able to call out what that product is, and I have to be clearly articulate the value that it creates, again, for the users, possibly customers, and for the business.
Holly Hester-Reilly:
For those of us who've been doing it for a long time, it sounds kind of obvious. And it's always sort of interesting to hear stories of when you go into companies where those things aren't clear. I guess I'm curious to hear a little more about what kinds of companies you encounter that at. Because I've seen some trends in my time and I'm curious what trends you see.
Roman Pichler:
So for me, unfortunately, it's not an uncommon experience that I work with a client, but also that I teach people and I notice there's a confusion around what a product is, and there's a lack of understanding. There's a lack of shared understanding and definition, certainly when it comes to digital products, certainly when it comes to software products. And for me, as trivial as it might seem, it is a fundamental issue, because if there's confusion around what a product is, then again, often the consequence or one of the consequences is that roles aren't correctly applied.But also I've seen companies who create strategies for features. To me, that doesn't make any sense to have a feature strategy and a feature roadmap, even if it's a bigger product. I don't think that's effective to do. You end up with lots of plans, lots of bureaucracy, lots of strategies and roadmaps that have to be synchronized. It's like, I wouldn't do that. I'd really always focus on the product. But again, that just means creating some clarity and some agreement within the organization how a product is defined.
Holly Hester-Reilly:
There is definitely a tendency across organizations to focus on features and not necessarily be able to step back to the bigger problem those features are solving and how that's going to create value for everybody.
Roman Pichler:
Yeah, that's right. And I think maybe one of the explanations is that product management and working in product I do think requires attention to the details. It's hard to offer a successful product if you don't do that. But at the same time, if we get drawn too much into the details, we can get lost and we no longer see the wood for the trees. And this is, again, where I think the vision and the strategy are so important, that we have the big picture and we can zoom out again and ask those fundamental questions or reflect on those fundamental decisions that we've made around target group, around value proposition business goals.
Holly Hester-Reilly:
Yeah, absolutely. I know that you have a product vision canvas. Is that basically what you were describing with the four areas?
Roman Pichler:
Yeah. So my product vision board really was my attempt, and I think I created that 10 years ago, a good 10 years ago, it was my attempt to help teams describe the vision and strategy of their products in a simple yet effective way. Did some research and looked at how do other people capture their visions and their strategies, what are their thoughts? And I really tried to follow the agile motto of "Do the simplest thing that could possibly work."And it's come out of my client work, it's come out of my teaching work, but it's also come out of my own work, running my own business and looking after products and services within my business. And the idea is just to offer a structure so people can ask the right questions and jot down some ideas and then use that to collaborate, to communicate, but also then to validate those ideas, particularly if it's for a brand new product or if it's for making bigger changes to an existing product.
Holly Hester-Reilly:
Yes. What other tools have you created along the way?
Roman Pichler:
Related is my product roadmap template, which I've called the GO product roadmap, and go stands for goal oriented. And the idea is to move away from feature-based roadmaps. As I'm sure many listeners will know, traditionally, roadmaps are a list of features that is mapped onto a timeline, very feature heavy. And move away from that feature focus, and in the worst case, being more concerned with creating ever more functionality rather than checking if what we're doing really creates value, in focusing back on the value, focusing on the goals or outcomes. So for me, goal-oriented roadmaps and outcome-based roadmaps are the same. I chose the term goal-oriented roadmaps because it's been a standard roadmapping approach for quite a few years. And fortunately, I think outcome-based, goal-oriented roadmapping approaches have gained more traction in recent years.And so for me, it's natural when I have a strategy that ultimately focuses on outcomes, so it focuses on the problem to be solved or the main benefit to be offered or the primary need to be addressed, and then the business goals. So those are outcomes, to then derive more specific goals or more specific tangible outcomes from those higher level strategic ones. And that's how I essentially connect a product roadmap to a product strategy and break them then down into measurable specific goals that can be attained within maybe two to three months. So that's a roadmap format, or template, I should say. That's a roadmap template that created. And again, the idea was just to help me in my own work and help the teams that I work with, and use it in my training courses when I teach people. And say, this is a template you can use. It's not about the template. It's not about filling out a form, ticking some boxes. But it's a structure that can help you as a starting point.
Holly Hester-Reilly:
And have your clients found that useful?
Roman Pichler:
I think so. I think the product vision board has become quite a widely-used tool in the agile and product space. And I keep bumping into people that tell me that they've used it. And it's similar with the roadmap template. I know a number of organizations that use it and seem to find it quite helpful. But again, for me, it's not about using tool A, B, or C, or template X, Y or Z. It's really having a structure in place that allows me to think things through, and ideally do this in a collaborative fashion together with my colleagues, other product people if I look after a larger product, or key stakeholders and representatives from the development team or the development teams.Have a structure that facilitates the thinking, have a structure that facilitates that communication and collaboration. And any changes then to a strategy and to a roadmap that come out from, say, some validation work, some research work, in order to ensuring that this is really a need that is strong enough for a large enough group of people, in that we can really address this need and can do a good job. And so it's worthwhile for us to now go after this need. And similarly with a product roadmap, that may change because the development progress is faster or slower than anticipated or because of user feedback that we've received and so forth.
Holly Hester-Reilly:
So how does the roadmap version that you use, how does it support being able to iterate and change? Especially, I'm a big fan of being able to iterate based on user feedback.
Roman Pichler:
For me, the key is really to work with outcomes and goals, and focus first and foremost on outcomes and goals, and keep the product roadmap fairly high level. I've mentioned that for me, a good product goal or outcome on a product roadmap covers a timeframe of about two to three months. It's specific and it's ideally measurable. I also like to suggest to consider formulating metrics or choosing metrics criteria that help me determine if the goal has been met or not. So a goal might be, just to give you an example, acquire more users or acquire 10% of users within the same segment. And if that's the goal, then I have to ask myself, okay, how can I then validate that goal has been met? How soon after the corresponding software has been made available will I know if we've attracted enough users? And again, how do I measure that?How do I measure user acquisition? Is it signups? Is it licenses that we've sold? Is it something else? And then keeping the roadmap coarse-grained in the sense that there are no features, or if you add features that you use those features really to describe big capabilities. So huge things like if I think about the healthy eating example and maybe a goal might be to help users better understand some of their eating habits, maybe how healthy their breakfast habits are, and acquire an initial user base. So if that's the goal, then the feature might be something like a dashboard, a healthy eating dashboard, and another feature might be integration with smart scales and smartwatches. But I wouldn't go into any more details at this stage because I think then the danger is that we're solutionizing, that we're developing, again, a feature focus, in the worst case, creating a feature factory, and that we're taking away the opportunity to inspect and adapt and iterate and build the best possible products in the iterative development process in the sprint cycles.So yeah, if you add features to your roadmap, only use big coarse-grained features, only three to five per goal. And the most important thing is any feature that is on a roadmap must help meet a specific goal. Goals come first, features second. And that means if a stakeholder comes and says, "I got this super important feature. We must add it to the roadmap now, and if we do this, we'll be stinking rich in no time. We'll have champagne breakfasts every morning in the office. It'll be glorious, it'll be wonderful." Then you have to find a goal that this feature supports. And if there's no such goal, either reject the request or suggestion, or you'd have to amend the roadmap. So those are the two choices, then. And introduce an appropriate goal or change an existing goal so that this feature can be accommodated
Holly Hester-Reilly:
Or perhaps you make a case that their feature doesn't actually achieve any useful goals and tell them they're wrong.
Roman Pichler:
Absolutely. Absolutely. Yeah, no, I think that's a very important thing that you say. It comes with the job of being a product manager, product owner, and taking charge of strategic decisions or generally product decisions. Part of that is saying no, and that can be difficult. It can be difficult when the stakeholder is powerful, is a senior stakeholder, influential person. It can be difficult if we don't want to disappoint the person, maybe because we have a good connection with the stakeholder and like the person, and we'd like to be helpful. But if we say yes to every idea, then we're likely to end up with a product that doesn't help anybody and doesn't really do a good job for anybody. But for me, the trick is to always remind myself that it is super important to listen attentively and not just think, "Oh, it's that stakeholder again," or "It's that person again."And then start immediately being biased and maybe start labeling the individual and discarding what the person has to say. But trying to stay open and trying to be appreciative of the individual showing initiative and making a suggestion, making a request, being present, listening attentively with an open mind. But at the same time, not being afraid to have a difficult conversation, not being afraid to make a tough decision and tell the person that for the following reasons, unfortunately, it's not helpful or possible to add that feature.
Holly Hester-Reilly:
Yeah. Do you have any stories about times when you've done that?
Roman Pichler:
I've been looking after my own products now for such a long time that I'm thinking, oh, when did I last do those for any of my products? And for me, it's not uncommon that people offer feedback on my books or even little templates. And I remember that a feedback I've received several times on another template that I've created that allows people to capture the key aspects of a persona, where people say to me, "oh yeah, nice try, Roman. Yeah, nice template, but you've missed something super important. You've got to offer an additional field on your template that allows me to describe the solution, the product." And I know some people like to do that on their personas, part of their persona descriptions.But personally, I disagree. I don't think it's right. I always try and be appreciative of somebody making the effort to reach out and offer feedback, and thank the person, but at the same time, explain that I don't think that's generally speaking helpful, and it's not really a practice that I would want to employ myself, and I would recommend. It's this, as I said, it's striking that balance between opening up to someone and being attentive and also being appreciative, but at the same time trying to be objective and assessing what is helpful, what isn't helpful in staying true to what we believe our products are about, and ultimately what the value proposition of our product is.
Holly Hester-Reilly:
Yeah. I like that example. I think it's all about giving them that positive reinforcement for sharing their ideas and being willing to come to you and talk about it, but also being clear about your own vision and strategy and whether the thing they're offering aligns with it.
Roman Pichler:
Yeah, absolutely. And for me, there are two key stakeholder management mistakes I see product people make. The first one is to try and please the stakeholders and then become a feature broker, be too accommodating. Again, the risk is to develop a product that doesn't really do a good job for anybody, develop a Frankenstein product, weak value proposition, looks horrible, broken user experience. And that's not desirable. And then the other mistake I've also seen product people make is to be a bit of a product dictator and just think of the stakeholders as these pesky people again, and basically give any stakeholder the vibes of "We don't need you. I don't need you. I call you if I really need input from you."And I don't think that's helpful either, because we obviously need the stakeholders to help provide the product, to support the product market and sell the product for commercial revenue generating product and so forth. And so I do think it's important to involve the stakeholders in the right way without allowing the stakeholders to take over, without allowing the stakeholders to dominate. But again, trying to be open-minded, trying to develop a genuine interest in what people have to say.
Holly Hester-Reilly:
And I would argue that the product managers who take that approach of, "Those pesky stakeholders asking me for things again. Can't I just do this without them?" are doing a disservice to the whole practice. Because I don't know about you, but I've certainly gone into companies and engineers and designers or salespeople, et cetera, other stakeholders, tell me basically their product manager was like a dictator, and they don't trust them at all. And I don't want product to get that reputation. That's not what it's about.
Roman Pichler:
That's right. Yeah. I mean, it's striking, again, a balance. It's that middle way between not being a feature broker and not being a product dictator, but having a clear vision of what's your product about. Having a strategy or developing a strategy, how you can attain that vision, how you can move your product forward. And ideally, doing it together with the key stakeholders and the development team members, or at least representatives from the development teams, to engage people at an early stage and to build consensus and agreement and also connections, do some relationship building early on.So yeah, I think it is a real challenge, I really do think so. It's the balancing our own ideas as product people, our own beliefs, our own, to a certain extent, biases, with listening out and being receptive to what other people think in order to build the best possible product. Plus the most important group we haven't even mentioned, the users and customers. So for me, with those different groups explains at least partly why being a product person is so exciting to me, but also so challenging. And why we sometimes are drawn too much maybe into the details or get lost in all the different tasks that we have to attend to, and then sometimes lose sight of the big picture.
Holly Hester-Reilly:
Yeah. So that makes me curious. What are your favorite ways of interacting with the customers?
Roman Pichler:
I may be very old school now, but maybe I should backtrack and say one of the biggest advancements, I think benefits we've received as a profession in the past 15 years is just the amount of user data that we can collect today and the ease at which we can do this. It's brilliant, it's great. At the same token, when I talk to product people and when I reflect to a certain extent on my own work, I sometimes think the pendulum's swung too much to everything, analytics, everything data, everything quantitative. Back in the day, 20 years ago, I think because we didn't have the tools available that we have available today, largely, there was much more focused on interacting with individual users. And things like ethnographic research was a big deal and were articles written and published about it. I remember reading an article in the Harvard Business Review, I don't know when that was, 2004, '05, '06-ish, about ethnographic research.And one of the examples I remember they cited was Lego researchers moving in was in their target markets back then in the US, Japan and Europe, and spending weeks with families observing how kids play in order then to make the right product decisions and design new products. And I think to a certain extent, we've lost track of that qualitative approach of everything that's around understanding how people really live and work and play, what their challenges are, and understanding the context that they're in and being able to really empathize with our users and customers. And so for me, I find it extremely valuable to interact with my users, my customers.So people that are likely to, say, use one of my tools, or buy one of my books or attend one of my training courses, and understand what they're struggling with so I can, again, learn from that and build the best possible offerings for them, in addition to collecting data, in addition to doing the number crunching. Analytics are great, and quantitative data is great, but I do think that ability and willingness to reach out is super important. Otherwise, there's the danger that we just push out new stuff, hope for the best, and see what sticks and reiterate and iterate. But we're treading water without getting anywhere, really.And it's easy for me to say this, but I also know that in large organizations, at least quite a few of the organizations that I've worked with, product people didn't always have the opportunity to easily reach out to users and customers. And sometimes the organizational layers between the person in charge of the product and the end user, there's management, their sales, their support, and other groups. And I'm never quite sure how this works, if the users are protected from us product people, or we, the product people, are protected from the users.But I think it's very [inaudible 00:32:27] to have salespeople that tell us about their experiences with customers and users support and other functions and of course, management. But I think that direct interaction and direct conversation and being able to observe people and talk to people, I think that's extremely valuable for us to make the right decisions.
Holly Hester-Reilly:
Yeah, absolutely. I'm such a huge believer in that. And I've seen the same trend that you're talking about where things have swung towards the direction of it's all about data and we're not doing enough about just user empathy and qualitative research, which has been frustrating to see, I think. It makes sense, there's so much data out there, and sometimes it maybe feels more comfortable to people to just spend their time looking at data.
Roman Pichler:
I think it's easier, and in some cases it may seem to be cheaper. But then we pay for it by making suboptimal or wrong product decisions and having to iterate more frequently. And I'm not arguing for any kind of big upfront research. I'm a firm believer in we should only do as much upfront research as possible and then build an initial, say, strategy as quickly as possible, and then do focused, targeted validation and acquire additional information.But a story I found really interesting and I like to share is in the book The Toyota Way by Jeffrey, and that book came out quite a few years back. He writes about what happened before Toyota was able to develop the first Lexus car. And they sent their chief engineer and a few other key people to California, apparently, if I remember, for six months to live the life. And rented a penthouse suite or whatever, or a posh apartment for them, made sure they had invites to all the important parties and met some important people and got to drive luxury cars, literally to walk in the shoes of their potential customers.And apparently that helped them build a first luxury car that I think, from what I know, was quite a big success. And we're talking about Toyota, who invented lean management. And lean management is all about, the terms says, it's all about efficiency. It's all about being lean. Not saying we have to go to California now for six months, which is a shame, particularly for those of us who live in Europe, other parts of the world. Wow, six months in California doesn't sound too bad. That'd be nice. But I mean, spending a few days talking to potential customers or to existing users, maybe on Zoom or Microsoft Teams or whatever it might be. Sometimes having online sessions I find can be sufficient. I think that can be super helpful, and certainly for me that's desirable.
Holly Hester-Reilly:
Yeah, absolutely. And I think there are situations where doing that in-person contextual work really makes a difference as well. Certainly learning about a car experience, I could see that in-person really mattering. But there's lots of cases that, especially for those of us building software, where what really matters is a screen share. And doing that over Zoom or Microsoft Teams is fine.
Roman Pichler:
Yeah, I really think so. And for me, it all comes down to really developing this intimate understanding of the user needs and being able to empathize with people. Really think that helps us make the right product decisions. It really informs effective product decision making. Without it, if we just have the data of half guessing.
Holly Hester-Reilly:
Yeah, absolutely. I like to ask people towards the end about what advice they have for people following in their shoes or facing similar challenges to what they're facing. And I'm curious to hear what you have to say for people who are interested in going through... You were doing enterprise product management before writing your own books and whatnot?
Roman Pichler:
Yeah, good question. I've never held a job role that was called product manager, but I've been doing product management in various roles now for close to 20 years. And so I'm happy to share advice for people who want to grow and develop as product professionals, or people who want to do some product coaching and some training.
Holly Hester-Reilly:
Yeah. I think what would be really interesting that I've certainly been talking to people about lately is people who are in related roles where product manager isn't their title. And they're drawn to the craft of product management or they're feeling pressure that maybe they should know about this product management thing. How did you come to that realization, and what do you think people should do when they're in that position?
Roman Pichler:
Yeah. No, that's a great question. For me, it was a combination of two things. One is having the good fortune to work with product people and in that way experience product management firsthand and see how people, not only one person, I was lucky enough to work with different product people over the course of all five years, and then see how they do their craft, how they do their jobs. So that was one of it. So you could say that was a part of, I guess, some form of apprenticeship nearly. Even though I was never formerly an apprentice.And then the other thing that really helped me is just to read about product management, and read as much as I could back in the day. I still like reading. I guess that's the way I was conditioned. I'm showing my age now. But yeah, even if it's not reading, if it's listening to podcasts or watching videos, that helps you consolidate your understanding about product management, but also maybe challenge some of your views and beliefs, and helps you deepen your knowledge, I think, is likely to be very valuable.And sometimes people say to me, "oh, how do I get into product management?" or "How do I make the next move, and how can I land this new job?" And then I tend to say, "You want to go from A to B." So it's good to be aware of what A is and to roughly understand what is your product management knowledge right now. Can you apply it, so what are your skills? How wide and deep is your expertise currently? And then think about the job role that you'd like to go for and what's the expertise, or what are the knowledge that's required in order to succeed in that big job? And once you know the gap, you can then figure out how do I close it? Do I close it, maybe, by trying to become a junior product person, if I'm new to the profession, and become an apprentice essentially to senior experienced product people, would that be something?Or can I maybe do some self-learning? Or maybe there is something, an app that I take interest in. Or maybe I have a blog or maybe I have a YouTube channel and maybe I can do a better job at managing that app or that YouTube channel or that blog as a product. And try out some of the knowledge that I'm about to acquire or in the process of acquiring in order to deepen my understanding and develop the appropriate skills. That's what I would suggest. I generally find it helpful to break product management knowledge and skills into three areas, leadership, strategy and tactics. And leadership is around everything to do with people, from goal setting and working with a vision and being a visionary product leader, to things like collaborative decision making and negotiating. But also time management and some self-leadership that I think is really valuable for product people.Strategy's around things like the product lifecycle model and knowing about some research techniques. Knowing about strategy and roadmapping and business modeling and financial forecasting, those things. And then tactics' about being able to work with a development team and maybe having at least some basic knowledge about the relevant technologies or some interest in technology. Knowing about things like personas, maybe, and product backlog practices, like how to prioritize a backlog and how to connect it to a roadmap, for instance. And how to update it and how to maybe test ideas for individual pieces of functionality or features or feature enhancements. But that can be helpful to work with a model like that in order to assess your skills and find out where are your strengths and weaknesses, and how wide is your knowledge and skill space and how deep is it? But yeah, where are you right now? Where do you want to go? And how do you get from A to B? As simple as that.
Holly Hester-Reilly:
Yeah, absolutely. Thank you so much for your time today. Where can people find you if they want to learn more?
Roman Pichler:
If you'd like to find out more about me, head over to romanpichler.com. And you'll find a blog, you'll find my books there, you'll find all the other things that I offer. And again, if anybody's got any questions, there's email information, social media information, there's a contact form. Please do get in touch.
Holly Hester-Reilly:
Awesome. Thank you so much. It's been a pleasure.
Roman Pichler:
Likewise. Thanks for having me.
Holly Hester-Reilly:
The Product Science Podcast is brought to you by H2R Product Science. We teach startup founders and product leaders how to use the product science method to discover the strongest product opportunities and lay the foundations for high growth products, teams and businesses. Learn more at H2Rproductscience.com. Enjoying this episode? Don't forget to subscribe so you don't miss next week's episode. I also encourage you to visit us at productsciencepodcast.com to sign up for more information and resources from me and our guests. If you liked the show, a rating and review would be greatly appreciated. Thank you.
