Fundamentals of product management with Roman Pichler

Join Murray Robinson and Shane Gibson as they delve into the fundamentals of product management with Roman Pichler, renowned author of ‘Agile Product Management with Scrum’.

Topics we’ll explore in this conversation include:
🔸 The role and responsibilities of a product manager
🔸 The difference between a product and a project
🔸 The distinction between a product owner and a product manager
🔸 Essential tips on developing a product strategy and roadmap
🔸 The importance of focusing on objectives, not feature lists
🔸 The value of continuous discovery during delivery

Tune in to gain valuable insights into the essentials of product management and learn how to steer your product towards success.

Read along you will

Murray: In this episode, we discuss the fundamentals of product management with Roman Pichler, author of agile product management with scrum. What is a product manager? What is a product? What’s the difference between a product and a project? What’s the difference between a product owner and a product manager? 

How do you know what to build? How do you develop a product strategy? How do you develop a product roadmap and define sprint goals? Focusing on objectives, not lists of features. Focus on one goal at a time. Time box product goals to maximize value for money. Don’t be an order taker. And how to do continuous discovery while delivering.

Shane: Welcome to the no Nonsense Agile Podcast. I’m Shane gibson.

Murray: And I’m Murray Robinson. 

Roman: And I’m Roman Pitchler.

Murray: Hi Roman. Thanks for coming on. 

Roman: Thank you for having me. Nice to be with you. 

Murray: We’ve wanted to talk to you about product management. You’re quite well known for writing agile product management with Scrum and you’ve got another book, Agile Product Leadership and then Product strategy. 

So why don’t we start if you could tell us a little bit about who you are and what your background and experience is, where did you start and how did you get to this point in your career?

Roman: Yeah, sure. Where and when did I start? A long time ago, I started out as a developer and experienced. What I guess many people who write code, write software, work on digital products, experience that it was stressful and it was challenging. And I then moved on and did some internal technology consulting because I thought that’d be a nice way to help other people and maybe also widen my horizon and broaden my skillset too. And, after a while in that role, I discovered the real issue aren’t really the technologies. It’s more the way people interact. It’s the processes. And it led to me becoming increasingly interested in agile processes and starting to apply agile processes in the form of extreme programming. In 2001. It’s a client, which didn’t work out at all but it was a great learning experience. The other thing that I noticed as part of that project work was that there was a real issue in product management. So we were dealing with a brand new healthcare application, a new brand new healthcare product, and there was a lack of direction in terms. What’s the value that product should really create? What’s the target market, and particularly what makes the product stand out? What are the differentiating factors? Which then led to real issues around what requirements should be written and how should they be prioritized. And so it really triggered an interest in product management and working with, product people. For me. and ultimately I guess those two factors combined have led me to where I am today. So very much interested in product management, are very much interested in trying to help product people create value, do a better job, and at the same time, interested in agile practices, leveraging agile practice and principles in order to make sure that the way we work is healthy and, sustainable. 

Murray: Have you been a product manager yourself? 

Roman: Yes and no. It’s an interesting one. Like many people, I fell into product management by dealing with a development effort that experienced issues and then discovering issues in product management that might be critical than deciding, which component model should be used . So yeah, I fell into product management and never held the position where I was called a product manager. But, I realized that a lot of the work I’d done, particularly as part of the internal consulting job really was creating products, creating services, describing those services, positioning them and also marketing them. 

And the same is true, for the job that I’ve got now. I’ve been running my own business now for 17 years and the number of services and products that I look after that I manage. And for me, that’s an important part of my work because it allows me to experiment with new ideas, and it allows me to keep my teaching fresh. Some of the tools that I’ve developed, like the product vision board for instance, that was partly driven by the work I did with. Product people, product managers, product owners, and seeing that, people struggled to describe a vision and a strategy, but also partly because of, my own needs to capture the value that my products and services should create.

Murray: Yeah. So What is a product manager, in your view? 

Roman: Yeah, that’s an interesting question. And as with many concepts and terms in product management, there’s probably not one right answer. So for me, a product manager is somebody who looks after a product and is responsible for making that product successful or keeping that product successful. So ensuring that the product generates the desired value for users, possibly customers in the business. So if a product manager is somebody who manages a product or makes sure that the product is successful, then I guess it’s natural to ask what’s a product? And for me, a product is an asset. Something 

that is able to create value for a group of people and an organization largely on its own. So it might be software it might be. Hardware, plastic, a combination thereof, plus additional artifacts. But the important thing is that it is a value creating entity or something that has the potential to create value largely on its own.

Murray: So what’s the difference between a product and a non-product? Like a service?

Roman: Yeah. Yeah. Thank you. So you’ve already mentioned something that typically isn’t referred to as a product, a service, a product. Would be an asset I’d look at a product as an asset that is readily available that can be used. Whereas a service is something that needs to be instantiated, needs to be provided typically by a human being.

If I think about my own services, my consulting services, coaching services, training services. These have to be provided, these have to be instantiated in this case by me. And then there’s another important, distinction and that is between product as a whole and product parts. And I think particularly when we talk about product management, because not every person who works in product management or has some form of ownership, owns necessarily a product in its entirety. Particularly when products are large, sometimes people own parts of that product.

So for instance, people own the tactical decisions, the tactical aspects part of the product backlog, like , in the agile scaling framework, SAFe for instance, or people own end user facing capabilities which I call features, say search and navigation for instance, on an online retailer’s. Or I’ve seen people manage and own architectural building blocks components, subsystems services rather than a product in its entirety. So it’s important to distinguish between what is a product and what are product parts, and for people who manage a product or who are in product management or who exercise some form of ownership, I think it’s really beneficial to be clear on what do I manage, what do I own, and therefore what’s my responsibility, but also what level of empowerment and decision making authority do I require in order to be able to do a good job.

Murray: Yeah, so we spoke to Rich Mironov, recently and he said a product is something that you build once and sell or use many times. If you are developing a custom service for each client you work with, then that’s not a product. What do you think about that definition? 

Roman: Yeah. I think Rich is very right , in distinguishing between a commercial product and a bespoke or tailored or customized product. And so a commercial product is readily available off the shelf.

It’d be like a book. You go to a bookstore, you buy that book, you order the book online, it’s shipped and delivered to you. It’s ready. Whereas , a bespoke tailored product would be, I guess if I stay with the analogy, writing a book for a specific person or a specific group of people.

The reason why that’s important is in a software development setting the different business models at play and that the role of the product people changes significantly. So if you are an agency and you primarily generate revenue by offering bespoke, tailored, customized products, then the sales people will be extremely important and you’ll be driven by client projects. Acquiring a client project, executing that project. Clients will also have a major influence in shaping product decisions. Whereas when you are in the business of offering commercial products that are readily available and serve a larger, usually more diverse market, you have to have strong product management capabilities and you have to be willing to take informed risks. You have to understand the market. You have to understand user, customer needs, the competition, and then say, okay, we. There’s a need here, there’s an opportunity. We can address this opportunity. Let’s go for it. So it’s a different business model. You need different, organizational capabilities and different approaches.

Murray: What’s the difference between a product and a project 

Roman: Yeah. Yeah. That’s another interesting, another interesting source of confusion. So for me a product has enduring value. Not all products make it to launch. I’ve worked on a number of products that didn’t make it to launch, including my own development initiatives, within my own business. And then not every product becomes a successful product. Not every product achieves product market fit, but generally I think expectation is that a product at least has the potential to be enduring and stick around for years. I’ve worked with organizations whose digital product software products were older than 20 years, and those were commercial revenue generating products. Not the entire product was that old, but at least, part of that product dated back went back quite, quite a while. Whereas a project for me is a temporary initiative in order to achieve a specific goal. Either create a new product version, or maybe a brand new product or enhance an existing product and maybe get out a new version or a new major release. So I’d say that you can use a series of development projects to create and enhance a product. But the product is the output that you generate and the thing that you enhance. It’s also the thing that ultimately creates value for users in the business. And yeah, as I said it has an enduring quality.

I expect the product to stick around for a few years, whereas a project, I don’t know, I guess it depends, on the type of product that is being developed. If we’re talking about a development project it will be anywhere between a few months and maybe a year, maybe a couple of years. If it’s a complex product .

Murray: Yeah. I think that leads to a very different perspective on what you’re doing. Because if you’re a product owner on a project, your job is to achieve some sort of business goal, primarily defined by a set of features within a given time and budget. So you’re focusing on deliverables. Whereas if you are got the long-term view, then you would be focusing much more on measurable outcomes, I would think.

Roman: Yeah, you’re right. The success criterion for a project manager is to deliver requirements specification on time and on budget. The success criterion for product manager is to make the product successful and keep it successful. And again, for commercial product, that means achieving product market fit. And then, keeping the product in the growth stage. And even afterwards when your product has matured, then milking that product and maximizing its return on investment, the benefits that it generates for the business.

Murray: So what is a product owner and what’s the difference from a product manager?

Roman: Yeah, great question. What is a product owner? The product owner? is probably, many listeners will know is a role that originally emerged in the Scrum framework in the late 1990s. But product management’s been around for much longer. So some people say since the 1930s, I probably fall more into the camp that says probably in the 1950s when product management started to crawl out of engineering and marketing and companies started to introduce product management functions, product management departments. And then in the digital space, the software space the first software product manager started to appear in the 1980s. I believe Microsoft was one of the first companies using product managers to look after software products. 

The product owner role is much younger and it’s a scrum specific role. Many people think of the product owner as in a way, a someone a role that fulfills a subset of the responsibilities and duties of a product manager. Sometimes the product owner is seen as a product backlog manager, somebody who looks after the product backlog, somebody who interacts with development teams, somebody who writes user stories, refines product backlog items. And that’s not entirely untrue. Often that’s part of the work that product owners are involved in . And it’s also not untrue for a specific type of product owner which makes the whole conversation a little bit confusing maybe.

So , there are two types of product owners . There’s the, original product owner role as defined in the Scrum framework. In there is another product owner type, the safe product owner that was defined within the Agile scaling framework Safe. And the safe product owner, in fact is a tactical delivery focused role that manages a team backlog and is internally focused. Whereas a product owner in Scrum has the responsibility to maximize the value a product creates. And for me, when I think about what that means, maximizing the value a product creates really ensuring that a product becomes successful and a product stays successful and generates as much value as possible for the users’, customers, and the business that’s impossible to achieve in my mind if the person is purely delivery focused and only empowered to make tactical, detailed product decisions. I think what it does require is an understanding and an ability to sh shape the product strategy and key strategic decisions. I’ve always looked at the product owner as a product person who looks after a product, manages a product owns a product on behalf of the company. So I’ve always thought the ownership is a nice metaphor to indicate the level of empowerment that product people require in an agile setting where, collaboration is valued and, development team members and stakeholders and maybe even users and customers are pulled into the development process and asked for their views and feedback and suggestions and have potentially quite a diverse and large group of people and still have to make a decision.

And so if no agreement can be reached, then the product owner has to have the final say or the right to make a decision so you can keep the product moving forward and at least run an experiment and try something out and see how that works. Yeah, I’ve always thought of the the Scrum product as a product manager in an agile context 

Murray: , if I think about what was there was before.

I used to think of the product owner in Scrum as the owner of the product, developed by the Scrum team, and that could be an internal or external product, but usually it was some sort of system. And it replaced somebody called the business project manager or the business manager. Somebody who was the manager of the department that was receiving the product. So they would normally be a subject matter expert who could be relied on to talk to all the right people, the internal users.

Roman: Yeah. And I think, what you’re referring to is one of the reasons why Scrum introduced the product owner role in the first place. Why didn’t Scrum just, use the more established term product manager? And, one of the reasons is that not all organizations that have applied Scrum have a product management function and have product managers. Think about banks, think about media companies most of which historically at least, or traditionally don’t have any product management department. Certainly not for digital products, for software products. And by having a product owner role, scrum allowed those organizations to start applying the framework and applying agile practices. And then the other key reason for me is that, Product management used to be different from what it is today, particularly back in the. The product management processes and the overall innovation process used to be much more sequential and you’d get people that would do the market research and engage in business development. And then, come up with a strategy document. And then you’d have maybe product managers who’d create a product roadmap, the requirement specifications, and essentially throw that specification and the requirements over the fence to a project manager who’d work then with one or more development teams to get the product built. And then there’d be a test group to test it and so forth,

Murray: Yeah. 

Roman: Whereas obviously the idea in an agile context is that we want a close collaboration between the product people and the development teams. And we want to bring people together who understand the product space, who understand the market and the domain with technology and design experts to build a product , that hopefully is valuable. And pull in key stakeholders as it’s appropriate. It’s a very different approach. It’s a very different process. And I think, that, that justifies at least to a certain extent, the term product owner or the introduction of a new term, of a new role name.

Now, of course, we can ask ourselves, at this day and age Is it still useful to use the term product owner and continue to use it? But it’s essentially up to Ken Schwaber and Jeff sutherland formulated the Scrum framework to decide what to do with the terms. But, ultimately, it doesn’t really matter if somebody’s called a product manager, product owner, product champion, product leads, product person, product professional. Different people have suggested different terms over the years. What’s important I think, is that there’s it’s clear what a product is and it’s clear who helps manage that product and move that product forward and ensure that product does create sufficient value. And, whatever that person is then called, or whatever the role is called, I don’t think that it matters that much. 

Murray: Yeah. So if we look at we see out there in the world at the moment, we see a lot of product owners performing a business analysis function. They are expected to write their user stories and to go out and interview all the stakeholders and find out what they want and find out what the business process rules are, and then prioritize them according to what the stakeholders have said. But that’s not what we want a product manager to be is it?

Roman: No, I think it’s one of those things where, of course it’s important to pay attention to the details and it’s, of course it’s important to ultimately execute a product effectively.

Murray: Yeah. 

Roman: If that’s all we do, then the dangers, we no longer see the wood for the trees and, if we’re unlucky, we’ve actually walked into the wrong wood and we’ve strayed off the path and we’re building a product that nobody really wants and nobody really needs. So, for me it’s difficult to understand how I can discover the right requirements, how I can write the right user stories if I don’t know who the users are and I don’t understand why people would want to use the product. So for me, that has to be clear before I start worrying about the solution. Before I start worrying about the product details. Before I think about the product backlog and I think about capturing user stories.

Murray: Yeah. 

Roman: Understanding the market, understanding who the users are, understanding, what value my product should create for the users, which specific problem it should solve, or which specific benefit it should address. And maybe also what business goals it should help me. For me, these are important strategic decisions that I would capture in a product strategy. So somebody who works as a product person, no matter if the individual’s role is referred to as a product manager or product owner, should tackle those questions and should ultimately engage in strategic decision making process.

Murray: So how do we know what we should build? Because the research by the Standish Chaos Group and by Pendo shows that 70 to 80% of the features we build are rarely or never used. So how do we know what we should be building? 

Roman: Yeah, that’s a very important question, and I don’t think there’s one right answer. The approach that, I like to suggest and I found helpful in my own work is to spend. As little time and effort initially as possible to create what I call a draft product strategy. So to be in a position that I say, okay, I believe that should be the target group. The users, the customers. We should address. I believe that is the specific problem my product should solve. So to make this more specific, I don’t know, the target group might be middle-aged men like myself who’ve developed unhealthy eating habits over the years. And the specific benefit might be to reduce the risk of developing type two diabetes, for instance. 

And then I think about what would be the business benefits? What would be the incentive for my company to invest in a product that generates those user benefits? And maybe that might be to open up a new revenue stream. Maybe it might be to diversify the business. Other business goals might be to reduce cost, increased productivity, develop the brand, and increased brand equity. And then if it’s a commercial product, I might think about what are maybe some three to five standout features, something. Personalized eating recommendations or seamless integration with leading smart watches and smart scales, those kind of things. And once I’ve got this, and again, I’d call those, four elements, a product strategy. Once I’ve got them captured, or once I’m, got them drafted. I then go through those statements and say, okay, is there any uncertainty associated with them? Am I sure that I’ve chosen the right target group and do I have some form of empirical evidence to back up my views?

And if that’s not the case, there’s a risk that maybe it isn’t quite the right group. Maybe the group is too small, maybe it’s too big, maybe it’s too diverse. Maybe it’s the entirely wrong group. in order then to validate my decision around users and the target market, I’ve been carry out some validation work. And that might be to observe prospective users and to interview users and carry out problem interviews. Find out more about the health situation, their eating habits. And I then move on and do the same thing for the value proposition for the standout features and for the business goals.

And process that I’ve just described essentially is you create an initial draft strategy that is good enough that is just testable, and then you iterate over it very much like you’d iterate over a product backlog. And you test it and you refine it and you correct it until you are certain and you’ve got empirical evidence to show that the strategy is likely to be correct.

And for me, that’s a key way to reduce the risk that we’re building something that was super excited about that we want to build. It’s happened more than once to me, but there’s no real market or the value proposition is not strong enough or the business goals are not attainable. 

To share, an example from my own work. I once had the idea to turn the little templates that I’ve created over the years into a software tool. And I got quite excited about this, thinking, oh, this is gonna be great. My own digital product. And in the new revenue stream new up, a new essentially part of the business is gonna be amazing and, doing interviews with customers and hearing, there’s a real need for that and that could really work until I looked into, feasibility and attainment of business goals.

And it occurred to me that not only would it be not necessarily cheap to develop such a tool, but the key point for me was that I realized I’d have to build up knowledge capabilities around being able to sell a software tool to larger companies. And it’s just something that I have no experience in whatsoever.

I know how to sell services to companies, but I think that’s different from selling software tools. And the only way for me really to pull this off would’ve been to hire someone with appropriate experience. And I was very reluctant to do that. I was very reluctant to change the business in that way. And also, to make that commitment in terms of the money that is then required. So I pulled out of it and, I invalidated my idea essentially. It just didn’t work out. And in hindsight, I’m glad that I took that decision. Even so at the time I felt quite down and said about it. Because, as it often is the case we have an idea, we get attached to the idea, we get excited, and then it can be hard to let go and admit to ourselves that, oh, maybe, what looked like a great idea initially isn’t a valid idea, isn’t something that really can generate sufficient value for users in our business.

Murray: Yeah. And I think that’s probably one reason why people don’t test their ideas or, review the data when things are out in the market. Cause they actually are quite frightened about what they might find. It’s hard on the ego. 

Roman: Yeah. that’s right. Isn’t it also referred to as confirmation bias that we just prefer data, we prefer information that confirms our preconceived notions and ideas, our opinions.

Murray: Yes. 

Roman: makes us feel good.

Murray: As we’re talking, I’m looking at your tools on roman pitchler.com/tools, and I think you’ve been talking about the product vision board.

Roman: Right. Yeah.

Murray: So the sections are: What’s your vision? What’s your target group? what are their needs? What’s the product that you think you’re going to give them? And then what are the business goals? is that the first part of your product strategy? 

Roman: For me these are the essential elements of a product strategy. There is no universally accepted definition of what a product strategy is, and I think that’s virtually true for any term in product management. I think most of my colleagues in product management would agree that. A product strategy should talk about the needs that a product addresses or the value it creates. I think most people would also agree that you probably want to talk about the audience, the target group, the market segment, the users and customers, whichever terms you prefer. I think most people would also say, there have to be some form of business objectives and, to which extent you then talk about the product and standout features is debatable. For me, it’s helpful because I feel that particularly revenue generating products have to be positioned and it’s useful to do a little bit of competitive research and competitive analysis and yeah, figure out how could our product stand out from competing offerings. 

The product vision board really came out of the issues that I experienced working with product people and making strategic decisions for my own products, where I was looking for a very simple tool. The simplest thing that could possibly work to capture key strategic decisions.

Murray: Now, how would you recommend that people go about developing that product vision template? Should they shut themselves away in a room and write 10 pages for each section? Or should they take a different approach? How do you think you should go about doing it? 

Roman: One of the ideas behind the product vision board is, and that’s inspired by the business Model Canvas, is to offer a visual tool that encourages people to only capture essential information. So it’s not about writing down everything , it’s really focusing on what has to be captured right now. What is important in order to make key strategic product decisions. It should really be a simple one page document. And my original idea with the product vision board was to print it out and give it to people. And when I was still running Classroom-based training courses, I would get people to draw up the structure on a piece of flip chart paper and use post-it notes in order to populate it.

But the point is, not to turn the product vision board into some form of product backlog and add loads of stuff, but only capture what really is important. And not do it on your own. I’m very much in favor of a collaborative approach. It’s an important part of working in an agile, way. My recommendation is to think about who are the key stakeholders whose expertise I need to make the right product decisions and whose support I need to deliver a product.

And for commercial product that might be somebody from marketing sales, maybe somebody from support or finance and involve those individual in a visioning strategizing session where an initial product vision board is being created. And in addition to the key stakeholders, also invite development team members or representatives from the development teams, to leverage their perspective and leverage their expertise and address design and technology issues and risks at an early stage.

I’m very much in favor, of a collaborative approach leveraging the wisdom of the crowd, without making the mistake of trying to please people or trying to broker a compromise, I think that’d be wrong. It’s important to make the right product decisions and it’s not necessarily important that everyone is always super happy with every single product decision, but that people are at least consulted, that people have an opportunity to influence that people are being involved. That there’s transparency, people see what’s happening and why decisions are being made. My experience suggests that significantly increases the willingness of the individuals to then support the decisions and support the strategy, even if, they’re not super happy with every single detail.

Shane: So one of the things I find when I talk to people is they get confused between vision and mission strategy and roadmap execution. And when I look at the template you have that idea of a vision board and then it goes into a roadmap, which gives you a sense of time of what might be built when, assuming the prioritization doesn’t change.

And then you break it down into, some persona mapping and a product canvas. The product canvas effectively driving a series of iterations, and then there’s a sprint goal template for an iteration, what are we gonna achieve within that iteration?

I often see, people get confused between epics, features, users, and tasks. It’s that whole hierarchy, I’ve seen epics that look like features to me. Sometimes they even look like tasks. I’ve seen epics that look like a five year strategy. Do you find that, do you find that, because it is so flexible about the grain of what can go into each of those templates, the way you describe what the boundary of work to be done is that everybody takes a different lens, or is there a natural way you would teach somebody to go, if it looks this big, move up the template chain? 

Roman: It’s a great question. I like to start with the vision in the sense of describing the ultimate reason for creating the product, the positive change it should bring about.

So I mentioned this product that reduces the risk of developing type two diabetes and a vision for such a product might be to help people eat healthy . I quite like to just use a very short brief vision statement or slogan that hopefully resonates with everyone involved in providing that product.

And then based on that vision, I like to capture the strategy. And for me the strategy then describes the path or the approach that we believe will be valid in order to realize the vision and make the product successful. And, in the strategy, I capture the needs and I capture business goals. You can also think of the needs as user and customer goals. So now I’ve got more specific goals. 

The vision is a goal as, as well, but it’s a big hairy, audacious aspirational goal that can’t be measured. And I always say a vision should be valid for five to 10 years, maybe longer. So I wouldn’t really expect the vision to change significantly over the lifetime of a product.

But the strategy will change. And the strategy is usually only valid for a life cycle stage, say from introduction, you wanna move to a growth, then you have to change your strategy. But also what happens is that now the goals are more specific. 

And one of the mistakes I see people make with a product strategy is that it’s too high level, it’s too course grained. But when it’s too course grained, it becomes very difficult to test it. It becomes difficult to see uncertainty and risks and assumptions and address them systematically.

So it’s a good idea to really make that strategy sufficiently specific, particularly the goals. And then I use the needs, the user, customer goals and the business goals in order to derive outcomes or product goals and capture them on a product roadmap. And one way I do this is by breaking the needs and the business goals into sub goals, and then ordering them in a way that I believe is meaningful.

If I’ve got this healthy eating product, I might say, a good first product goal is to help people become aware of some of the eating habits. What they have for breakfast, if they have breakfast, how much they have for breakfast, and acquire an initial user base.

And then, the second goal might be to create more awareness and maybe talk about dinner and acquire more users. And maybe then I start generating revenue and try and encourage people to subscribe to my product by offering personalized eating recommendations, for instance. I find it very helpful to use goals and outcomes on a product roadmap as the primary elements. And secondly then to connect those outcomes and goals on a product roadmap to the strategy and the goal stated in the strategy. And then in order to make the connection to the product backlog, I simply take the next outcome or goal on the product roadmap and copy it into the product backlog, which gives me a goal directed focused product backlog, which is also what the latest scrum guide suggests.

I’ve been working with product goals now for many years, and I really like them. I think they’re great to focus the development effort. They’re great to focus the product backlog and they avoid big, bloated backlogs that look more like a wishlist than the outstanding work required to deliver a product version and achieve a clear benefit.

It’s moving away from thinking about features and functionality to thinking about benefits and outcomes and goals that we want to achieve. And the specific value that we want to create. And again, the way I do this is by having, these high level visionary goal, then having strategic goals on the product strategy than more specific measurable strategic goals on the product roadmap. And then taking one of those goals and moving it into the product backlog so that all the tactical execution, delivery oriented elements in the product backlog are essentially governed by an outcome, are governed by a product goal. And that way everything ties together everything is connected. Which, if you do it right, it gives you a great consistency.

Shane: Yeah. And that, aligns with the idea that the product owner is there to explain to the team the strategy and the goal. This is where we’re going, this is why we need to get there. And then it’s up to the team to determine the best way to actually achieve that goal. And so that kind of framework where we focus on the goal, not the feature gives that alignment and that boundary in a nicer way.

Roman: Yeah, that’s absolutely right. So I think a common mistake product people make is to. Solutionize too much. To spoon feed development teams with very detailed requirements but I think it’s great to try and empower the development team and to a certain extent educate the development team so it can become self-sufficient and ultimately own the solution and help make detailed product decisions. It’s always nice to try and establish a collaboration between product people, say a product owner and a development team when it comes to product backlog work.

But I find it’s a tends to be a positive sign when a development team becomes capable and willing to do some of the refinement work on their own. And that way also the workload of the product person is lightened and there’s a little bit more time to focus on the strategic and discovery oriented work.

Murray: So you have a business goal in your product vision, and then in your roadmap you break it down into a series of smaller goals for the product. And then you, also have a metric for each product goal? 

Roman: That’s right. Yeah. So the idea with the metrics is to state success criteria for each goal, for each outcome on a product roadmap. So we can understand if the goal has been met. if one of my goals is to acquire users, then it might be worthwhile to think about, okay, how many new users do I want to acquire? And are those users within the market segment that the product is currently addressing? Or do I want to reach out to a new market or market segment? So again, I can then look back and say yep. We’ve met that goal. Great. Everything seems to be on track. Or actually now we missed that goal. And I tend to then add those metrics that I capture on a product roadmap to my set of key performance indicators or KPIs. KPIs measure the value that our product creates the metrics that help you understand how much value your product is creating. And in order to determine the right KPIs, I use the needs and the business goals and the product strategy, and I use the product goals on a product roadmap and ask myself, how can I tell that I’m meeting those goals?

Again, that then helps me determine the right set of key performance indicators. And I’m stressing the right set because it’s not uncommon for me to work with product people who say yeah, but my boss told me to use those KPIs. Or I read an article where they said, for a sus product, you must use those 10 KPIs. So your boss understands your product better than you. Or somebody who writes an article about SAS products, understands your product better than yourself. I doubt that. So yeah, rather than just taking a set of predefined KPIs, I think it’s very important to look at what are the strategic goals that we have? What are the strategic outcomes that our product should achieve? And then use those goals. Use those outcomes in order to select the right metrics, the right indicators.

Murray: And for each goal in your product roadmap, you also have a list of features by the look of it that you think will allow you to achieve the goal. 

Roman: That’s right. Yeah. So the couple of reasons why. I still like to work with selected features on a product roadmap. The first one is because I find that it can be very helpful for the stakeholders and the development teams to talk a little bit about aspects of the solution, key capabilities that have to be provided or enhanced or key deliverables that have to be created. And the second reason is that historically a product roadmap is a list of features mapped onto a timeline. And many organizations still use those types of roadmaps. I routinely do a little search on Google images and just, key in product roadmap. And most of the images that come up are feature-based roadmaps. I think slowly the industry is changing. But again, many organizations are still very much used to working with feature-based plans, feature-based roadmaps. And so then to help an organization move to a more outcome-based, goal-oriented way of working, a soft sale to say look, what really matters are the outcomes and the specific value that the product should create over say the next 12 months.

That’s what we want to focus on. And in a way that’s the only mandatory element of any outcome-based, goal-oriented roadmap, but you can add three to five high level course grains capabilities, features that sketch out key aspects of the solution. And yeah that I’ve just found that it makes it easier for organizations to embrace this new way of working.

But, as I said earlier, all my templates are there for people to try out and also to tailor. And so if one of the listeners says I don’t wanna use features because I’m worried that this is gonna lead us down the dark path to a feature factory, by all means remove it from the template. Or recreate your own version of the product roadmap without a feature row and and I’ve seen people add elements to the template like budget targets for instance. I’ve seen people dislike the suggestion to work with dates or timeframes and remove that element and that’s all Cool. The point is really to think about specific, ideally measurable benefits, outcomes that your product should create, over the next 12 months. And then use other elements that you feel are helpful in your context for your product. And if they’re not helpful, don’t use them.

Murray: Yeah. So would you work on one product goal at a time? 

Roman: Yes. Good question. I think it’s a very important question. Generally, my recommendation is work on one goal at a time. I feel that creates alignment. I feel that facilitates collaboration with the stakeholders and development teams. And I feel it’s easier than to measure progress. If you work on multiple goals, then there’s always a danger that some people work on one goal, other people work on another goal. You lose cohesion. It’s not such a collaborative effort, not at least across the entire group, in that it becomes harder to understand how we’re tracking, how we’re doing if we’re on track to meet those goals or not. So yeah as a general rule of thumb, one goal and for a product goal on a roadmap, I tend to suggest to shoot for a goal that can be achieved in a two to three month timeframe. I wouldn’t go lower than about six weeks and I wouldn’t go for a timeframe that’s, much longer than six months. I find two to three months goals tend to work quite well for most organizations. 

Shane: So where we’ve got, multiple teams, that are working together to achieve the outcome. Would you do a single product roadmap and then have multiple goal columns in play at any one time because each team’s working on a unique goal, or would you have a goal that was two to three months and then all squads are working on the same goal, and then they at the backlog level, how not to stand on each other’s toes, what do you typically see? 

Roman: I’d prefer the letter approach. So for me, it’s always important to be clear on what is the product. And then once I understand, okay, that’s a product, then that product deserves a vision. It generally speaking, deserves a strategy. It deserves a roadmap and a backlog. And then no matter how many development teams there are, if there’s one development team or if there’s 10 development teams or 20, they all work on the same strategy. They all work on the same roadmap or goals on the roadmap and they consume items from the same backlog. 

So I’d have all those teams work on the same protocol and be synced through the same protocol. What might differ potentially are the sprint goals that they’re working on. So they may or may not be working on the same sprint goal, but certainly on the same product goals. That then creates the alignment. That creates the togetherness and hopefully, make sure that everything that is being developed, everything that is being created can be integrated and is being integrated.

Murray: So were we time boxing these product goals? 

Roman: Possibly. I like to work with dates or timeframes, at least for internal private roadmap, that you don’t communicate to customers so that you can balance dates goals, and budget. And you can think about what is more important is it to fully meet the goals on our product roadmap map or to hit certain timeframes. And for some products like seasonal products, the timeframes are more important. Say, you develop a new computer game you must have a new version available in time, for the Christmas sales. Because that’s why you’re likely to make most of the annual revenue.

And for other products, it’s likely to be more important to fully meet the goal and then be flexible with regards to the date. Cuz we can flex the budget, but there’s only so much money an organization typically has. Plus even if we are able to increase the budget than often we’re not able quickly enough acquire or hire pull in experience people with the right skills to really make a difference.

So often the trade-off is between the degree of to which we meet a goal and if we do it on time or not, if we’re flexing the time or if we’re not able to flex the time. And I think that’s an important conversation to have when you create a product roadmap or when you rework a product roadmap.

But that’s an also an important consideration as you track the progress towards a product goal whichever way you do this, the traditional way in a scrum context to do it might be to use a release burndown chart, for instance, that’s pretty old school, but can still work quite well I find. And then, you say, okay, you know how we’re tracking how we’re doing and is it still right that we want to deliver on time here? And then are we still willing to maybe only partially meet the goal? Maybe not. All of my AI-based personal eating recommendations are being delivered as part of this specific development effort. At least the new release, the new version goes out on time.

Murray: What I was thinking of was let’s say you’ve got a lot of people working on something. Can you burn rates a million dollars a month? Then we might say we wanna work on this product goal for two months. Let’s say it’s, we wanna fix up the the process that people go through as they’re placing their orders cause , we’re getting a lot of dropout at the moment. That’s worth spending $2 million on and we are going to, fix that up as much as we can within that time and budget. 

That’s one way of doing it. And it seems to me that’s the agile way of doing it. We, set the goal, the time, the team, the budget, and we allow the scope to flex within that. Whereas the other way of doing it is more like, I developed this big list of features and then, we try and fix the scope, in which case, generally we, will blow out the budget and time. 

Roman: Yeah. I think options are valid. Ultimately it depends on what is the right thing to do in terms of maximizing the value that the product creates. Is it likely to be the better decision in terms of value creation if we ship on time, or is it better to push out the release date because we know that we need to fully meet the goal and implement certain features to a certain extent?

And from my personal experience I’ve used both approaches. So where I feel it’s important to make sure that the goal is sufficiently met is when it comes to book writing efforts. Again, talking about my own work, it’s happened to me virtually with any book writing project that I’ve pushed out the release date, the publication date, because for me, there’s no point in publishing a book if it doesn’t create sufficient value and if the quality isn’t quite there. I’d rather flex the date. I’ve worked on other products where, it’s absolutely the right thing to do to say, there’s a window of opportunity, there’s a specific timeframe that we have in order to get that product out, and we’ve got to meet that.

And if that means that some features are only partially implemented and maybe we can’t create quite as much value or address a need quite as comprehensively as we’d like to, then that’s the way it is. As long as we’re giving the users enough.

Murray: So it’s quite common when you’re doing a product roadmap like that for senior executives to put a lot of pressure on you as the product manager to say you have to have all these features delivered in six months. Exactly. Cause we’ve already sold it.

And why did they say six months? Cause that’s what the customer wanted, and because people up higher just thought, how hard could it be? So they’ve already committed and now you are being told as the product manager, what would you suggest you do?

Roman: For me if my boss comes to me and says, Roman, look, Here, you’ve got six months. This is what needs to happen. These are the features that have to be implemented, get on with it, and my job title is product manager. Then it probably would occur to me that my boss is not treating me as somebody who is really in charge of a product. Somebody who really manages a product or metaphorically speaking, owns a product, but he’s really treating me as a project manager maybe even as a personal assistant because, a good project manager would say, hold on a second let’s sit down and look at your requirements. Are they complete? Are they correct? Are they well formed? Are they understandable? But we first need to go through a requirements review, and that might take a little bit of time. Then we need to think about the technologies and the architecture and do a little bit of project planning here.

And then we can commit to a date and we can commit to a budget before then, I can’t tell you anything. And so if my boss comes to me and says Roman you’re the product manager, here’s a goal, here’s a list of features. Make it happen in six months time. Again, I think I’m being more treated like a personal assistant. I don’t really think it’s a respectful way to deal with product people. 

It’s easy for me to say that. And from my work, I know that’s what product people experience, fairly commonly. But I think it’s to a certain extent up to us as a product management community to stand up and say, if we are truly product managers or if we truly meant to own a product, then, we have to say no and push back.

And maybe we should consider saying to our boss, that’s a very exciting project and it sounds a great idea, but, I can’t commit to doing this job if I don’t understand more about this. And if I’m not sure that we’ve got a valid strategy in place and that, the goal we have is realistic, then it’s actionable.

And, be willing to decline that. I know that’s hard and it can be hard, and again, it’s easy for me to say oh yeah, you should just push back. It’s completely different when you are in that situation. But, it’s often related ultimately to a lack of product management maturity and a lack of understanding what product management is, and a willingness to empower product people, and a sales-driven approach.

If you jump at individual customer requests so you know, a combination of factors, but they’re organizational in nature. In a natural context, they might be classified as organizational impediments. But again, I think it’s important for product people then , to show some courage and some strength and really consider, what do I take on, what do I say yes to? And what do I reject? What do I say no to? 

Murray: Yeah saying though might mean you don’t have a job. I think that’s how lot of people are worried about when it comes to that sort of situation.

Roman: Yeah, that might be one outcome and that may be the worst outcome. And I absolutely agree. It can be a very tough decision to make. I would hope that, that’s not the only outcome and not the most likely outcome, but that it’s a conversation with the boss around, okay, what’s happening here and why has it been requested?

Has there been some analysis done into what is the impact both in terms of the value that we can create for us as a business, but as well as, the challenges and the potential stress that puts on us. And is that really something that we’re comfortable going ahead with? And am I the right person then to take on this project?

And in a way, I’m being asked to execute a project, not so much to manage a product. As the product manager, I would expect that I’m involved at a much earlier stage. And again, if it’s a commercial product, then I wouldn’t jump necessarily at the request of an individual customer unless I want to create a customized, bespoke, tailored variant of that product.

But I’d rather listen to the customer and I’d like to interact directly with the customer myself, understand what’s going on here, understand what the need is, and then see if that need is something that we can accommodate for, and then plan it in the appropriate way. It might then lead to a product roadmap change, but, I don’t want my boss to do this for me.

If my boss is experienced, then it might be a good idea that my boss supports me and mentors me or coaches me in the appropriate way. But I should be empowered to make those decisions. Otherwise I’m simply not a product manager. And I guess that’s a problem within the product management profession at this stage that, We’re product managers. We’re product people, we’re product owners. But are we ? Do we really manage our products? Do we really own our products? Do we really have the necessary decision making authority and the necessary skills? Sometimes we don’t.

Shane: A product owner or a product manager should be empowered to create value, not just take the order for the features that somebody else’s thinks is valuable.

Murray: Yep. All right. Shane, I think we might need to go to summaries. 

Shane: Yep. Sounds good. All right. So I loved the idea of the hierarchy. So that idea of a product vision or strategy board, then to roadmap, which is the promises over time or at least a guess over time, then breaking it down into the things you’re gonna build and then breaking it down into the delivery of those things. I think that’s a great way of doing it. And I’d love the way you explain the boundaries of each of those, because they can become big or little. But that was a great way of describing it for me. 

I like the way you described a product, something that created value, something that’s enduring and it’s off the shelf. I’m never comfortable using the lens of customization for a product. Mainly because if I think of, in the old days we used to be able to go to the DELL website and customize our products for ourselves, our servers but it was still off the shelf. I couldn’t go and add a component that wasn’t on that shopping cart. So it was an off-the-shelf capability and for me, that defined the product Whereas if a human’s involved, it’s bespoke, it’s a one-off, or it has not been done before, that’s more of, a service. 

And then if you’re a, product manager or a product owner, just pick whichever title you like the best. Then you are responsible for that product, you’re responsible for maximizing the value of the product. You are responsible for making sure that product delivers the goals of the organization and the goals of the customers who are going to use it. That’s your job. Your job is not to be the backlog manager. your job is not To be in Jira Ticket Hill. That’s not your job, you may do those tasks because you know you’re the best person to do them, and they add value to the team. But your job is to maximize the value of the product. It’s your product and everybody else is a stakeholder and a customer, and go make your product successful. 

So Yeah. love the canvases, and then love the hierarchy of strategy down to iteration delivery. It’s a nice set of patterns. So that was me. Murray, what do you got?

Murray: Yeah, I think Roman, you’ve made product management very simple and clear and easy to understand with your approach, which is good. So we have talked about the role of a product manager versus the product owner, projects versus products. The differences there and we’ve talked a lot about the strategy. So starting with the product vision board which is a canvas you do collaboratively and has vision, target group needs, product and business. goals. And then again, we developed the product roadmap collaboratively as well.

So we’re taking the business goals and we’re collaboratively breaking it down into product goals that are achievable in, two or three months. And if we have multiple teams working on it then we would want all of the teams to focus on the same goal. Although you can have features in a product goal, but something measurable that has an outcome. Reduce the time it takes to place an order from 12 minutes to six minutes.

And then is it time limited? It’s up to you. Stakeholders are going to expect that things be time limited, I think, on a product roadmap cause product roadmaps are usually have time going along the bottom of them. That’s almost a definition of a roadmap. So product roadmap has, for this period a goal, some features and some metrics, how you’re gonna measure success. And then that cascades down into sprint goals, which are just, how we’re gonna cut that up so we can achieve them in sprints. And it would also cascade down into features. In fact, you’re gonna have the, some high level features in your product roadmap, so that’ll help the teams. It’s all very clear and simple and straightforward. I think this would help focus the teams quite a lot on achieving that outcome. Particularly if they are delivering things into production continuously, or, at least every two weeks. Then you can actually measure whether you are achieving your goal as you go, rather than just looking at it at the end, which is a bit more of a project mentality.

Roman: Yeah, absolutely.

Murray: Yeah, I think all the things we’ve been talking about, we could go into a lot more depth. Like we really could go into a lot of depth on metrics, for instance. There’s been a lot of work done around that for different sales product metrics. I also would urge people to try and do this in more of a continuous way. I find that the continuous discovery, continuous delivery approach with, a bit more of a scrum ban approach works better from what I’ve seen.

Roman: Yeah, absolutely. It’s not a sequential linear process and the metaphor I like to use is cycling, so when you cycle the two things you have to do concurrently. One is you have to pay attention to the right here, right now. So keeping the balance pushing the cranks, pedaling, maybe changing gears. And at the same time, you have to be forward looking. If you don’t look ahead sufficiently, you’ll crash sooner or later you’ll miss a turning. You’ll overlook an obstacle and it’s gonna hurt. I’m talking here from our own experience.

We have to be in those two realms or we have to attend to those two types of work concurrently. And I think the same thing needs to happen with regards to products. We have to pay attention to delivery, and at the same time, we have to monitor the market. We have to monitor user behavior, we have to monitor the competition in order to understand if our strategy and roadmap are still valid and we have to be willing to regularly inspect and adapt them.

From an agile perspective, it’s not sufficient just to have a tactical, delivery oriented inspect and adapt cycle. You also need to establish a strategic inspect and adapt cycle. So I’m a big fan of continuous strategizing. I really think continuous discovery is a very important practice. And the two things go very nicely together. I look at strategizing as a subset of the discovery work. 

Murray: Yeah, we did recently talk about continuous discovery with Teresa Torres on the podcast. 

Shane: I’m using that one every week now. I’ve got three calls booked every week, and I’m figuring out the next question I’ve gotta ask for the next poor, unsuspecting person I talk to. And it’s working. Yeah it’s great The thing I love about things like the canvases and things about what Theresa taught is they’re simple to use. And once you find them and you use ’em, you go, why haven’t I been doing that for the last 10 years? Why did it take, me? Talk to someone on the podcast to go, oh, that just makes sense. 

Murray: Shane is building his own data product, Roman. So this is all free consulting for Shane 

Roman: Cool. I think the challenge is to put different, a approaches and techniques together and make them your own and create a cohesive, consistent hole, really. So when I look at Theresa’s work, as far as I know and understand it and say, Marty Kagan’s work, and what Rich Minoff says, I think there’s quite a bit of convergence. But then also there’s some interesting differences. For instance, Theresa is very hot on having product people together with other members of the trio to talk to users or prospective users on a weekly basis. Whereas I tend to say it’s cool if you can make that happen, but I’ve worked with a lot of big established enterprises and it’s just very difficult to do that. So I tend to say at least once a quarter, don’t go longer than three months without having talked to at least some users and selected customers, because otherwise if you just trust the data, you only have a partial picture of what’s really happening and how well the product is doing. And it may not be enough to really make the right forward facing strategic decisions.

Shane: Yeah. And just like you said with your canvas you said if there’s something in the canvas that somebody else finds that they don’t want to use, take it off the campus. If there’s something they want to add it to the canvas. So the key thing is it’s a pattern that works in a certain context, and if your context is slightly different, then change the pattern right until it works for you. Yeah.

Roman: yeah. The matter of the truth for me is, without wanting to take up too much of your time, is that product management is just a, still a fairly immature profession. And not only because it’s not as old as other professions think of sales, marketing, or engineering.

Certainly sales and engineering, but also because it’s changed so much in 10, 15 years, through the advent of agile methods and business modeling user-centered design, a number of big influences that have shaped and changed product management. And I think that combined with the growth that we’ve seen explains why generally the level of maturity isn’t that great and why there’s a certain element of confusion.

My hope is that over the next 10, 15 years, things are gonna start stabilizing and there’s gonna be more convergence and more, standardization within product management as a profession. So that when we talk about a product roadmap, we think about an outcome based, goal oriented plan.

That’s it. And we don’t have to now start arguing about, how detailed the feature should be and if there should be epic and user stories on the roadmap, which is still a conception see, hear many people voice and have. I think that’d be helpful. Or, product, either stop using that term or we get to a stage where we have a shared understanding.

Okay. That’s what it means to be a product owner. Good. Done. You don’t have to keep arguing about that because, it’s wasteful. It really is.

Murray: Yeah. All right. That’s great. Now where can people find your tools and templates?

Roman: Yeah. So the best address is my website, romanpitchler.com. So head over there and you’ll can download my templates there. You can find my blog articles there. You can see my books listed. You can find selected videos there. My podcast is on my website as well, so it’s a good starting point. And yeah, I hope you’ll find something there that is useful that you like.

Murray: All right. Thanks very much for coming on Roman.

Roman: Thank you for having me Murray and Shane, it was really nice talking to you and yeah, thanks for having me.

Murray: That was the No Nonsense Agile podcast from Murray Robinson and Shane Gibson. If you’d help to create high value digital products and services, contact Murray evolve.co. That’s evolve with a zero. Thanks for listening.