Roman Pichler

Speaker: Roman Pichler  00:15

Thank you for your questions and thank you for the votes. It seems the top two ones are, what is the best way to define what is a product? And how can you teach the organization, what is a product. And then based on your experience, what are the main challenges product owners have when it comes to stakeholder collaboration and how to solve them? How about if we start with the very first question what a product is? To me, that seems pretty fundamental. I mean, I have to say, I’ve got a product and a product management bias. But even if you don’t work primarily with product people, like I do, if you apply a framework like Scrum, there’s a product backlog. There’s a product increments, and most recently, there’s even a product goal. And of course, there’s a product owner. So, there’s a lot of product. So, it’s worthwhile to reflect on what is a product? How can we define a product? So, let’s start there. And can I share my screen? 

Speaker: Miljan Bajic  01:21

You should be able to.

Speaker: Roman Pichler  01:23

Cool, So, hopefully you can see a screen that isn’t too exciting yet. And now a slide that says, AMA, Agile Maine, now product, and I thought I’ll just use my iPad here to visualize some of the ideas that I may be mentioning. So, it’s a little bit more interesting and maybe it’s slightly easier to understand what I’m what I’m trying to communicate. So, what is a product, I like to think of a product as a…, so different people have different definitions of what a product is. But it seems to me that… [I’ll share mine.] So, for me a product is. We have a product here, a product is an asset. And in the context of digital products or software, that will be essentially a piece of code plus, possibly additional artifacts. So, we have an asset. And for these assets to qualify as a product, there has to be a group of beneficiaries. So, it has to be a group of users, or possibly customers. Users are the people who use the product and customers  are the people who pay for the product in one way or another. 

So, I’m using Microsoft Office PowerPoint here, I’m the user of the product and my business has licensed or subscribed to Microsoft Office. So, my business will be the customer, right? So I’ve got users and customers, and the product has to do a specific job for those individuals, it has to address a specific need, or it has to solve or address a problem or create a specific benefit, or in a another way to put this as it has to allow the users in this case the customers to achieve a specific goal. So there has to be a real reason for people to engage with the product to use the product and to pay for the product. So there has to be a need here. Then you could say that the value that the product creates towards those individuals, towards these users and customers. So, if I wanted to, say create a new Healthy Eating product, then I’d have to think about who would benefit from such a product. And I might decide, I’ll go for people like myself, middle aged men, who may not always have super healthy eating habits, should maybe start to consider changing their eating habits in order to avoid the risk of developing type two diabetes, and that could be the benefit. So, the benefit of using the product might be to reduce the risk of developing type two diabetes, again, it’s very important to be clear on who would use the product, particularly who would use the product and then why would people want to use it? What is the specific value that the product creates for those individuals? But that’s not enough, there has to be something else. For an asset to qualify as a product, it has to also create value towards the business. 

And this is meant to be some form of building here. The business or the company, maybe I should have drawn a group of people because really, businesses and companies are a collection of people, of individuals, right? So here, we also need to ensure that the product creates a specific value towards the business. And that might be, for instance, to open up a new revenue stream or to achieve a certain amount or generate a certain amount of revenue within a certain timeframe. Well, you could think about other benefits, such as achieving a profit target, probably for more established older product, or reducing cost, increasing productivity, developing the brand, or helping market and selling other product. So that’ll then depend on what kind of product it is, is it a product that directly generates revenue, then you typically have things like revenue or monthly recurring revenue and profit as key, business goals. So that’s what I should write here… On the right-hand side business goals.

Speaker: Miljan Bajic  05:53

How much do you see… and this is just to build off on the value, what I see is, a lot of times I talked to product owners, and they don’t even know what value is, they don’t know how to define it, they don’t know how to explain it. A lot of times they say, return on investment. So, could you maybe just quickly elaborate on how to help product owners define value for a product? Because I see a lot of product owners and even companies struggling to explain that.

Speaker: Roman Pichler  06:21

Yeah, sure. So, the value should really answer the why question, why is it worthwhile for people to use the product or pay for the product in one way or another? What’s in it for those individuals? And why would your business, why would the company invest in the product? Is it to generate revenue? Is it to support another product or service? Or is it to maybe reduce cost as in the case of a traditional IT product or traditional IT app? And so, the formula that I like to suggest to define what a product is, is the product has to do a good job for the users and possibly the customers, and it has to generate some tangible business value. Now, if you’re interested in some form of the tool, to capture those key pieces of information, you can take a look at my… if I can only find it. Hopefully, it’s not going to take too long, at my product vision board. I don’t know if anybody of you has worked with it. I’ve written too many book posts, I think. Oh, come on. Yeah, this one will do. So, okay, that’s a sampled one. So here you go.  So, you can use this little structure here, it’s just one way to capture the needs and the business goals. And, you have the vision at the top, which is the positive change that the production created a purpose of a product. And then you have the target group, those are the beneficiaries, the customers and users the needs, again, focusing on the main problem, or the main benefit, or the main job, the primary job that the production do for the users.

And then the product itself, and it’s a key feature that make it stand out, make it special in one way or another. And then the business goals. So that can be a helpful template, a helpful structure to clarify your thoughts and describe the product and describe the beneficiaries and the value it creates. And the trick here is the key point is really to be specific. And if I say, well, my healthy eating product should help people eat more healthily, which is like, well, I’ve just restated the vision. That’s not specific enough, it has to be so specific that I can test, that I can find out if that benefit is truly desirable or if that problem really is significant enough so that people do want to have it addressed. Similarly, with the business goals, they have to be specific as well. 

It can be nice to try and make them measurable, but at least they have to be specific. And so, in addition to being able to validate my ideas, I’m also in a position to choose the right metrics or KPIs key performance indicators, and measure how much value my product creates. But again, for me, it really starts with saying, who are the beneficiaries, the users and customers? What Problem does my product solve for those individuals? Which benefit does it create? What is the value? What are the benefits that my product offers to the business? Yeah. It’s a worthwhile exercise, particularly as products change over the life products grow, if they’re successful. And then sometimes what happens is that they grow so big that it’s time to break them up. 

Think of those of you who are OS Mac users, Apple users, Apple… fairly recently, I think that was 2019 Finally, unbundled the iTunes app that had grown so much over the years from essentially the ability to purchase digital music online and then download it onto an iPod to all sorts of things, managing videos and reading Apple books and administering your iPhone, and it’s just grew so big. And then finally Apple spun off three or divided it into three new products. I think TV, podcasts and music. So, in that case, you have a product that has changed, that has been split into three, and sometimes companies do unbundle knot… so I’ll leave it there.

Speaker: Miljan Bajic  10:39

Yeah, no, I think it’s great. And Roman, you and I talked about timeboxing these, and it’s been roughly about 10 minutes. So, do you want me just to remind you, or probably I don’t want to rush through these, but…

Speaker: Roman Pichler  10:50

Cool. So, I hope that was useful. Now, the next question, I think was about, oh! I’m looking at the wrong screen. The next question was about main challenges product owners have when it comes to stakeholder collaboration, and how can you solve them? So I think in an Agile context, we’d really like to encourage stakeholders, and by stakeholders… my understanding of stakeholders is that these will be people from within the business, so, for commercial revenue generating product, a stakeholder might be somebody from marketing, it might be a sales rep, it might be somebody from supports, possibly operations, or maybe finance depending on the type of product that we have. So obviously, in an Agile context, we’d like to encourage close collaboration. 

Now, if that’s what we’d like to do, and then the question is, and I think for product owner, that is, okay. Yeah. We’d like to encourage close collaboration and the question is, how can we achieve this? And what can go wrong? And so, for me one of the key gradients in order to enable effective collaboration is to build trust. So, for me if I think of collaboration, I think about trust, if there is not sufficient trust, then it’s hard to collaborate, right? So if I don’t trust another person, if I don’t have faith in the other person, if I don’t believe that the other person watches out for me, or at least doesn’t want to cause me any harm or disadvantage, then it’s difficult to be open, it’s difficult to trust the other person, it’s difficult to speak my mind. And it’s difficult to… in a way, be willing to rely on the other person, open up to the individual. So, whenever you experience any collaboration issues, my first question would be, is there a trust issue? And if it is a trust issue… if there is some form of trust, that’s lacking? Then the follow up question will be, how can we build that trust, and so there a number of things you can do in order to build trust, [just looking for a nice color to use.] The first one is to get to know people. And I think that’s very worthwhile, particularly for product owners, who have just started to work with a group of stakeholders to get to know the individuals and make time for them. And we’re all influenced by our backgrounds, and by our personal situation, our family situation. 

So, it’s interesting to learn about people find out about people because that sometimes explains a behavior that people that people show you. I remember being in a meeting a while back, and one of the attendees just was just going off on tangents all the time. And I thought it was extremely difficult meeting and I was getting increasingly impatient in a way, agitated and frustrated and didn’t quite know what to do. And only afterwards, I found out that the person was going through a particularly difficult stage in her divorce. And, that allowed me then to empathize with her and I felt a little bit guilty for having unkind thoughts about her being like, “oh, man, you know, just wish she shut up. Can we just get over things?”

Speaker: Miljan Bajic  14:50

It’s really about that empathy. We talk, especially in product ownership. I know you’ve talked about it. It’s empathizing and trying to look through other people’s eyes and see what’s going on versus just…

Speaker: Roman Pichler  15:02

 Thank you. So, I think it’s easier to empathize with people, if we get to know people a little bit, it’s easier then to understand people, right. And in order to be able to empathize and get to know people, it’s good to listen, listen attentively and listen with an open mind. And even if a stakeholder makes a suggestion, or requests a feature piece of functionality, which we disagree with, then I think it’s still worthwhile listening attentively, or trying to listen attentively. And being open minded, at least initially not judging too quickly, because first of all, maybe the feature really is a good idea. And we’re just biased and think, oh, no, it can’t be. But after a little bit of consideration, we discover Yes, we should definitely take on board that feature and get it implemented as soon as we can. But even if that’s not the case, then by attentively listening to somebody, we show the person that we care, that we value the person’s perspective and contribution, and that builds trust. So those are…

Speaker: Miljan Bajic  16:15

What about your tools, for instance, I’ve used the gold roadmap and other things that you do, to help in that collaboration.  A lot of this is soft skills, I found a lot of times using some…, other tools, like story mapping, but some of your tools that you’ve shared with the community, those are really good to communicate and collaborate with the stakeholders. So, I don’t know if you want to highlight some of those and how you have used those to help with collaboration with the stakeholders.

Speaker: Roman Pichler  16:46

Thank you, thanks for suggesting that. So, I’m jotting down joint decision making and planning. I think that’s another great way to very practically collaborate with stakeholders and users, and the number of tools you can apply. I mean, it starts with coming up with a shared product, vision and strategy, so you can use the product vision board, structure that I showed you earlier, if you’d like to. And I’m a big fan of translating a higher-level vision into a more tangible product roadmap. And I like to work with outcome based or goal-oriented product roadmaps that contain product goals. 

I think we’ve got a question about product goals and I’m not sure how high up it is here in this fight, how many votes it attracted. But the idea with a protocol is… well, at least that’s my interpretation, it’s a specific measurable benefit or outcome that product should create. And I like to suggest sort of in the next three months or so, and so having a shared vision, having a shared strategy, and having a product roadmap that describes how the product is likely to develop and grow. [Let me just quickly see if I can find a sample product roadmap so I can visualize what I’m talking about. Scroll down a little bit again.] So here is a template, again, one of those little templates that I’ve created over the years, that you might want to consider using. And as you can see, the goal is here in the middle. And that’s the desired outcome that should be achieved. And so, a great way to collaborate with the stakeholders is to agree on specific measurable benefits, product goals, outcomes that your product should create over the next 12 months. 

And that can then really help align people, it can help people work together, you don’t want to be in a situation where the stakeholders go off and everybody does her or his own thing. They do their own thing. And then, the marketing strategy in the marketing collateral doesn’t fit and the sales collateral, and the sales strategy doesn’t fit and so forth. And the training material that was created for the service guys doesn’t fit because everybody was doing their own thing, right? So, we need integration, we need an alignment, but at the same time, we want to enable people to work autonomously, as product owners, we don’t have the time. And often we don’t have the expertise to essentially tell people what to do or babysit people. We’ve got a job to do ourselves. So, for me working with those types of goals, strikes the balance and it achieves that alignment and at the same time, the necessary level of autonomy. Yeah. So, having the…

Speaker: Miljan Bajic  19:54

It’s also level I think, one of the things that I’ve seen in the feedback that I’ve gotten from stakeholders is that… especially with the roadmap, product roadmap is that it’s at the right level for the stakeholders, a lot of times, and it’s easy to communicate, and it’s easy for them to see as it evolves and changes. So…

Speaker: Roman Pichler  20:15

That’s great to hear, thank you for sharing. So, from the product backlog is just a little bit too detailed. And the rate of change can be too high for stakeholders to truly understanding and work with it. So that’s why I think it can be really helpful to complement it with a product roadmap. And I mean, if you want to work with product goals, and in the latest version of the Scrum Guide has introduced the concept of a product goals, then you can put your product goals on the product roadmap, and then just simply copy them into your backlog. So, I find that quite handy. So, workshops, joint decision making, planning, and I should maybe also say, review meetings. And that can be really powerful. 

Speaker: Miljan Bajic  21:03

 How about we move? It’s been another 10 minutes. And I think it’ll be good to maybe shift to the third, that one had seven votes, unique quotes. And the question is, would you recommend breaking out Agile teams into support and new development?

Speaker: Roman Pichler  21:22

Generally speaking, no. Unless these teams are virtual teams, in the following sense. And there is a…, [I think I’ve got an article about this somewhere. So, I’ll see if I can find it quickly, because it has a picture that I’d like to show. We’ll see. Actually, that’s probably under a different category.]

Speaker: Miljan Bajic  21:54

Maybe while you’re looking for that, in a lot of times what I’ve seen, it’s like creating a JV team, support team and new development, your varsity team, what we call it here. And there are some pros and are some challenges, but I agree with you, it’s much better if it’s jointed, so it looks like you have your stuff. So…

Speaker: Roman Pichler  22:19

That’s right. So, the drawback of working with as a separate in a way development team and support team is that… in my experience, it can create a two-class society in the sense that, nobody really wants to be on the support team and do the more difficult bug fixing, maintenance tasks. Everybody would like to be on the feature team, where you get to implement cool new functionality, and it’s exciting and interesting. And I’ve also experienced that the setup can lead people who develop new functionality to have a slightly sloppy approach when it comes software quality, because, they don’t have to fix the box, somebody else will sort out the issues. And that can then lead to software that isn’t as good as it could and should be. So the picture here suggests that, if you have a lot of technical debt, or you have a lot of bugs, you have a lot of maintenance work, then one way to deal with it, rather than having separate teams is that you still have one team or a number of teams who look after a product. 

But then teams have volunteers and two or three people per sprint from each team volunteer, to do the maintenance work, to do to support work, to do the bug fixing work. And then in at the end of the sprint, new people volunteer. And so that way the majority of the people can focus on enhancing features or developing new features. And not disturbed by having to do support maintenance, bug fixing work. And so, you have dedicated people who can take this on, but you avoid the drawbacks that I mentioned earlier, the loss of kind of accountability for substandard software. And also, the being stuck on a team and doing work that I don’t really find particularly motivating and interesting. Yeah. So maybe something to consider.

Speaker: Miljan Bajic  24:37

Great! I’m thinking about jumping one ahead, and then we’ll come back to the other one. This one comes up a lot. What’s the difference in Agile between a product owner and a product manager? Should always be one person. This question comes a lot in my classes, too. And I think it would be good if we could hear your opinion then this.

Speaker: Roman Pichler  25:01

Yeah, sure. So, when I started working in a way properly with Agile practices, the people who I was working with were product managers. And then when I introduced Scrum for the first time, again, the people who would act as product owners were mainly product managers. So, for me, I’ve always looked at a product owner in Scrum, the Scrum Product Owner is essentially, the Agile product manager. And I find it interesting that when you look at the scrum history, before Ken Schreiber, who mainly coined the Scrum terms, choice to term product owner, he actually used the term Product Manager for the role. Now, some people may say, Well, come on, why did he then change his mind, but I think one of the reasons for calling the Product Manager, Product owner is that, particularly in an Agile context where there is so much collaboration, but we value collaboration, we talked about collaboration earlier, right. And we’d like to encourage collaboration, we’d like to involve the stakeholders and the development team members in the decision-making process. So, we’ve got all these collaborations going on, where you we have to make sure that if people can’t agree, if people can’t reach consensus within a realistic timeframe, there’s a person who can make a decision and move the process forward and progress the product. 

Now that person in Scrum is called the Product Owner. So maybe one way to continue the discussion is to look at this little picture here. So, what you see is a simplified version of my cones planning onions. So, I’ve simply distinguished between vision, strategy and tactics vision as the purpose of our product strategy is how do we get there. That’s the general path that we’ve chosen tactics, then are the specific steps along the path, you can think of the user stories and epics or the good stuff in the product backlog. Now, in Scrum, that’s my perspective, a Scrum Product Owner has full stack ownership, and should own the product in its entirety. For me, the Scrum Product Owner is very much an Agile product manager. However, other Agile frameworks have a different perspective on this. So, if you look at Safe, there’s also a product owner, but in Safe the product owner, and that’s my understanding of the role is mainly a tactical role. So, a Safe product owner would work with one or more development teams and take responsibility, take charge of part of the product backlog, I think in Safe it’s called a team backlog. 

So, it’s more a tactical person, more of an inward focused person or role, I should say. It has partial ownership of the product. And then there is a Safe product manager who owns the strategic part and make strategic decisions and is more outward facing and understand the market and the market trends and measure the product performance using KPIs and review the strategy and maybe work with a product roadmap, if that is appropriate. So essentially, what the scaling framework has done in order to facilitate scaling is, it has taken the Scrum Product Owner role and split it into two roles. Now, that’s one way how you can scale and, certain circumstances that can make a lot of sense, particularly when your product has reached a certain stability and the strategy isn’t too volatile. So typically, that’s the case in maturity and decline if you’re familiar with the product lifecycle model. But what it has done is, it has created even more confusion in the community and generally, in businesses what it means to be a product owner.

Speaker: Miljan Bajic  29:01

… authority level, for instance, what I see is… what you’ve shown here, Safe Product Manager, which again, I’m not a big fan of safe, but you also see an another is just named differently, like Chief Product Owner and then product proponent down below, but it really has to do with authority level, right?

Speaker: Roman Pichler  29:19

It has to do with the decision making. Maybe, some of you’ve seen this little diagram here that I created a while back. And so, the idea really is just to illustrate different types of ownership. So that’s why it’s called six types of owners or Scrum Product Owner owns the product. And then if a person looks after product capability and major features, say the ability to… you go to an online retailer’s website like Amazon, the ability to look for a product on the Amazon web page for me is a feature or component, somebody who looks after payment. The payment system, there will be a component owner. That’s at least the terms that I like to use. We have the Safe product owner who takes care of the tactical decisions for a given product. And then, we have two products here, they may use similar services. 

So, we may want to take them out and encapsulate them, extract them into a platform. And then we have a platform owner in platform owners, like a Scrum Product Owner only looks after an internal technical product, right? Now we have a little portfolio and sometimes it makes sense then to have a product portfolio owner. And as we’ve just heard, all these owners, they have ownership, but to a different level. So, their level of decision-making authority in their responsibility and accountability will vary. So, product portfolio owners’ job is to maximize the value of a group of products. A good example of a product portfolio might be Microsoft Office, with PowerPoint, word and Excel is the traditional members, job of a Scrum Product owners to maximize the value of the product, job of a feature owner is to maximize the value of the feature, I think it’s just important to be clear on, if you have a product role, what is your responsibility? And what is your decision-making authority. 

And I generally tend to recommend to my clients to either choose the term product owner or product manager, I find that it can create a lot of confusion and organization uses both uses both terms. I’ve worked with businesses where the product managers were desperate to become these hip, new, trendy Agile product owners, when I’ve worked with companies where the product owners, they couldn’t wait to become product managers and grow up and finally make important product decisions. And that was seen as a positive career move. So, it can create quite a lot of division. And in I think that’s not that’s not desirable. So, my suggestion, again, is use either product manager, product owner. And then maybe you have a feature manager or feature owner, for instance, if you want to follow my model here, when you can have senior and junior product people, senior and junior product owners or product managers. But again, I think that just limits the confusion, at least a certain extent.

Speaker: Miljan Bajic  32:19

And someone’s like, depends on your organizational governance design structure. So that’s going to influence a lot. How about, let’s move on, we have about maybe 20 minutes left, just a little shy of that if we move to the next question, which I also think is something that’s pretty common, and I hear often, how can I get my team to write stories instead of relying on me or another person as their scribe?

Speaker: Roman Pichler  32:50

That’s a great question. And so, for me, the trick is a to a certain extent, empower your team to take that ownership into… [you won’t believe it, there’s another picture that I have that I’d like to show you quickly. Quick is relative, you here we go.] So, I sometimes find that product owners and product people think they have to feed their development teams with detailed user stories or requirements, essentially, forever. And while sometimes that’s true, when you work with a new development team, a team where people don’t have much knowledge about the market, the domain, the users, the product competitors, that will benefit from detailed requirements. 

And same thing is true when people haven’t worked with Agile practices. And people are more used to the traditional setting, where you use a well a traditional detailed requirements specification. So then people will ask for those detailed user stories, those detailed requirements, and initially that can make sense to create them. But if you do that, I’d suggest that you create them together. So, product backlog, refinement, product backlog work, should be a joint responsibility. So here on this diagram, it’s written between the product owner and the development team. And that you actively transfer knowledge from yourself as the product owner, you try to actively transfer knowledge into the development team, and try and educate people about the market, the domain, the users and customers and so forth. One way to do this is to take some of the people along when you carry out some form of user research. So, when you interview people when you observe people, when you talk to customers and users, be it current customers and users or prospective customers and users, another way to do this is to make sure that the development team members are present when a sprint review takes place. 

So, they can directly hear, at least from selected users and customers, depending on the solution validation technique that you use, about how well the product works for them, and listen to the feedback. So, it’s about actively transferring that knowledge, which, in the short term may be more work. But in the long term, should enable the development team to become more self-sufficient, and take on the job of at least writing detail user stories. So not to just suggesting this, that as a product owner, as the person in charge of the product, you should not be involved in the product backlog work. But I don’t think that you necessarily have write every single, detailed user story and you don’t necessarily have to forever detail the user stories or create super detailed and specked out user stories. In fact, that was never the intention with user stories, the user, the intention with the user stories was that they would essentially capture the conversation or the essence of a conversation. So, it’s really about developing a shared understanding, it’s really about the communication piece.

Speaker: Miljan Bajic  36:14

A lot of people, if we just go back a little bit, a lot of people, you mentioned customers and users. And a lot of times people don’t fully know the difference between customers and users. And I have my own way of explaining. But I’d be interested to see how do you typically explain what’s the difference between a customer and a user?

Speaker: Roman Pichler  36:34

So, I think I touched upon it. Earlier, when we talked about what is a product user is somebody who uses the product, employs it’s. I was using Microsoft Office just a minute ago, Microsoft PowerPoint, I’m the user and then customer is the person who pays for the product in one way or another. So, the example I gave earlier is that my business has subscribed to Microsoft Office. So, my business will be the customer. And sometimes customers have different perspectives and needs and ideas from users and vice versa.

Speaker: Miljan Bajic  37:05

And sometimes one can become another, the example that I use if I’m buying a bike for my four-year-old son, who’s the customer, who’s the user? His son is the customer, I’m the user.

Speaker: Roman Pichler  37:21

Unless you decide to give it a go and you will see if it’s a..

Speaker: Miljan Bajic  37:24

Sorry, it’s the other way around, right? Yeah. So, my son is the user, I’m the customer but if I’m buying a bike for myself, I’m both customer and user and my wife is the stakeholder. So that’s another way you can look at how things… a user sometimes is both customer and user, and sometimes it’s different, so…

Speaker: Roman Pichler  37:51

So, try and really transfer that knowledge into the team and enable the team. And at the same time, I think you should also be able to expect that your team is willing to support you, and certainly support you in identifying and capturing user stories that should be a truly joined responsibility if and it should be truly, a form of teamwork. And if that’s not the case, then I would suggest that you talk about it in one of the upcoming retrospectives. And also, maybe secure the necessary support from your scrum master or Agile coach.

Speaker: Miljan Bajic  38:30

 So, here’s an idea Roman, I’ve done this in the past, but we have 10 minutes. And a lot of times people have these questions. So, if we limit it to 30 seconds, quick Roman’s responses to these Would you be open maybe instead of diving deeper into one just going broader? And answering some of these? So just pick and choose some of these questions in 30 seconds or less, just maybe give us some answers. But I think given that there were a lot of votes, at least those individuals that wanted to and this is probably one of the few opportunities that they will get a chance to get your opinion on it. Just give them a quick answer. Maybe you can for some of these.

Speaker: Roman Pichler  39:12

So, we’ve got a question around, Publications and organization are defined as products. Hopefully, that’s been addressed by the discussion we had earlier around, what is a product? If not, then the test for if something is a product is? First of all, it has to serve a specific group of people. So, you have to say, what is the value of create? What is the problem it solves? So, the benefit it creates? And who are those individuals? And at the same time, you have to say, Okay, what is the value that my product largely on its own independently creates for my business? If you can answer those questions, then most likely you have a product or the asset or in this case, the app is a product. So that’s something you may want to do and always look from the outside in avoids the mistake of saying, we have the systems in place, therefore, each system has to be a product and think about trying to look at your system landscape from a user perspective and see how users interact with the various assets and look at the user journeys in order to identify products. And then, what does a good product goal look like? How is it different than then a strategic intent? So, a product goal, again, I briefly touched upon it earlier, I would consider a good effective product goal to be specific and measurable. And a goal that describes the benefit or outcome. So, if I wanted to create a healthy eating product, then a good product goal for the very first release the MVP might be to help people become more aware of their eating habits, and at the same time, acquire an initial user base. So, something that you might be able to achieve, say in the next three months, sometimes that timeframe is too long, and then you maybe shoot for six weeks or eight weeks, sometimes three months is maybe too aggressive. And you need more timeframe of four to six months, but somewhere within that, that sort of scale… that’s usually an effective product goal. What’s next? Do you have any tips on how to add effective acceptance criteria during sprint planning? Yes, I have don’t do it. So separate product backlog work from the sprint planning. 

So, make sure that you refine and work on your product backlog before you move into the sprint planning meeting. Otherwise, your sprint planning meeting becomes very strenuous, it’s likely to be overloaded, and the quality of the backlog work you do might be sub optimal, so make sure you invest in a product backlog refinement when doing the engine behind the scenes that drives the product, how to do it in smaller releasable chunks. Now, I’m not quite sure what the engine here is. But, I suspect it might be something like a platform, like a software platform that encapsulates shared services or shared components. If that’s what it is, then I would suggest you best start by addressing the needs of a small number of products. And by forming a team, or in closely involving the teams that build the software, that sits on top of the platform or the engine to make sure that the engine or platform really does a good job for those teams, because the users of that engine or that platform will be the development team members. And otherwise, you can pretty much… assuming that the engine or platform is managed as a product, you can pretty much use all standard product management techniques to do that. And there’s an article I wrote I think about a year ago about software platforms maybe refer to that and check it out. 

And we are doing Agile so wrong. How do we get to convincing management to go the route of continuous discovery and building features that are of value rather than saying yes to every feature that our customer wants? Sometimes that has to do by actually moving away from a building, tailored, custom, bespoke products to well, essentially, commercial products. I’ve certainly seen companies struggle with that. So, if you currently earn your money by running, essentially projects and doing bespoke custom work for individual clients, then you’d really have to change the way the business is set up and operates. Otherwise, it might be an empowerment issue, establishing effective, empowered, qualified, knowledgeable, professional product people, product owners. And the thing that you can do to help with this is that you first of all, build trust with the stakeholders, as discussed earlier. And secondly, that you increase your expertise, the more expertise you have, the more likely people are to trust you and listen to you. Do you know any good practices, how project managers could cooperate with product owners? Well, so if we’re talking about Scrum Product owners, and if you’ve set up Scrum in the right way, and you’ve filled the Scrum roles with the right people, you don’t need project managers. And you may you may have noticed that certainly in Scrum, the term project isn’t really used. It’s all about product. It’s all about organizing around products, and it’s all about then developing and progressing and enhancing products. So, project managers typically face a choice, they can become team members, they can become Scrum Masters or product owners, but in all those cases, their role will change significantly. So, it’s something to be aware of, I think. Alternatively, if you currently have project managers who perform program management, some of those individuals might make good product portfolio managers, as I briefly showed in one of the one of the pictures I shared with you, then we have should every feature requests go through design sprints? No. So a design sprint, as the name says, that’s at least my understanding, is really there to figure out what is the right user experience design approach for… either brand new product or product that is being significantly enhanced or changed. So, it can be very useful then to spend a week and well going through that, design, Sprint, but certainly not for every single feature. 

So that’d be really again, for brand new product, or for a major change when you take your product to a new market or market segment, for instance. And then the final one I can see here is having trouble getting value… Having trouble getting value info from the business making it difficult to prioritize using COD, are any of the matrix approaches valuable, or are they anti patterns. So I think whenever you are the product owner, you have to really understand the value that your product should create for the business, I wouldn’t expect that any of the business stakeholders have to tell you, it’s really something that you need to know and you have to take responsibility of the products, ability to create value towards the users and towards the business. And then you have to think about, how you can ensure that you maximize that value and that the desired value is created. Again, as I briefly hinted at earlier, the model that I like to use is by starting out with a product strategy, and then test out that strategy, validate that strategy translated into a product roadmap, and then derive a product backlog from that product roadmap via a product goal, or one of the product goals. That’s on the product roadmap. If that is useful to you, it’s probably something that you need to look into in a little bit more detail if you’re interested in possibly experiment with…

Speaker: Miljan Bajic  47:16

Maybe one last question, Roman as we’re here. It’s the second one here, and I haven’t voted and I would vote for this one. I’m currently writing a book. Do you have any advice I should consider to get it done and published? I’m actually writing a book as well. So. I’m interested, as well in this question. So maybe you can just quickly for me, and this other person just answered that question. You’ve written three books for how many…So any advice for us inspiring writers?

Speaker: Roman Pichler  47:55

Well, I’d look at a book as a product, a product in its own right. So, be clear on who is the target audience? Who are the readers and be clear on why people would want to use the product and be clear on why you write that product? What is the benefit that you want to get out of that product? And depending on the benefit that you want to achieve by offering this product by writing this product, think about which route you want to go down, is it self-publication or working with an established publisher, if you’re a first time author, and you want to write a book to establish your name, or to grow your reputation, to grow your brand, it can be beneficial to work with an established publisher. Well, if that’s less the case, if you feel that won’t necessarily be very beneficial for you then go down the route of self-publication, it just means that you have a little bit more work because you’ll have to then take care of the… you’ll have to find development editors, if you need any, you have to hire copy editors, you have to work with designer artists for the cover, but also for any graphics that you use. And so, you have that production part that an established publisher would take her off. 

And then what the final thing I’d say, again, that’s related to the value that your product to create and how big or focused the audience, the group of readers are likely to be. I have a preference to write and to read, I have to say fairly focused books. So, I mean, if you think about writing a book on agile, then I’d say, well, maybe there’s a specific topic within the big Agile realm that is interesting. Even if you say I’d like to write a book about product ownership, I’d say like, that’s still so big. Maybe write the book about, product backlog, or even specific product backlog management aspects. You could write a book on prioritization, and as always as any product development effort, it’s a balance between having a product that is too focused or your market is too small and it’s no longer attractive and appealing. And a book that is too big and a product that is too bloated and does too many things for too many people and then really doesn’t offer a compelling value proposition.