Podcast: Play in new window | Download

Paul [00:00:01] Hello, everybody. We are really excited to be joined by Roman Pichler. He is a product management expert specialized in digital products. He has more than 15 years experience teaching product managers and product owners, advising product leaders and helping companies build successful product management organizations. Roman is the author of three books, soon to be four, including Strategize: Product Strategy and Product Roadmap Practices for the Digital Age and the Agile Product Management with Scrum. He writes a popular blog for product professionals, which I highly recommend, and he has been known to play the saxophone from time to time. Roman, what I am really excited to talk to you about is how you’ve brought humanity back to product leadership and I think a lot of people in this space are talking about emotional intelligence and active listening. What you’ve really done a great job at in the conversations that we’ve had together is just being a nice person, to put it plainly. It’s really struck me that not many people take those sort of soft skills, as they are called, and live them, walk the talk, so to speak, and put them into practice from day to day. So welcome. I’m really excited to pick your brain and get your ideas out to the world.

Roman [00:01:11] Thank you, Paul, and thanks for the kind introduction. Yeah lovely to be on the show.

Paul [00:01:16] Welcome.

Sean [00:01:16] Nice.

Paul [00:01:17] Go ahead, Sean. I think you’re chomping at the bit more than I am, so go for it.

Sean [00:01:21] I absolutely am. So in our space, you’ve been quite active and prolific blogger as well. I think over 160 articles last time I checked. I’ve been reading your stuff and we are privileged that you sent us the manuscript for your up-and-coming book, so we got a chance to read that. And I see it as a bit of a shift in your thinking in terms of where you’re headed and it feels like we’re really starting to, and I think you’re seeing this across this industry, we’re really starting to recognize the importance of the soft skills over just the hard skills. You need the hard skills, but the soft skills are what are really gonna drive product success. So I’d like to hear about that from you.

Roman [00:01:54] Yeah, no, that’s right. You’re absolutely right, Sean. So when I reflect back on my own personal journey in product management, I started out working with product people primarily in an Agile, scrum-based context, so things like understanding what a product backlog is and how you can leverage it and understanding how product people can benefit from sprints and software being built incrementally and, you know, early releases and testing things out and working well with development teams. That was something that I was very interested in. And then it dawned on me that you can write beautiful user stories and have an amazing product backlog, and if you’re not really sure who the users are and why they would want to use your product, then, you know, maybe all the effort that you’re investing is not quite so well spent. And so my interest in a way shifted to strategy. And to certain extent it coincided with me having founded my own business, my own company, and having to think not only about business strategy, but also about the strategy for the various assets that we were about to create or had created at this stage. And then again, while I was writing my last book, Strategize, it occurred to me that in order to make effective strategy decisions and go ahead and implement them, it’s not enough to have some tools in place and know the right techniques, it’s key to get the buy-in from the stakeholders and the development team members. So it’s important to build rapport, it’s important to be able to influence people, it’s important to be able to involve people. So that’s in a way how my thinking has evolved over the years. Maybe just to finish off this kind of thought, for a while now, in fact, for a number of years, I’ve been doing the same exercise in all of my product owner workshops. And so I ask people, you know, just imagine your boss comes to you and says, “you’ve been such a successful product owner, well done, I want you to be in charge now of hiring new product owners.” So, you know, take a few minutes, think about what are the most important qualities that the candidates should have. And by and large, the qualities that people list are soft skills, they’re all around things like, you know, being trustworthy and being empathic and being good at listening, not shying away from difficult conversations and those kind of things, you know, a lot of which I try and address in the new book. So I believe that as a product management community, we sort of know that the soft skills are right at the heart of our job. I mean, we have a highly networked job, right, but I don’t think it’s necessarily always reflected in the writing, the articles and books and also the training classes that are available to the community. That was a long answer.

Sean [00:04:24] No, no, it’s a good one, though. I always like to say when we run our workshops, I kick them off with a conversation about the business of software development and how complicated it is. If you think about it, you have a bunch of people holding onto these bags of money. They’re generally mysterious, like they call it a budget or an RFP in some cases, and they are trying to hire a bunch of really smart people that we call geeks or nerds to build a product for a bunch of people that none of us have ever met. Mm hmm. There’s a lot of people in that equation, right.

Roman [00:04:54] That is.

Sean [00:04:54] So if we don’t understand the mechanics of human motivation, right from the get go we’re in deep trouble.

Roman [00:04:59] You’re absolutely right. I sometimes think product management shouldn’t be called product management, it should be called people management. Even so, that term’s already been taken, but as you just said, they’re the users and customers and it’s understanding the needs of those individuals and getting to know them. And for me personally, that is a key part of a product manager’s job, I think we’ve got so many amazing and powerful analytics tools available these days, you know, thinking back over the last sort of 15, 20 years. But I think it can’t really replace the intimate knowledge that comes from meeting people face-to-face and observing them and talking to them and then equally building relationships with the stakeholders and the development team or development team members. So, yeah, there’s a lot of people in product management and I think it’s important to recognize that.

Paul [00:05:41] I want to jump in there and key in on one specific tool that you’ve talked about quite frequently in your upcoming book and of course, in your backlog of blogs over the years and it’s empathy. And I’m going to quote from the manuscript of Product Leadership, just for the sake of the conciseness of which you’ve put these two ideas together. You said, “there are two common barriers to empathy: first, we can be so caught up in our own thoughts and stories that our ability to be receptive to the needs of others is reduced. The same is true when we are tense, irritated or worried. Experiencing negative mental states makes it harder to relate to others. And then secondly, we might confuse projection with empathy…” I think this one is really interesting. “…The former means making assumptions about what the individual should feel according to preconceived ideas. For example, believing that someone who speaks loudly wants to dominate and take over the meaning.” That quote stopped me in my tracks when I read it, because I often do that about the users for whom I’m building products. I do it for the team members, making assumptions about, “oh, they’re having a bad day,” or, “they can handle it because they’re so happy,” or, you know, projecting what I think is going on without ever really asking. But the crux that you bring it home to is a term that’s not often used in technology or product management and that’s that the antidote for mis-applied empathy is servant leadership. And that is not an uncommon phrase, but it’s just one that’s not often applied in these types of frameworks of agile and scrum and backlogs and roadmaps and vision. Servant leadership is sort of, you know, on Sesame Street, it would be, “one of these things is not like the other.” It shouldn’t be, in my opinion, but how do we make it more part of the toolkit of the product manager? How do we start to build this into the skills that we’re nurturing in up-and-coming product leaders?

Roman [00:07:26] Yeah, great question. It’s really recognizing that, in a way, the human aspect, or the humanity, in our job is really a core part of it and not just a nice-to-have or something that sort of kind of happens. But, you know, that’s not really the important thing. What’s really important is getting the strategy right and getting the backlog right. Now strategy and backlog, again, are important, and the hard skills are important for us as product people to do a good job. But I feel that the people skills, the leadership skills, the soft skills are just as important. Paul, you mentioned making assumptions. I make a lot of assumptions. I think all of us make assumptions. I mean, we’re all conditioned, you know, we all have a history. You know, you before benefited from different backgrounds and educations, and, you know, we’ve soaked up a lot of ideas, in some cases, subconsciously over the years. So it’s natural to make assumptions. But I think what is helpful, certainly to me, is trying to bring some awareness from time to time to what is happening and to the assumptions that I am making and make an effort to empathize. Make an effort to reach out with interest, a warmhearted interest and an openness to other people, and and make time. You know, I think when we’re rushed and when we’re stressed and when we’re tense and when we’re so caught up in, you know, have to do this, have to do that, have to achieve this, you know, must attend to this meeting, must meet that goal. And if we’re in a driven state of mind, then as you said, it’s kind of difficult to be open and receptive and be empathic. So it does require in many cases, certainly for me, slowing things down and developing a little bit of awareness of what’s happening so I can then take an interest in others.

Paul [00:08:59] And to take that one step further, the concept that obviously built on is this inter-relationship of trust. Empathy is the fundamental skill that leads to trust. We talk a lot about trust in the relationships that we have with one another, with the users of our products. But a lot of times I feel like trust is rooted in what I’ve seen called the industrial feedback complex. Social networks are engineering our data to create echo chambers; we’re becoming more and more siloed as communities and societies. But I’m wondering, how can we talk about trust in a way that a product person might be able to build trust on her team and with the users of her products, not in a transactional way of, “I’m uploading a profile picture because I trust it’s gonna get where I’m going to go,” or, “I’m buying a product because I trust what the people are saying.” I feel like that’s the transactional level of trust, that’s table stakes at this point in the state of technology and what we expect of our apps and our products, but how do we start to bake this into our thinking as really a common core value?

Roman [00:10:00] I mean, for me, trust is a vital ingredient in any relationship. So in order to build trust, I think it’s helpful or essential to spend time with each other and get to know each other, find out about each other and be open to that. And again, make time for it and go in deep, prioritize it. You know, things like acting with integrity, you know, saying what we believe is true and then doing what we say, that builds trust. You know, if we don’t give people the information they need or if we portray things in such a way that it isn’t quite true, then, you know, that’s unlikely to increase the trust that people have in us. Having an open mind and being receptive to what the person has to say, no matter if we like the individual or not and no matter if we agree or not, we can still be open and accepting. It doesn’t mean that we approve in any way. And again, reaching out with empathy and having this kind of warm-hearted, kind approach, and that doesn’t mean that we gloss over issues. I mean, there’s some people out there and some people I’ve certainly worked with who had acquired very difficult behavior patterns, habits, and you know, were just very, very difficult in the way that they spoke and behaved. So not to gloss over it and just sugarcoat everything like, “oh yeah it’s wonderful, it’s wonderful, yeah don’t worry about it,” but taking an interest in why people act the way they do and why they say what they say, where they’re coming from, what their underlying motives and needs and interests and goals are. So I think those are important elements. And, you know, you can take this a little bit further and say, particularly in environments that agile processes want to encourage where there’s a lot of collaboration, that in a way assumes that a certain level of trust is there, because otherwise people won’t be open, people won’t share things, they won’t speak their mind, they won’t feel safe to truly contribute and interact in a meaningful way. At the same time, once there is an initial level of trust, it’ll increase the trust if the collaboration goes reasonably well. So, again, it’s something where I feel it’s it’s worthwhile to put some emphasis on and say, maybe reflect on how trustful is the relationship that I have in place, is the connection that I have in place with the key stakeholders and the development team members and is there anything that I can do? And are any of the points that I just mentioned, would they be helpful for me to deepen the trust and improve the relationship?

Sean [00:12:06] All right. So let’s go a little deeper on empathy, because I think it’s one of these words that gets a little bit abused in the market. You know, I’m not proclaiming to be an expert here, but I know there’s different types of empathy. There’s cognitive empathy, which is the recognition of how other people are feeling and the ability to empathize with them in order to, you used the term earlier Paul, emotional intelligence, and I think that they’re often equated, but they’re very different things, to influence others, to influence the behaviors of others towards a positive result. And the form of empathy, I think that you’re referring to Roman, is affective empathy, like understanding how people feel so that you can increase caring. It’s the combination of those two things that cause relationships to be formed. So understanding how people feel so that you can understand what they’re thinking and then also understand how they’re feeling in terms of caring to try to increase the caring that occurs in our teams. I mean, what’s your definition of empathy? When you use the word, what are you thinking?

Roman [00:13:03] You know, I quite like to keep things as simple as I can. And so for me, empathy is the capacity that we have to understand each other’s feelings and needs, perspectives, interests. So it’s for me, facilitated, as I’ve mentioned before, through a kind of warm-hearted, kind attitude towards the other human being. And again, it may be that the stakeholder, the individual, the development team member, you know, the sponsor, whoever the person might be, is somebody who we’ve experienced as difficult in the past, but still trying to cultivate this openness, receptiveness and, you know, a positive outlook. So the opposite of labeling somebody, the opposite of saying, you know, “she or he is a bad person, a mean, person,” or, “I hate him, I hate her.” Strong negative feelings may be present, and that’s okay, but I think we can still try to be interested in the perspective and the needs of the other person.

Sean [00:13:55] Yeah. In your book, you talked about the Behavioral Change Stairway Model, the one that the FBI uses. I think his name is Voss, I read his book a couple of years back, and the intent of that is to cause behavior change.

Roman [00:14:07] That’s right.

Sean [00:14:07] And the model that we tend to look at or use at ITX, when we think about this behavior change, because if you think about it, the intent of a product is to cause change to occur in a positive way. So this is the job of product owners, to figure out how are we going to cause this change to occur through this software product for the people that are using it. And then we also have to look at our team. That’s a collection of behaviors that results in a great product, right. So this behavior change thing is a really important concept and we use the self-determination theory. Are you familiar with that?

Roman [00:14:37] I’m not sure, to be honest.

Sean [00:14:38] Ed Deci and Richard Ryan… I think it’s largely, if you think of the Behavior Change Stairway Model; empathy, rapport, influence and then behavior change. It’s the science behind this influence piece and I’d like to understand what your thinking is in terms of influence, like how do you approach that or how you approached it in the past?

Roman [00:14:58] So one of the reasons that I like to use the Behavioral Change Stairway Model in a product management context is that it shows how we can exercise a positive influence on others without having any power over the other person. As product people, we usually don’t have any transactional power, what are commonly referred to as transactional powers. We’re not the boss. We can’t tell the stakeholders and development team members what to do. We can’t usually offer incentives. So, you know, you could say being authoritarian and to certain extent commanding and possibly even threatening people or offering incentives, that’s something that’s just not open to us. Personally, I don’t think that necessarily those are good leadership instruments, but I’ve certainly seen bosses exercise them. The question that then arises is, how can we then lead others? Leadership is only possible if we can influence people. I mean, you know, you find a common helpful definition of leadership, influencing people to reach shared goals, common goals. And what the Behavioral Change Stairway Model says is that we can only influence people once we’ve built a trustful connection, once we’ve established rapport, and in order to establish this trustful connection, empathy is a key element. I don’t think it’s the only one, but it’s a key element. And then he goes a step further and says, now, in order to empathize with people, make an effort to actively listen to people, to really pay close attention to what they say and don’t judge too quickly, try to cultivate an open mind. So it’s something that the FBI developed in order to deal with terrorists. And I don’t think the sort of threats and the challenges that we face in product management are quite as severe.

Sean [00:16:32] We hope not.

Roman [00:16:33] Yes, I would hope so. But still, the principle, I think, is the same. You know, dealing with people over whom we don’t have any kind of formal power. Again, we can’t tell people what to do. We’d like to encourage a positive change. And so empathy is not just for me something that is a nice word. It’s not just a nice idea, you know, it’s not something fluffy. For me, it’s something that is essential in order to do a good job, but also to have meaningful relationships and be content and reasonably happy in my life, including at work.

Sean [00:17:05] It’s a deep skill. It’s a really important skill. I totally agree with you.

Paul [00:17:09] Yeah. I’m going to take it down from 30,000 feet to possibly taxiing on the runway. This is a pretty nitty gritty question, but it’s one that I’ve been interested in getting your thoughts on because you’ve written about it. And it’s especially near and dear to my heart because I live this every day, what I’m about to talk about, the relationship between product owner and scrum master. Previous to our jumping on the recording today, I was in standups. After this conversation wraps up, I’m going to be going into road mapping and release planning and the relationship that makes those kind of planning and updating and team dynamic meetings work is definitely my relationship with my scrum master and my team. I think the relationship that I have with him is 100 percent correlated to whether or not I’m a success or not on my products. So because you’ve written about that dynamic, I’m curious if you could give us some just practical applications for young product leaders who are trying to get their bearings. Maybe they’re just starting out in their careers and trying to figure out where to go for what kind of input and details. And I’m curious, you dropped Mike Cohn’s name in your upcoming manuscript; he’s absolutely fantastic thought leader in the scrum space and in this dynamic overall. I’m curious, first of all, what do you think should and shouldn’t be the relationship between product ownership and scrum masters? And then secondly, do you have any words of wisdom that you’ve picked up from Mike Cohn that you think are worth passing along just as a fan of his blog.

Roman [00:18:38] Yeah, sure. Great questions again. So I find that the scrum master role, the coach, the team coach, the agile coach role is often misunderstood by product people, you know, partly because not all organizations use scrum masters and then not all scrum masters are able to do an effective job, either because they lack the experience or some skills, or maybe because they’re too stretched, they look after too many teams at once. But I look at the scrum master as an important partner that the product person, the product owner, the person in charge of the product. And it seems, you know, Paul, that that’s the relationship that you have in place with your scrum master. So the person that takes care of process and people issues so that the product person can focus on, well, the product and offer product leadership. So in summary, for me, the scrum master offers process and people leadership. So things around staffing, for instance, something that I find. Some scrum masters scan CVs, for instance, and then set up interviews and then involve team members in interviewing candidates who might join the team, making sure that the roles are filled and finding the right team members, for instance, you know, taking care of the process, helping people collaborate, evangelizing an agile way of working across the organization and explaining it to the stakeholders, preparing and facilitating meetings. You know, having meetings with maybe senior stakeholders and development team members, you know, can be challenging when you don’t have a skilled facilitator with you in the meetings. So that’s something that scrum masters should do. Ensuring that the development team has a productive work environment and any impediments, any blockers, are being addressed. And finally, the scrum master was always thought to be an organizational change agent. I think that the very first scrum book talks about, literally, the scrum master being such a change agent. And so somebody who tackles issues, not only in my mind related to an agile adoption, but also to establishing an effective product management function, at least to a certain extent. Again, a very important role and a very valuable role when it’s staffed with the right person. Now, I often find that, as I said earlier, a scrum master is not available or an effective scrum master is missing, and then I see product people trying to cover. And I think it’s okay, personally, to try and cover for a short while, maybe for a sprint or two and take on some of the scrum master duties. But if that becomes the norm, then that often leads to either the product manager/product owner neglecting the more strategic duties around product discovery and reaching out to users and stakeholder engagement or just getting completely overworked. And neither is desirable. I think as product people we have to make sure that we do a good job, but at the same time, also make sure that the work is sustainable and take good care of ourselves. So if we’re overworked on a continued basis, it’s not in our favor, it’s not in the favor of the product, it’s not in the favor of the company or the users, the team and the stakeholders. So we’re really not doing anybody a favor and so I think then it’s really a question of, what is the right action? And sometimes the right action is escalating the issue and just making the problem apparent, essentially stop covering the scrum master role or even consider no longer playing the role of a product manager or product owner if you don’t have the necessary support.

Sean [00:21:35] Cool. Along the lines of the soft skills, I was delighted to see in the new manuscript that you also mentioned Carol Dweck’s work. I’m a huge fan of mindset and her work on the growth mindset, so I want to give you an opportunity to talk about that and why you think the growth mindset, that whole body of philosophical work around human motivation and mastery, is important.

Roman [00:21:57] Mm hmm. Nice. Yeah thanks, Sean. So I talk about growth mindset as part of a chapter on self leadership. So for me, self leadership is an important concept for two reasons. The first one is that it helps us grow as product people and helps us develop as leaders. And secondly, it helps ensure that the work that we do is healthy, so I related to what I said earlier. A growth mindset I find very attractive because the central idea, as far as I understand it, is that as human beings we have an amazing capacity to learn virtually any skill. It’s up to us if we tap into it. And Carol Dweck argues against, you know, we see ourselves as being talented at something and not talented, not so good at something, but rather saying, you know, we have the skills and we’re just at different stages of having develop that skill. Admittedly, some people developing a specific skill comes a little bit more easier than others. But, you know, we can all progress. We can all be very competent in a broad range of skills. So just make this maybe a little bit more specific, a simple example from my own life is, for many, many years, in fact for decades, I thought I couldn’t bake cakes, because I had a bad experience. When I was about 12 years old I think, I tried to bake a cake and it didn’t turn out well and my mom wasn’t overly pleased because I think I caused quite a mess in her kitchen.

Sean [00:23:13] I think we might have all had that experience.

Roman [00:23:16] You know, the learning that I took away from this was, “oh, you know, I’m no good at this; I can’t bake.” And it stayed with me literally for decades until only a few years ago, I started trying out to bake a cake again and surprise, surprise after following a recipe, it actually did turn out and it was edible. I mean, I’m not claiming to be a master chef or super baker, but, you know, even I can cook and produce a cakes. It shows that often our thinking, our beliefs, our self view, our outlook in ourselves, who we think we are, is holding us back. And we kind of put ourselves in a box, in a corner, and say, “this is who I am, this is how I am, this is what I can and can’t do.” And that’s limiting. That’s limiting from a personal perspective, but it’s also limiting from a professional perspective. Product management is a young discipline, as far as I’m concerned. I feel it’s a very vibrant discipline. It’s a discipline that has evolved significantly over the last 20 odd years, I think alone about the changes we’ve seen in the last 10 years or so with Lean Startup business modeling, agile, and other key frameworks that have influenced product management. So I think it’s important for us as product people to be open to learning new things. And then when you generally think about how innovation happens, you know, we can only create new features and new products if we’re open and develop an open mindset, and I would argue if we adopt a growth mindset, if we believe that we can learn and it’s worthwhile to continue learning and deepen our knowledge and acquire new skills. So this is where, in my mind, the growth mindset piece fits in, and I find that it’s something really empowering and something extremely valuable.

Sean [00:24:48] Yeah. I mentioned self-determination theory earlier. In the self-determination theory, they say there’s three things that are required for human intrinsic motivation: autonomy, competence and relatedness. And it plays well into the competence side of things, like people need to be growing in order to be intrinsically motivated. And I think it’s part of the product manager’s job to be looking at your team and making sure that people have an opportunity to grow. You talk about this in your book too, like give them chances. One of the sort of controversial bold statements you make in the book, I think it’s the header in possibly one of your chapters; don’t manage the team.

Roman [00:25:23] Mm hmm.

Sean [00:25:24] Right. And it’s so true, like, if we’re driving every little detail, we’re going to make a mess and we got to give people the opportunity to step up and grow. And I think the growth mindset and all the things that you just said are a big part of that.

Roman [00:25:37] You know, if you buy into continuous learning and development and if you buy into growth mindset, then you also have to buy into experimentation, and if you buy into experimentation, you have to buy into being willing to try out new things and fail. I think what you said is very valuable, Sean, that if we want to encourage our teams and empower our teams, then we have to give people some space, some autonomy, some freedom, and that includes the freedom to make a mistake, to try new things and fail, because, you know, we don’t want to screw things up, certainly not for cash cows. But, you know, if we don’t personally want to get anything wrong and if our teams are scared, or if we give our teams the feeling that there is no room for any mistake whatsoever, then it’s very, very difficult to learn a new skill and try out new things. So, yeah, I think it’s important to give the teams room to learn and maybe have a sprint where there’s some time set aside that encourages the team members to experiment with new tools, or maybe have a hackathon or other ways to encourage learning, growth, and innovation at the same time. That tends to have a positive impact on motivation and productivity in my experience.

Paul [00:26:41] That’s beautiful. Actually, I think one of the things that I’m struck by; I was gonna say it was implicit, but I think we’ve actually come out and said it at this point. The job of the product manager isn’t just to manage backlogs and write user stories and keep teams with a steady diet of deliverables that they can churn out in the form of features. The real core job description I see as the modern product leader is, is the empathy, trust building, team creativity, building autonomy and part of the self determination theory that Sean was talking about. I feel like the way that we’re starting to see this thriving yet young product management community going forward is that these aren’t just good business practices. These aren’t just ethical. They are that. But all of these things together are what the product manager has been missing. It’s why this role has become such a high demand, title, practice, role within a team. And I think when I started out in the product world, I was more aligned with what I would consider a project manager or a scrum master today. I thought my job was to get the SOW fulfilled, get the features delivered on time. You know, when I was first starting out, I felt like that was my job. Today with, you know, a few years of experience behind me, I feel like my job is to make a vision tangible, to make a team motivated, to build trust with my clients and users, and a lot of that is not just tangential. That is what I do. Is that too lofty of a goal or is that really what we’re talking about?

Roman [00:28:20] I think you’ve put it really, really nicely, Paul. You know, empathy, trust, making meaningful connections with users stakeholders and development team members is a core part of our job and we should recognize it as such. I think I said earlier, you know, those kind of skills, they shouldn’t be further-ons or nice-to-haves. We should actively try to cultivate them, develop them. In a way that’s one of the reasons, certainly one of the reasons for me, why I wrote the book, because I felt that as a product management community, it’s worthwhile for us to bring more awareness to that side of our, in a way, skills that we have, that we need, as product people to do an effective job. So I absolutely agree.

Sean [00:28:56] Cool. Another little sidestep. You love your two-by-twos. I’ve noticed that in your work. You have lots of them floating around out there. In the book you have ones that I found interesting because we’re struggling internally with the concept of like RACI, DACI models. How do you choose who’s assigned to a project? Who has accountability? Right. And your two by two is around people that have high power versus people who have high interest with interest as a proxy for motivation. Like people are highly motivated by the solution or have low motivation. And then you have people of low power versus high power. I wanna hear about that. It’s interesting. You have subjects, players, context setters, and the crowd.

Roman [00:29:31] Yeah, that’s right. I think it’s referred to as the power interest grid. And it’s not something that I’ve developed, but it was suggested by authors of a book on strategy. Ackerman and Eden, their names are. So, yes, as you said, Sean, it looks at two dimensions: the power somebody has and the interest somebody has, and then you get four quadrants. One quadrant was referred to as the crowd. Those would be people with limited interest and limited power. My suggestion is…. You know, generally, I should maybe backtrack a little bit and say for me, this is a handy stakeholder analysis tool. Stakeholder analysis, in my experience, is particularly valuable when you work in a large organization and you have potentially a large number of stakeholders and you can’t engage all the stakeholders in the same way and you can’t collaborate with everyone; it’d be an overkill. I mean, you’d be spending too much of your time in terms of trying to engage with people and you’d engage people and collaborate with people who maybe don’t really need to be closely involved and may not have the knowledge. So it’s a nice stakeholder analysis tool. So, again, you know, crowds are those individuals who have limited interest in a specific product and limited power in terms of being able to influence decisions or being required in order to progress the product, to develop, market, sell it, provide it or operate it. And my suggestion is to loosely inform those individuals maybe through some form of a newsletter or updates. And then you have what’s called subjects in the model, people who have a lot of interest but not much power. So those are often users or product people from related products, and my suggestion is to involve those individuals on a regular basis, maybe once a quarter or so, possibly, particularly when it comes to internal subjects, through a bigger sprint review meeting where you do a bigger demo and maybe also talk about plans for the upcoming months. And then context setters are often senior stakeholders, senior decision makers in the organizations. Often it’s a good idea to consult those individuals and maybe try to have one-on-ones with them. And then what is referred to as players in the models, so people who have a lot of interest in the product and have a lot of power, or you need those individuals in order, as I said earlier, to progress the product. Those are the players, yes, the key stakeholders. And these are the individuals you really want to collaborate with. Those are the individuals you really want to build meaningful connections with, you want to have a trustful connection with, you want to involve in key product decision. You want to make sure that the goals that you use around vision, strategy, roadmap, are shared goals, and that those individuals are aligned around those goals. So, again, it’s a handy tool just to focus a little bit the effort that we make in terms of relationship building and relationship management and making sure that the number of people we involved in workshop isn’t too large to make those workshops ineffective.

Paul [00:32:07] I heard it from Jared Spool, I’m not sure if it’s his research that drove it, but he’s where got it from. He said that if you’re not talking to your users for at least two hours, once every six weeks, the quality of your product overall is going to degrade. There’s gains to be made above and beyond two hours, once every six weeks, but he said that the messages that you’re proclaiming, the experiences that you’re building, are going to become more and more disconnected. I thought that that was any tie in to the two-by-two just in terms of how to focus your time and how to prioritize who you should be talking to and what kind of information you should be getting.

Roman [00:32:45] Yeah, I absolutely agree. I mean, the rule of thumb that I like to use is a little bit less ambitious or a little bit less strict, maybe. I tend to say make sure you meet users at least once a quarter. So get out of the building, meet users, talk to them. If you can, observe how they use your product in the wild, again, you know, for the very same reasons, so to really be able to empathize, to really understand their needs, understand what works for them, and then discover ideas for progressing the product, taking it further, or possibly even developing a new product. So, you know, as Stephen Blank said many years ago, go and get out of the building. The answers usually aren’t found within the office or just by doing Internet research or looking at the data. I mean, data is important. Analytics tools are extremely valuable, but only trusting the data, I think, is wrong. It needs to be complemented. It’s kind of going off a little bit on a tangent, I hope that’s not too bad, but I find it funny looking back at how product management has developed over the last 15 years or so. When I in a way started in product management in the early 2000s and started working with product managers, I think there was much more emphasis on user research and generally market research. Things like ethnography were really big. I remember an article about Lego researchers moving in with families in target countries and spending weeks studying the kids’ playing behavior. And then the digital tools came and were able to collect much more data. And then models like Lean Startup and Customer Development came and suddenly we were looking at data like crazy and drowning in a sea of data. You know, the pendulum has kind of swung to the other extreme and it’s the sort of the healthy medium, what I’d like to strive for: meeting users face to face, but of course not neglecting the data. So, you know, leveraging kind of both the qualitative and quantitative aspects.

Paul [00:34:26] It’s great. I have a couple more questions for you just before we let you go. And this one is probably going to be compiled in some anthology of quotes at some point down the road when we get around to it. It’s a question that we ask of all of our guests towards the end, just to see what fits. The question is, what is your definition of innovation as it stands in the product world today?

Roman [00:34:48] Yeah I think it’s a very interesting question. One of the models that I’ve used my last book, Strategize, is a model suggested by Nagji and Tuff, and they published it a number of years ago in the Harvard Business Review. I like the model because it’s built on the Ansoff matrix, which kind of makes it a little bit more simple. And it suggests three different innovations. They talk about core innovations, adjacent innovations, and transformational innovations, which I equate to disruptive innovations in the sense of how Clayton Christensen defined the term. So core innovations are products that essentially act as cash cows, you know, they’re mature. Think about something like, I don’t know, the Google Chrome browser for Google, for instance, or Microsoft Office for Microsoft, or the iPhone for Apple. Those are core products and adjacent products are innovations where we take an existing product to a new market and modify it, or we create a new product for market that we already serve. And then the disruptive products are products that are brand new and create a new market. So I find it helpful to think about, when I hear the term innovation or when I talk to somebody about innovation, I find it helpful to try to figure out, okay, what type of innovation are we talking about here? You know, some people when they hear innovation, they always think about new product development. But I don’t necessarily think that’s right, as the Nagji Tuff model shows. Innovation Ambition Matrix, I think it’s called, if I remember correctly.

Sean [00:36:02] And the last question we usually ask all our guests is, what are you reading right now? Besides your own books, of course. What are you recommending?

Roman [00:36:10] Oh, what am I reading right now? In terms of business books?

Sean [00:36:14] In our space, in the product development space.

Roman [00:36:16] You know, to be honest with you, as I’m right at the stage where, you know, the book is getting ready for publishing, I’ve been so entrenched in my own book, I know this is really, really sad, that I haven’t really had the capacity to do any reading. So the honest answer is I’m not reading any product management book right now. I’ve got a number of books on my list that I want to read, including Melissa Perri’s Build Trap, but I just haven’t gotten around to it. I’ve been so, so busy. So, you know, how I work is that I tend to have phases where I do research and I read books and I really have dedicated time and make an effort. And then I have phases where I’m just super busy and I’m just really, really super focused. And, you know, I wouldn’t necessarily recommend to copy that, but it seems to work out okay for me.

Sean [00:37:02] Well, you did mention Eden’s book, Making Strategy I think is the name of that book, right. [Making Strategy:] Mapping Out Strategic Success.

Roman [00:37:07] That’s right, yeah.

Sean [00:37:07] So we’ll count that one. That’ll work. But I want to thank you for joining us. I think your latest manuscript, your latest piece of work, is going to be an incredible contribution to the art of product management and into our space. So thank you for writing it and thank you for joining us, for sure.

Paul [00:37:23] Roman, it’s been a pleasure.

Roman [00:37:25] Thank you, Sean and Paul. Thanks for the kind feedback. Thanks for having me. It was really nice to talk to you.

Sean [00:37:30] Yeah, this was a lot of fun.

Paul [00:37:31] Cheers.