 How's everybody? Okay, on a scale of one to ten, how likely are you to recommend the Agile India conference to a friend? So The ten is I'm gonna tell the whole world one is I'm gonna tell them don't bother So how many one? two three four five six seven eight nine Ten Slightly more promoters than detractors. That was a very very rapid net promoter score Which is one of the metrics that can be really useful When you're trying to get real feedback from real-world customers I would encourage you we're not going to talk about NPS net promoter score much more than that now But I would encourage you if you are Responsible for products in any way you really need to understand how your customers feel About your products and NPS net promoter score is one of the metrics that does actually matter All right product ownership I suppose I've got a fundamental premise and I must nail my colors to the mast. I don't think I'm going to be as controversial as the opening talk, but I believe that the way product ownership is typically spoken about in the agile community and especially is as it is described in the scrum guide is Broken and wrong it does not work So that is the the premise of this talk That's me I Don't want to go through who I am where I am terribly much Except I am a grandfather now, and I've got seven grandchildren, and that's much more fun than than pretty much anything else that I do in my life those of you who are Parents and you take your children to their grandparents to visit occasionally I I'm gonna let you in on a secret, you know when we fill them full of sugar and do all of the things that you don't want us to do It's deliberate and then we send them back. It's Revenge at one or other level It's also having fun with them so our focus for the session and It is branded as a workshop Workshop is a collaborative activity in which a group of people work together We are going to collaborate. We are going to work together. And yes, I'll give you time for silent reflection, too We're gonna look at the product owner role. We're going to look at the Impact of different project or initiative types on that We'll look at the product ownership team We'll focus on value and then we'll have some time looking at some of the tools and techniques that are available to support product ownership and Then we'll wrap things up. We have we have 90 minutes. We're just short of 90 minutes now and I'd like this to be an interactive session. I don't particularly like a monologue So let's have the conversation and it's okay if you disagree Just because Shane said it doesn't mean it's right Let's explore. Let's examine. Let's delve into these topics so here is the official definition From the scrum guide of the product owner role The product owner is responsible for maximizing the value of the product and the work of the development team How this is done may vary widely across organizations scrum teams and individuals and This is the part that worries me The product owner is the sole person responsible for managing the product backlog I in any reasonably significant product I Do not believe that a single individual Has sufficient mental capacity to do that effectively That is my premise what I'd like you to do now is In whatever groups you want to form for five minutes talk about and Make some notes. There's paper on the tables. There's flip charts. You there's the the little pads if you want I've got some post-it notes up here as well. What I'd like you to do is Just make a short list of the things that you have seen Where product ownership hasn't worked well What are some of the the the anti-pattern some of the challenges of product ownership and also some of the Ways in which you have seen it work. Well Does that make sense? So please self-organize into groups of about seven to ten people and Have that conversation We'll make it ten minutes Now I'd like you to summarize So what are what are some of the things that you came up with in your groups lack of long-term vision? What else lack of domain knowledge? So no technical knowledge or lack of anything else so Conflict between and that's that's around interdependencies. So a disconnect between the remote Multiple working on multiple products. Is that domain knowledge or is it beyond that context? Roll dilution Another term for that is the flaccid product owner who can never make decisions themselves. They've always got to go and ask Mary able to He's not ready Ready using the definition of ready Yeah, okay, so Too much technical involvement They're the wrong product. I'm not understanding the competitive environment. They're losing the big picture vision shiny objects The frequently change the frequent priority changes, but isn't that what agile is all about I want to change my mind I'm agile Metrics, and I'm gonna call a halt there just because I've run out of space. So we we are Constrained that kind of sounds to me like my premise might be right one of the challenges that I really struggle with is Can one person Have that beautiful long-term vision the domain knowledge in the context the technical knowledge Be able to mitigate conflict be local and remote work on multiple products at once Be able to prioritize efficiently get for stories ready without macro managing talk to the right stakeholders Understand what the competition is doing Again, have the big picture and avoid the shiny object syndrome. I don't think that's feasible for a single individual There's just too much going on cognitively. There is just too much going on Even if this is somebody who is one of Nuretia's magic multi-taskers one of the the challenges of I think we face in Agile and in software engineering in general is That we don't have simple empirical solutions Every environment is different Every context is different. Yes. There are things that We've found seem to work in many different environments and contexts But there it truly is no one-size-fits-all And I feel that this applies to the product to product ownership as much as it applies to every other aspect of the work that we're doing I think they all apply to developers. Yeah, we need to have that clarity of understanding To people work there everyone on the team So one way is just make everyone product owners, right? Once that's one possible approach. I'll tackle that one a little bit But you're right. I think we all we need and for me an aspect of product ownership That is incredibly important is conveying these messages So that there is a clear vision and a clear understanding But I'll talk about some ideas that I have about how we get there now if you are working in What Janita Andrea called the Cinderella project and she wrote about this back in 2005 then Agile any one of your agile brands as it is described in the scrum guide or the XP book or Jim Heismas adaptive software development any one of them you can pretty much apply Or crystal clear from Alistair Coburn if you've got this small co-located skill team Six to seven six to eight people with generic skills with an engaged customer right at your beck and call They're sitting in there with you absolutely clear with the terms of reference a short duration Probably web based web based user centric type systems that that dedicated On-site customer or subject matter expert with clarity of project vision and dedicated team members You put those people in a room and you tell them figure out how to work and how to solve this problem Don't give them any process whatsoever Because they will solve the problem Anyone worked on one of these I Have once it was great fun We had the customer engage. We were doing releases and this was back in 1986. We were doing releases to production every seven hours about We would make a change deploy make a change deploy. There was no Change control or anything like that. The customer was literally sitting next to me as we were building this product there were five of us on the team and We had that that beautiful environment, but of everyone in the room. There were three of us that have once worked on a project like that your project small co-located team 270 people in five time zones Generic skills. No, no, no, we got front-end developers and cobalt developers and back-end developers and middleware developers and UI experts and Expert engaged customer at your beck and call nine time zones away Clear terms of reference we want to build something maybe sometime Short duration know this thing is gonna go to the rich 520 sprints 10 years web-based user centric most of the Interesting stuff today is being done in the API economy Dedicated on-site customer. Maybe not Clear project vision. How many of you work in teams where you have dedicated team members not shared with other project? 20% the reality is our environments today are more complex more difficult then honestly, what was being worked on in The late 90s when the agile manifesto ideas were being distilled In the 2000 early 2000s when they when they came out when when Alistair was writing about crystal clear when when Kent was Writing about XP. They were talking about a lot of those trap projects. Yes They were starting to deal with bigger things Today we have Scaling in all of its various forms and tomorrow is all about scaling I believe at this conference and we've got the the various scaled vendors around the outside there So things are perhaps a little bit more difficult a little bit more challenging Philippe Christian provides a View that helps us look at our initiatives and say okay What are the elements of complexity that we need to take into account? He calls it the octopus model. It's got eight components and These eight things are size. Well, I don't care what you measure it by We know the difference between big and small the level of Criticality how much do we care if this thing doesn't work properly? Do we kill people or? In the case of some systems. Do we kill many people all at once? The traffic management systems air traffic control systems or is it We lose some money or do we lose a lot of money or do we get slightly embarrassed or? Do we misspell something on a website? What's our business model is an organization? Are we selling? products is Software something that we do to support other parts of the business Are we an outsourced provider? offering services for other companies Because the way we're going to work and communicate is going to get a very How stable is the architecture of this product? We're working on Has it been around since? 1964 in the case of one product I worked on and it's got at that stage 35 years of technical debt waiting or What how distributed is your team are you the six person team co-located or you're spread over nine times that What's your governance model? Are you a a bank or a financial institution? Are you part of a government department? where you've got to have auditable Controls and and be able to prove that all decisions were carefully thought forth through or are we the much more Loosely governed and more trusted organization. What's the rate of change? Are we a telecoms industry where the average duration of a product in the marketplace is seven days? Or are we one of the human resource type organizations where? Processes change at a rate. I don't know about once every hundred and fifty years What's the age of that underlying system these are all factors that you need to consider when you look at How are you going to choose to work together when we look at our pen? that the absolute breadth of choices in the agile brands and the over 70 different practices that fall under the broad agile umbrella some of those practices You're going to be able to apply others. You're not you're going to have to look at Now if you've got a distributed team in nine time zones of 250 people you can't have a daily stand-up With that team you might have Smaller daily stand-ups now up until September last year I wouldn't I didn't believe you could have a daily stand-up with more than 10 people rich proved me wrong I went and visited me alone. I've seen those 70 person stand-up stand-up work Which was stunning. I'm still in shock. I Participate it. Yep. You got a men log. You got no choice. They suck you in So We've got to think about the approaches that we're going to take and these are some of the factors to consider But we've got to consider what is product ownership There's a product management component Now sometimes that product management component goes right the way to the to having Responsibility for profit and loss from this product Return on investment and value There's a marketing aspect to the role there's business advocacy customer advocacy and and Rich's lost tribe the end user advocacy We've got to have domain subject matter knowledge We need analysis skills. We need user experience and graphic design All and by the way while you're doing that be innovative and communicate well and make good decisions for people and Don't do anything that could get us into trouble from or with the lawyers in terms of legal and compliance Again, that's hard. So my Solution my suggestion is that we need a team and this is a sub team of the broader delivery team Now something that is really important if I talk about and and the title of this talk Product ownership is a team sport Every team in a sport every sports team has a captain. I am not Advocating anarchy. I am saying that there does need to be a guiding mind We're on this slide. We call them the value facilitator It might be the product owner the product champion. The steward is another term the value manager somebody who is Has is setting the general direction, but they are supported by a team with the breadth of skills and like on the on the sports team Now if you're a soccer team Playing in a match and the ball appears in front of you. They don't pause and say captain. Can I kick? They know where they're going and the team captain is setting that overall direction But then we've got to think about the other skills that we may need we need some sort of project management and coordination especially where this Product has got dependencies on other streams of work that are going on in the organization This is part of a bigger program then project management is going to become much more important We've got some relationship and interface with the organization's governance We need analysis skills. We need subject matter expertise If there is a user interface component, we need user experience and graphics type knowledge we might need External independent Verification and validation if you're working in a highly regulated industry such as health care You're not necessarily allowed to release a product unless you've gone through an independent assessment And you need those skills within the team. You certainly need user acceptance test so those to me are the skill sets at At a minimum that are needed in a product ownership team How many bodies are needed is a very very different question That's based around these types of decisions But these are the skill sets you want to consider There's also an overlap and a tightly coupled these images Unfortunately don't show the overlap particularly well, but there is a tightly coupled relationship with the delivery team Again we have the facilitator whether we call them the scrum master the steward the Kanban master The iteration manager. This is a role who's responsible for for team health and process health We need some analysis testing generalizing specialists in our Domain Development or production or engineering some sort of architectural guidance And again This is the skill sets. How many bodies who knows? now these two overlapping and tightly integrated teams Are this other the skill sets that are needed in my mind to effectively deliver products to the marketplace It's making sense Nobody's telling me I'm a lie yet a bit heavy on the on that one Where's it? So where's too heavy and potentially in a complex product product? I've seen a team of 12 people In a simple product, I've seen it as small as to and occasionally I've had the real but the one Mm-hmm. It could do There's there's different patterns for for the engagement of UX graphics whether that whether they are at one one thing that I see with the with these two overlapping and tightly coupled groups is they tend to be working at a slightly different cadence the product ownership up to about half an iteration or sprint ahead of the development Aspects of the team because they are responsible for getting it to ready and these people take it from ready to done What I don't want to do is have a large Timespan between ready and done no more in my mind than about half a half a sprint between ready and done possibly yeah Who are they they are people? with t-shaped skills so We've we've mentioned development there, but possibly we've got people that are full-stack developers possibly some of our developers are user experience people or are good at graphics or Depending again on the domain we're working in yeah, and I'd rather have those personally full-stack Generalizing people with some specialist knowledge It's not about the thin narrow generalists. It's generalizing specialists I'm good at this, but I'm able to step outside and do other things as well, and I and we build that depth over time we become and and I've certainly seen this in people become experts in many areas By putting in a lot of work to it. Can I ask you to? Take just a five-minute conversation for this one What's wrong with what I've presented so far? Where is my model broken does this resonate is it does it feel reasonable or is this is there something that we should be doing That I should be doing radically different here So please take take five minutes not necessarily write stuff down, but have a chat and then let's have a quick feedback session Where is it broken? What is wrong? Or if I would have changed it, what should I change it to? There there are their sub teams very tightly coupled with probably up to half a sprint cadence difference No Co-located if given me druthers given my choices they this is they are a subset of a single group Sitting in if we take the mean low picture all sitting around the same table within Yeah It's not one person. It's and people Yeah, absolutely. Yeah, the part-time subject matter expert or the part-time business person is a dangerous anti-pattern Because they don't care enough about our project the projects where I've seen the most success in terms of these of outcomes of those where you have the the subject matter expert who is dedicated and Part of the team sitting in there with the team in a banking system that I did We had three tellers that we pulled out from the branches and they live with the team for nine months It was great Over the nine months. We actually Cycled them three times that we got other people in because what had happened is that lost touch with the with what was going on there in the The real world of Yeah, yeah, so you you've got to be One of the worst patterns that I've seen is there is the remote product It's a nightmare Richer's high-speed voice technology. He was talking about it the yeah, you literally just You've got to be close enough that you can lift your head and talk as All of the all of the agile methods do talk about the value of the co-located team That doesn't mean you can't work in distributed teams I have seen distributed teams work one of the best that I've seen as a team that works between Brisbane and Bangalore These people do it really really well But they have invested both in the technology to support but also in the People to make it work They're the group is split largely between Most of what I would call the product ownership team is in Brisbane and the and the development team is in Bangalore There's about a five hour four and a half to five hour overlap every day Both teams time switch slightly so they get a slightly longer The Brisbane people work later and start later and the Bangalore people I think start earlier or the other way around so that they they get they they try to maximize their overlap time everyone has a Presence indicator they use a chat tool for presence when you're there You're part of their social contractors that you indicate your present that you are there the two Rooms that the that the teams are in they've got the the commons and caves area and On the wall one on one wall of each space is a lot a big screen TV Sort of 50 60 inch TV and a high definition camera if two people want to have a conversation They'll ping each other on the chat and say are you there if they are they then get up And they go and talk to each other and they've positioned the big screen TV so it looks like you're looking somebody in the face I've seen that team share a meal where they pulled the tables up in front of the TV on both sides and they sat around and they got to that they'd put some thought into it and they shared the recipe in advance so they were eating the same meal in Brisbane and in Bangalore and they were chatting and it was almost past the salt and oh you're in the other side of the world Mm-hmm. Mm-hmm. Yep. The the It's it's not a perfect solution the the ideal solution is co-located Nothing beats being physically in the same space And small teams. Yeah, so cool. And if you if you don't need it get rid of a lot of those roles Yeah, and if we can I still feel there's likely to be a sub-circle in me Yes And certainly when I look at the organizations where we've had to engage with heavy governance such as Medicines and in some of the but the financial institutions the Governance groups that do their job well do have shared vision with the teams There there's others Make no mistake, but to my experience has been that when when it works it's because of a shared focus on delivering value as opposed to a focus on bureaucracy and ticking boxes Yeah, silo behavior is The if there's a single thing that's going to get in the way It's not having that shared vision and it's the the competing goals across different functional groups in the in the organization and This is culture shift. It really is bringing things Bringing a way to to point out what we need to have From there from the cultural changes the One large financial institution we work with used to have a very very heavy governance process Where any to move anything from any step to another in their delivery cycle? You had to go and pretty much beg on your knees to a steering committee and they were made and they they went to legal and all sorts and it slowed everything down they Turned that around and created an environment of trust and within the team one of the team members Was actually trained and these are the these are the legal aspects that we have to comply with and this is why Your role in the team is to help us make sure that we're constantly compliant So that brought the governance right inside and they no longer need to go and get permission. There's a an element of Fundamental trust the person who has that knowledge is now in the team and they are Delivering it on a much more regular basis, but still Auditably provable that they are compliant with all of the legal things that they have to follow up with Sorry, what is the context of the question? There so and again it like like the soccer team, you know If you've got a defense question, you talk to the defenders if you've got an attacking question You talk to the attackers if you've got a strategy question. You might talk to the captain So what is the what is the context of the square the question then you find the person within Either part of the broader team who's got the right knowledge. You might need to yes So we need to spread that knowledge as much as possible and One of the questions is if I'm unsure Okay, who would have the knowledge that I need Becomes the first part of my questioning. They are subsets of a single group tightly coupled with Possibly a slightly different cadence of no more than half a sprint in my mind One primarily responsible to get it with for getting to done the other subset taking from done to ready and Done could be no more than half a sprint ahead of ready No, sorry ready a half a sprint ahead of done Well, what I hope it's there's never a single ringable neck that is just such a Negative metaphor, but they the captain of the of the of the ship is the value facilitator or If you want to call them product owner because they are the the team captain There will somewhat depend on what level of testing you can do where and also do you need? Again, possibly for compliance reasons reasons to do some sort of independent via IV and V type activity What do you want to be accountable for? Yeah, so the Team captain is the ultimate arbiter of where there is where there is conflict and decision the team captain is the ultimate arbiter What I don't see is that that conflict happens My experience has been that in this model you don't get that conflict people collaborate effectively Shared goals shared outcome shared vision that that's where it starts. So product manager product champion Because the product manager is the ultimate product owner If you have a product manager role in your organization They typically have that financial accountability for the product. They are the ultimate product owner. Yeah, and They do they have a product owner is in the system or Okay, but and yeah, the product manager in that case is the because if you have a true product management structure Then that product manager has that financial Responsibility for the product okay Thank you because generally in in Inside a a scrum team or an agile delivery team. There is not much need for direct project management There's the team facilitation the scrum master role who is responsible for keeping the process healthy and keeping the team healthy and removing obstacles project management is most useful when you're in the broader world of Coordinating across multiple streams of work in multiple programs and so forth Generally, I don't believe you need much project management in the delivery part of the team another thing that I think we have a problem with in our In many or implementations of agile is the way that we build our backlogs I've seen a backlog of a thousand user stories a single stack ranked list It's a nightmare It's horrifying It is simply a cue and if you've got a list of 200 things and You've got a level of flow. You're getting rid of four of them per sprint or maybe we're being good. We're getting 20 of them per sprint we we're Knocking off 20 of our stories that means if a new story comes in and it's Not going to be higher priority than anything else. We've got on the backlog. It is 10 sprints away 20 weeks away That's not agile at all We're telling our stakeholders that we've got this this huge cue of things We need to consider how do we shape our backlog? I Did a lot of work in in diamond mines in the Kimberlite fields and We're there what you do is you take out of the ground Wapping great big rocks and you put them through an ore crusher and you break them down from 10 ton boulders to two ton boulders to 200 kilograms and it comes out and eventually you get this fine dust going out on one side and the gems dropping out on the other And that's kind of what our backlog should be You want the gems That are dropping out at the bottom and those are the stories we're going to work on maybe one or two sprints ahead anything beyond that It's useful to know about but we need to To prune to slice to thin down. I don't want 2,000 stories. I want less than a hundred Some of them are going to be big as we get as we knock those ones off We're grinding these ones up as we're moving things down. We're grinding those up and we could be dropping new ones in Somewhere in there are the gems the other thing 90 plus percent of what you think you want Is going to be thrown away So changing our thinking about the items in our backlog not not trying to define the 2000 or the 200 user stories Defining the big picture. Yes No gold outcomes. What are we trying to achieve? Maybe the the milestone based features? Absolutely, but getting them down to the size of an implementable user story should only be done Shortly ahead of when we start the work. So the the backlog refinement activity So what we need now need soon some day and our wishful thinking and some of these things will drop down But a lot of it is going to be thrown away and being comfortable with throwing that stuff away is Incredibly important in terms of the the role of product ownership Not getting wedded to features the riches shiny object syndrome but truly taking a value-based focus and This is a hard decision that product owners have to make as well It's easy on most of our teams to chart this orange line Velocity story points. It's a measure of effort and cost That's all it is. How much money did we spend in the last sprint and over these sprints? The blue line is much much harder to figure out The blue line and it's related to the features as we're implementing them to our stories but we should we were looking for the value that we're delivering and Most initiatives have an S curve of value the first few sprints What we're doing is we're mitigating risk We're figuring out Can we do this? Do we understand the technologies and the tools as a social from a social perspective? Can we work together and? What are the what is our MVP? what is the The smallest piece that is going to validate the underlying assumption that we are That what we are building is useful in the marketplace We'll get to a point where we have an MVP and then we should be able to get it in the hands of real-world users Once we got it in the hands of real-world users, we're starting to get real feedback our backlog should be shifting a lot so those priorities are changing which is great and We're delivering the most important features the most valuable pieces is what we deliver over the next few sprints We come to a point Where the values to curve start and start starts to flatten out? Now if we are working to a budget then I'm going to deliver that Irrespective of what happens to the value curve if the budget that we are working to is this is a an 11? Iteration project we are funded for 11 iterations. We will do all 11 however that stuff We're down in the the nice to haves The 68% of features in a typical product that are never really used by people One of the hardest decisions in product ownership is when to stop if We can recognize the point where this starts to flatten out and It's not easy And I haven't got a magic one solution to tell you how if we can recognize that we can stop there and either switch the focus to another to maybe what we'd plan for the next release or or future elements of the project of the product so that we again Increase the shape of the value curve or we release this product and we bring other work to the team And we focus this team's effort on another product another product that's hard and In most organizations, I don't think I don't see them Having the courage to actually examine our initiatives that closely So an open question. Have you seen that done? Do your organizations do it and how do you know when this is flattening out? I saw a couple of nods Release every couple of weeks. So are you building metrics in to get that those measures? What are what are some of the measures if I? Google analytics, you know So we've got some Reasonably accessible metrics built into the product from the and and things that we can that we can count How many other organizations are taking a doing that taking that approach? Deliver every day So just constant So develop developers test we deploy Yep Right and when the value in production are we measuring that how? Net promoter score Okay, so you've got you built those metrics in Some organizations are doing this. They're getting it right and from the rest of the room. There is a stunned silence Alright, we have 20 minutes left Yeah, okay So so going back to the the previous features and adding the what do we need to do to the backlog? So enhancing that the dropping something new through that Yep, so not tackling the lovely term technical debts UX debt. Yep. We've got debt all over the place now. We talk about business debt That is not related to real money. Okay. We have 20 minutes left So yes, we can look at just coming a little bit down from the from the abstraction Into what are some of the techniques? I love this quote from Jim Highsmith. It's it goes back to 2007 but it's still ballot the number one challenge of agile project management is creating a culture of innovation Everything else pales in comparison Agile projects often attempt to implement the new the untried and the nearly impossible This is not the problem domain in which controlling tasks to achieve a fixed plan will succeed This is a problem domain that demands the innovative exploration of possibilities the innovative exploration of possibilities is that what we're doing in our organizations today It sounds to me like there might be a couple that are most of us We're just working on the next list of requirements taking the time to really Be innovative As we get so enamored with our our new brands our new things that we throw away All of the techniques were used before you know waterfall was evil So anything that worked in a waterfall project. We should never do Scott amble will tell you that Analysis models are really useful in agile projects But I've also heard we don't do analysts that analysis in agile We don't need those thinking business analysts when we bring in new things and We do and should discard parts of the old that didn't work but Know the difference between the baby in the bathwater Metaphor is don't throw out the baby with the bathwater Keep what works and some of these tools have been around for a long time. This is one that is one of my favorite Poliana picks been Todd little Kent McDonald's and their books stand back and deliver Present the the purpose alignment model and this is an initiative that product owners need to To take when they're looking at the work that they're doing We need to look at it for each initiative that we work on and we also need to look at it at every Feature or aspect of the products we work on But at the initiative level at the project level we need to understand Where does this thing fit? are we and The two dimensions it does this how does this differentiate us in the market and how important is it in terms of our mission criticality criticality and survivability so Down here We've got The who cares stuff It's low differentiation low and missing mission criticality Don't bother spending much time or effort on it Maybe outsource it if you're gonna do it at all if you have to do it do the barest minimum that we'll get by But most of the time just don't bother doing things down if you're over here in High-mission criticality and low market differentiation Parity products parity projects Financial accounting for many organizations is a good example of a parity activity you have to do it well If you do it badly you run the risk of either going bankrupt or going to prison you do it really badly So you've got to do it to a good standard But doing it beyond that is a bit of a waste of time and effort No, I don't see Tesla Motors Advertising by our new Model X because our accounting systems are so good This doesn't Resonate with me somehow we should be only operating in that top corner well Yeah, as the product owner I want to be asking seriously why we're doing that this one I've seen a lot of things gone wrong in organizations that I'm gonna pick on financial accounting Because that that is an area where where we see a huge amount of Overexpenditure now we're gonna implement one of the big ERP systems But we are different then we're gonna spend two million dollars Tailoring this ERP system because we are different But actually we're in a parity environment and what we should be doing is adopting The the true industry standards and working to that level and no long and no higher if we're up here if This is something that differentiates us, but isn't critical to our mission Again, we probably don't want to do it ourselves. We want to find somebody who does it well and partner with them Because from an organization value perspective, that's where we want to focus our efforts The things that make a difference to us in the marketplace and that our mission critical Those are the ones we want to put at front and center and Understand where the real value in our organization comes from But these are hard decisions We can have the conversation is about individual features but we also and the really hard conversation is about The the elements of work that we do in our organization When we're starting a new a new initiative, so understanding where we fit is really important That's one of the tools in the toolkit. Excuse me We also and this is coming closer to a single initiative Or it is for a single initiative one of the the tools that that it can be really handy in terms of conveying a message about what is this product getting and I do this often with the team when we're forming starting the Elicitation and understanding of what is this product about? We want to bring people together give them get them to collaborate and understand the vision and the compelling statement of value about this product that they're going to work on and Often having them build a vision box and it looks like a box of cereal It makes them focus and think about what are the important benefits and Then key features that this initiative this product needs to have so the the compelling statement of value which we typically put on the bottom of the box for Customer who has statement of need the product name is a product category that has a key benefit Unlike primary competition our product achieves that is Sometimes called the elevator statement and it's a simple structure that really helps us to Hone in on what are we doing this for? Why does this product this thing that we're going to build in the matter in the marketplace if we have time? I'm going to get you to write one another technique and this again comes a little bit lower The Kano analysis when we're looking here at features in our products We've got to choose what features we include and what we don't Product ownership is often making those decisions. What are the capabilities that this thing will have? And the Kano model says that features fall typically into three categories. We have some delight is we have things that our performance needs and basic needs Delighter is something that a customer will look at and go wow. I want this I Will get I will buy this Because that capability is there a Basic need is something without which we wouldn't buy it at all And then a performance need is something that the more we have of this thing the better we feel So if we take mobile phones ten years ago Having a phone having a camera on your mobile phone was a delighter. I Remember my first Nokia phone that had a camera. It was a wow moment Within a couple of years it had moved from being a delighter to a performance meet need and at that stage we saw phone suppliers competing based around the resolution of the camera in the phone The 12 megapixel and the 2 megapixel weak because honestly the first one I think it was less it was 1.3 megapixels and the it was grainy and horrible, but we could take a photograph Once we got used to having that Then the competition was about what how well the the megapixel range Today it's a basic need you wouldn't buy a phone without a camera and Do you know? The megapixel resolution on the all of the two cameras on your phone at the moment How many people know the megapixel resolution of their cameras? Okay in a room of 60 people I see five ten hands Bunch of geeks And that's the other thing that happens with features they drop in perceived value over time But it doesn't mean you can throw it away You can't stop having it. You've still got it. You've got to have a good camera in a phone today When you think about the features of your products And when we're looking planning releases and considering the the rollout you want to make sure that you have a slice Through so our prioritized backlog needs to include some delighters Maybe not for the first to get to the MVP, but once you'll be on the MVP you've got to have some delighters The the basic needs have got to be met and your performance needs have got to be Good enough in their implementation to entice people to working with them Make sense So the promise was a number of tools, so there are three Let's put them into action. We've got five minutes left And so we got five minutes Or am I time up five more minutes? So I suppose a question folks do you want to try and put a try and write a compelling statement of value for a product? Or do we want to have some question and answer? Question and answer time. Okay Q&A time. Oh boy Yeah, it does come down to influence now now one of the things that is Those product managers so the question did it did everyone hear the question, okay? So the question if I Correct me if I've got it wrong the in in Silicon Valley, you've got a community Who authoritarian Do it my way philosophy about products and They don't come to our agile conferences. They're very influential influential globally about how product management is happening So how do we change? Their perception I'd like to bounce that one to rich Because you've managed to do that with some of your customers much for the same reason we all come to a conference like this Get ideas from others to learn from each other to encourage each other I think we have to learn to do that with the people we work with We have to become the influencers we have to become the thought leaders And you also have to learn to speak to them and let their language Because I think a lot of times if we just try to use our lingo with the people who don't know what we know It's very difficult to move them from where they are to a new place Now, you know one of the biggest impediments to change is success If you're dealing with people who have experienced a great deal of success and you're trying to convince them to change to a new way of thinking They will look at you like why would I change? I'm successful usually the impediment or the Key ingredient to success is pending failure Thank you rich. Yeah, and it is it is about influence and Getting the message out there other questions Is that a stunning sign? Okay, thank you very much folks. I hope that was a valuable investment of your time