Leaving a legacy: Product management and business critical systems

(techno beat) - Hi everyone, and thanks John.

I am in the even less of an optimal place than Patrick was before, which is that I am the speaker that is standing between you and drinks.

So I'm conscious of that, and let's see that I can at least help you to wear off some of that sugar that you've got now rushing through your system ready to accept more of the sugar through the alcohol. So look, I, oh God.

This is one of those things where it's like oh my God, I've been thinking about this and thinking about this and thinking about this so much over the last four weeks that my brain is still reeling and will probably stick closer to my notes just so that I can prevent myself from going down the rabbit holes that I am very likely to go down.

But this is, as John alluded to, I think that there's not a lot being said around this particular area.

Product management, business critical systems at the moment, and I know this because I thought, no, I can't be the only person that's kind of struggling with this.

So I flung out to my colleagues in ThoughtWorks and ThoughtWorks is an international IT consultancy. So we end up doing a lot of these kinds of projects and I figured if any of the product managers who are in ThoughtWorks, if they knew about stuff they would tell me, and then they were like "No, we're not seeing a lot around, "we haven't got anything, have you looked? No, No." And I thought "Okay, cool." I'll put something in for this conference and we can start talking about it and I see this as a start of a conversation. This is not a definitive, this is the way that you will do it.

This is more this is what I found, this is my translations of what's going on in the B to C world.

So I will present, ach, I will apparently run over my tongue.

No, so think of this as strong opinions loosely held to echo a previous thing.

So why I wanted to talk about this for me is I've been working in software for about 20 years in kind of the UX and products space, and at least half of it has kind of been on these kinds of gigs.

These sort of organisational, legacy, business critical systems.

So some of it's been Greenfields.

So I've worked like I did, NBNs provisioning and fulfilment system.

We built that from scratch.

Don't blame me if they didn't turn up to your place. Not my fault, blame the little government.

Just saying, I lived through that.

I cut my teeth doing call centre replacement systems. You know, green screen, off green screen? So I put in a new call centre system of Opters forever ago, and via that I did new codes management system for new South Wales attorney generals.

I worked for five years on ThoughtWorks' own internal IT.

So we have an internal IT organisation of about 200 people. And for about four of those years I was head of products and design for that internal kind of IT and how that puts that together.

And most recently I've just been working on a replacement as we move off loaders notes, not us.

Oh, I'd just like to say ThoughtWorks finally decommissioned its final loaders notes server. (applause) Cutting edge IT company here people.

No, it's one of those things, you know? Where you've got these last bits that just keep staying for forever and ever. Anyway, we got rid of that.

And from since then, I'm now working with a client, still at ThoughtWorks, but you know we're working with a client on moving their sales and CRM system off loader's notes.

That's an exciting, and while, so this is where I've been working through all this and product comes along and there's always interesting stuff being said about it, and all these great things going on and it's like okay, you know, you see these things, like the latest and greatest.

There's fabulous information in them, they're saying really exciting things, you're reading it and you go "Yeah, that's great and I really like that." And some of it just gives you names for the things you've already been doing and others it looks at and you go "That's terrific, but not a lot of it "is actually speaking to my experience "given that I've been working on these kinds of systems." They are not these ways through.

And what's even worse, you know, if it was just me, if it was just me having to translate stuff, well you know, I'd suck it up and say "Get over it." But what is worse is that your clients come along, or your stakeholders, whatever, and they've read maybe Lean Startup and they've read some Harvard Business Review articles and maybe they've listened to a podcast and they start chucking around words like MVP. And the next person who does that I might just have to stab when you're like Jesus, you know? And that's more been the issue.

So I suppose what I'm talking about here today is attempting to try and give you my viewpoint, and maybe that might help you the next time you're in this situation, this is what you're trying to do and your stakeholder asks "What's the MVP?" Do resist the urge to stab them as I have until now. And hopefully use some learnings from this talk to explain why this is just not going to cut it. Ah, and I've pushed the wrong button.

The skateboard, not going to cut it.

Look, and you know, everything, as I said, strong opinions loosely held.

There's definitely a lot of nuances in here, and we'll talk about them in a bit more of detail and you don't want to throw the baby out with the bathwater. But I think that first let's take a step back before I look into some of the standard kind of tools and techniques of product management.

Let's take a step back and look at why it is that this environment is essentially different. This environment of business critical systems. And just in case anyone is wondering, business critical systems are basically if you get it wrong, if you get it wrong, the replacement of it, or they crash, or anything goes wrong with them, you are suffering the organisation or government is suffering severe financial or legal reputational loss. Anyone want to think about the Centre Link Grober's debt scandal? That was a pure failure of business critical product management that that happened.

I keep returning back to the thing to click the dot, it's because I've, you know.

So product management still exists at the intersection and it's just a slightly different intersection. It's still that intersection between business technology and what's normally printed up here is customers. And in this case the difference is colleagues, but it's still that intersection.

So that hasn't changed.

There's nothing different in there.

What really are the three key differences when you're working in it? It's the CL change, like this customer to colleagues, and that is an essential difference in there. It's the relationship that you as the product manager have to the people that you are building for. I now, I completely forgot who alluded to it earlier, but the market, when you talk about that market, well your market are your colleagues in this case. And the second is that you're looking, the relationship that the users actually have with those products is essentially different.

And the third is they're often just not even thought of as products.

So let's just have a little bit of a look into that. So the relationship between the product manager and the user.

So big as their world, we're all relative.

This is where most of the literature that's written and talked about is in that relationship.

There's you as a lovely little, you see I did get a, no, you can't make it work, can you really? There's you as the product manager over there, and there, kind of somewhere at there in the other world is your customers and your users are exactly the same. You know? So there's a big separation between you and your customers and your users.

Enterprise, and in this case it's kind of that enterprise, like there is a bunch of talk going on around enterprise product management, but it's normally from this perspective as well.

Where again, you as the product manager are out there, you're within the company building enterprise software for someone else.

For, and it's a similar relationship, except you've got this weird dynamic going on where your customers are not necessarily your users and to get to your users you often have to go through your customers.

And the third one, and where we want to talk about and where I'm sitting here, and where I've probably spent, as I said, about half of a 20 year career in, is in this business critical space where you're on the inside.

You're on the inside with your stakeholders and your users, who are all there, and in fact they are your colleagues.

You can run but you cannot hide.

And this is a challenging place to be, and it's an exciting place to be, and it gives you a huge amount of opportunities, but you have to be prepared to be exposed and to be honest, because people will come down on you personally anytime they like, because they know where you live.

So let's talk about the relationship between the user and the product.

So this is my lovely, you know, there's the user, this is in the beta C world and the way it's kind of envisioned is that, you know, you kind of have your IT estate, so you know wrapped up on your phone or your iPad, or you know, anything else.

And it's kind of a bunch of discrete little lumps, and some of them play bigger in your life, Facebook. And some you can hook up with others.

But at the end of the day, the barrier is pretty permeable. There's a lot of other stuff out there, you go and pick it up.

I mean you know, think about it.

If you're booking a flight, you don't really pay much attention to if you book it through the airline, direct, through what if, through Agencia, through whatever. You don't care.

So it moves around pretty frequently, and a lot of the product literature is kind of setup to take advantage of this relationship. When you move to the business critical, and I was going to have a lovely building here, but you know, time.

Is that you're in this black lump in here.

This sort of amorphous, ugly, stretchy oil slick that's going on, kind of shows you what's there. So again, you have your little person here. It's a Scottish person in a kilt, in case anyone is, and their IT estate, the barrier is no longer very permeable at all.

You are normally locked in.

This is you at work, and you are locked into a space, and there is this business critical system, I mean often there's more than one and they intersect badly, but you know, go with abstraction. And it hooks into various other pieces.

Even more, it's used by someone else, who it's also hooking in to various other systems that they've got that are not the same as you, but they're all pulling on it in different ways. So as a product manager in this kind of space, you need to corral this oil slick, and we always know how well that goes, don't we? And see this down here? Pay attention to this, we'll come back to this later. This little shadow here, anyone want to guess what it is? Shadow IT.

Is it both your friend and your foe, and we will talk about it in both contexts coming up. So don't forget it.

And I believe that these two situations, that relationship between the user and their products, and between the PM, the product manager and the user, are the two things, and the differences why we don't tend to think about it as a product, these kinds of things as products.

So let me talk about it.

So this is often in this world how this still works. I think it's becoming rarer and rarer in the B to C world and in the enterprise world of building enterprise systems. Rarer and rarer where you have a project team, they make a feature, it hits deployment, it goes to some other team, and they deal with it from there.

There's that big bank of like there's a team, they deliver some stuff, they get all the knowledge of it, they hand it over, and then all that knowledge goes away, yeah? Doesn't happen so much in the B to C world. Rarely still happening quite a lot in the enterprise world. Where as this is actually what it is that you want to have happen.

So you've got that around where people are responsible, teams are responsible for particular products, particular approaches, however you end up breaking it down, and they go through on a whole continuous improvement and go to business KPI.

So this is a fairly, hopefully it's a fairly setup for large numbers of people in this room.

And this is where you can still have that approach for these kinds of systems.

These kind of business critical systems.

We do it, I just want to give you an example here. So this is from Alf.

So as I said, I worked on internal IT for ThoughtWorks over about five years.

And over that time I was both involved in and responsible for some of those changes going through. So when I first joined we had teams and they were at least those collective teams, and they were ongoing responsible for it.

But they were responsible for a system, and it's hard to break that connection between a system and a product, but it does need to happen, and this is the difference.

So we have this system called Jigsaw.

It's a staffing system, it's custom built for us, because quite frankly, the way that we can staff people as a consultancy, is a bit of a differentiator for it. So it's worth it for us to build it and maintain it. They were just responsible for that.

They had very little stakeholder engagement, they didn't actually, you know, they were always going "Well what do we build? "And where are we going?" And it was just kind of like yeah.

We moved into a version of more looking at products. And rather than just a one to one match between a product team and a system, gave them a goal. It was an overall, what were they responsible for? In this case that team was responsible for staffing systems and that whole view of getting the right people in the right place at the right time.

How do you support the organisation as a whole to do this? And that worked a lot better, and we got a lot more engagement and people talking about it.

So the team as a whole looked after still the main system, Jigsaw, but also looked after other little bits and pieces as well in that overall quest to get it through.

And in fact where we ended up transitioning to, and we're still in the process of transitioning, because it's a big leap, is more into a value stream, where we have our bigger team.

Because what was happening back here that we're sorting out the problems, and then we're starting to optimise locally across that problem, whereas there were bigger problems in other areas of that journey, and that's where we ended up moving our teams to a value stream, where it's a big piece.

So anyway, so that was just an example of kind of what that could mean, and that it's the team structure, but it's also the goal of the team.

It's not so much I just need to support this particular system, but more I need to achieve this goal.

Even if you know, generally, in my world you're doing it through there.

So this, I am probably guessing that pretty much everyone in this room is familiar with all those terms up there, yeah? So we're going to walk our way through these seven key kind of approaches, tools that are in product management land.

And we're going to look at what works, what's not so great, and what other twists that you need to put on it to make it work in this world. Okay, value proposition, we're going to kick off there. It's good, and there's been some talk around value propositions and goals and strategies, which is kind of neat, so you know, these are all difficult to judge, and they've all been difficult to judge for me what level of depth.

Because you know, we're going to cover seven all big topics. People have even done complete talks on these here, now, in this session.

There's books written on all of these individually, like how much detail do I go down to or not? So I'm probably going to skim across most of it in the time that I have got, and she says checking to see where that's going.

A little bit worried, I appeared to have used, I'm not going to stop.

And we're on the theory that everyone has Google at their hands and they can, or some other search engine, and you can just go look up in more detail. But value proposition, there's often a thought, why do I care about it in this world? Isn't it fairly self evident? You know, if you're at the point oh God, and you know, you think "Well I don't have to spend too much time here." We all know why we're here and what it is that we're doing and stuff, stop.

Stop at that point in time.

Like if you think just because your job is to replace a ordering and fulfilment system, and so it's like yeah, yeah, yeah, we all know what one is, I'll just go do it. Without stopping and doing this value proposition activity, you are so setting yourself up for problems later on. You are setting yourself up for such a level of noise that it can become a crippling cacophony.

Stuff, so get it sorted right up front so that everyone actually understands what you're doing. Because if you can't get agreement and you can't work out what is the value proposition of what you need to do, and that's, and if you sort of do all these things to go yeah, yeah, I can get the value prop, we know that on why it is say you're doing a replacement, a Legacy system replacement.

If you can't sort it out, well it's a good product manager's job to also know when to kill initiatives as it is to actually deliver successful initiatives. So some of the key things that I've used over time to actually get to those value propositions, is think of lean value tree, and we saw kind of things that without specifically saying it, there are a couple of talks going on there and I'd have to go back and check my card to remember peoples' names, but you'll know them when you see them.

Service design, value stream mapping, and value proposition canvas are kind of four of the ones that I've found most useful. Lean value tree.

This is effectively doing that way to map your work back up to the overall state of the organisation.

So what's the future state of the organisation? What are the goals? What are the bets you're making to achieve those goals? And what are the initiatives? And then kind of what are the teams that you're constructing to deal with that and to go on delivering on that? This is really useful at making those relationships back up through the whole way.

So you can trace it all the way back up, and you can then articulate the value to the company as a whole on what it is that you're attempting to do.

So it's a do this.

Even if your company doesn't have something like this, and you'll find a lot of people do.

They would say just even do it, grab hold of the company's mission statement or vision, or whatever you can find and go "How do I relate mine back up through it?" Where you're normally looking at playing in this is normally in the bet and initiative space because those goals will often be defined.

Yes, so I even have a note here on my notes to go Nicole's model, nicely talked about this. So I wrote it down so I could remember someone's name. Okay, service design leads to service maps. I'd say this is critical in here as part of the value proposition, and the reason being is because you are so intertwined and interdependent with everything else that is going on.

This is actually the service map that I did for ThoughtWorks, probably about four years old now, four? Yeah, about that.

Which makes it safe to put out, to go what's going on across the phases? Who's involved? What activities? What systems are involved? How do they all interlink together and where are we facing problems? And this thing gives you that easy way of going "Okay, we need to look at this in this way." identify the problems because you can see it where you can sort of use this as a way of identifying issues that might be coming up. And then you know doing more in depth service, design maps where you actually walk people through things is a useful accompaniment to this.

This is also great at helping you to identify the stakeholders and the likely user groups. And just do whatever level mapping makes sense to you in whatever way that it does at that time.

I want to talk a little bit about value stream mapping. Does anyone here know value stream mapping or used it? Okay, this is why I thought I'd put it in, because it's an odd one, and this is the thing that I think that you find working in this world is that you drift across into organisational transformation a lot.

So value stream mapping is very big in the lean organisation movement and you know, lean transformation and all that sort of thing.

Basically you follow, you follow through the processes to deliver, so what is it? It's all of the actions, both value add as well as non value add required to bring a product from concept to launch, and from order to delivery. So it's the value streams within your company, and what is the process across it? It's a good method for visualising the flow of a product or service or information, and it provides, and the reason for doing it is to actually identify where are the issues occurring? So this is, there's if you're interested in this kind of thing, go grab John Shore's book on mapping. To see that there's a couple other great pieces out there on there.

This is around insurance, and what it does, and what's the interesting bit around it is that you go "Okay, this is the overall process." This is the time, the PT is the process time, the time it actually takes to do the bit of work. The lead time is how long does it take to get from one end of that particular little piece of process to another? And then under the bottom is what's the rate of accuracy? So you're seeing here like 50% of stuff in this whole verified claim is getting pushed back. And these identify the problems and the challenges that your product is going to face and maybe that sort of legacy replacement.

These are the ones that form part of your value proposition. Where you can go in and say "Look, we are actually "putting this in place because currently "we are watching 50% return rate in this phase "and we believe that we can bring that down to "pretty much that there is, I don't know, 5% return rate." And that's part of the measure that you will use to go and the value prop in there to go.

Give us the money.

I'm not going to go, anyway.

So that's what it looks like in its nice, kind of abstracted sense.

This is what it looks like when you're actually talking across a company with a complicated process through there.

You can do it in post it notes, and it's an ongoing process.

We do these depending on the complexity of the company. It can takes two weeks or so, but it's incredibly useful and becomes a useful tool across the length of that particular project. So I want to talk about value proposition canvas. In this world I find this more useful than the bigger piece of the business model canvas because obviously there's a whole bunch of stuff in the business model canvas that doesn't have direct implication.

But the value proposition canvas and its focus on the pains and the gains experience between the user groups and the creators and the product itself is really useful in creating that value prop to begin with, hence its name. The value is in the title.

Strategyzer of course are big people who kind of invented this and it's great.

Back in your service map you will have identified who your major audiences are and who your major stakeholder groups are, and that's where you need to start mapping to here. And you should do it for your direct audiences, but also for your stakeholders, because they're the people you're going to manage along the way to make sure you get this through successfully.


So we're good with value proposition.

Make sure you do it.

Don't think, "Eh, it's just a replacement product. "I don't need to do it." No, do it, it's really important.

You will find it just saves you so much pain all through out.

Let's go to the next one.

Pirate metrics, we'll see these everywhere. You've got the value proposition sorted.

And as part of doing that, you are to put projected values for whatever it is that you're going to deliver. If it's the B to C world you put these against your pirate metrics to determine how it's going, make adjustments along the way, but it's not going to cut it in this world, you know? Despite the ground sound of being able to go "Argh." Acquisition, activation, retention, referral and revenue, not really applicable when you're talking about inside a company, and when you're talking about a CRM kind of thing really.

So I just want to bring in, these are, and this is when you need to bring these in is pulling through that value proposition that you've created earlier on, is look attitude metrics that are actually going to work for you.

These are just five that I've used on various different products.

Adoption, productivity, recommendation, reuse and attrition. And let me see if my, oh, this is low.

So first up, adoption.

This is around actually going, "Are people using it?" Really? You know? Particularly if you're trying things out.

And you can still try things out in this world, and there are particular things.

This is where you make a bet, and then you need to, and if the bet is around, say for instance 60% of potential users are accessing via mobile once a week.

And you just want to know, "Are people doing it?" And if they're not, then why not? You know? Is it worthwhile us doubling down on this? We use this when we put in, there was a great hypothesis that the thing stopping your reasonable data going through our sales systems was that the sales people found it too inconvenient to sit down at a laptop and put information in.

So we went "Okay, cool." We'll build a little mobile app on the top. We went, now it's successful, if we get 60%. Did not happen.

Basically sales people just lazy, don't want to put data in. There was no real fix for that.

But it did mean we kind of used it, and in fact what we used was that going forward to completely morph into a different product in that space. Productivity.

These are things like for us, you know, and you need to look longer than just our people can complete this process.

Go back to that value stream mapping, and you want to kind of check it across that value stream. Are you seeing an overall improvement across that value stream? And this is where you're going say for example "Staffing requests are available with 5 minutes "of beginning of process." These particular kinds of metrics are often a bit harder than pirate metrics, because you've got to think a little bit more deeply around what can be measured, and what's going to come back and be useful. Recommendation.

This was kind of important to us because we're a consultancy and people tend to you know, if you can't actually show that, you know, I prefer sipping your own champagne rather than eating your dog food, you know? It looks a bit bad.

So we went look, our products have been shown to at least four clients as an example.

That was kind of our metric, and we went "Is that happening?" It was.


Often the justification for putting in a new system is that we want to have easy access to data for different applications, so they can all consume off this one source of truth that you're building. So you want to know what are they? Did that happen? So in this case it's at least two other systems have accessed our APIs.

And attrition, this is the one you really want to make sure that you are not contributing to, or else you are a terrible product manager.

You should be ashamed of yourself, naughty. But no colleague is sighting system, lack of usability, usefulness in their performance review or exit interview. You would think this would never happen, but yes it does. So we want to avoid that.

So those are the, and there are other ones out there, and you need to actually think through what it is that you're trying to do, and how you're trying to do it, and then craft the metrics to match that.

Unfortunately there is no lovely acronym that I can put onto it, or across it as it is. There we go, ah, someone knows what that is. So, pirate metrics, let's come to that one that we've all been talking about today.

Roadmaps in general and thank you, pattern of four, a fabulous rundown on a door.

I'm not going to go into roadmaps in detail. Been through at least one session, I know it's been referred to repeatedly.

If you want to get a good rundown on crafting roadmaps well go read Roadmaps Revisited, which is excellent in this space.

But what I did want to talk about is you still do need something like this, and you need it because when I mentioned you're in this very intertwined space, where a lot of things are so, other people need to know what you're doing. This is also one of those spaces where often, you know, you've got regulatory requirements, compliance requirements, risk issues, training that needs to happen because we're often talking quite complex systems. In the B to C world, generally, if you need training, you have failed in your product development. In this world, you actually aim for, you go okay, because I'm aiming for a fairly experienced user because you're often building things that you're expecting people to be using four hours a day, five days a week.

They're going to get pretty good at it pretty fast. It's worthwhile investing the training in them. But that of course needs to be slotted in.

Needs to be worked out is how are we going to do that? Where is it going to hit? I think the other thing to think about in roadmaps in this space is roadmaps are often thought about only in those external releases.

The releases you make into the user's hands. Don't underestimate, that was the word.

Underestimate the value of also putting in internal releases into here. So releases you might make just internally. They don't either, they don't hit to the user's hands, but the teams were in other people.

These are also useful for things like pilots you might want to run with people, to go, because of the complexity of those systems, sometimes it is hard to know "Have we actually covered often, got everything right?" Releasing it into a pilot, into real peoples' hands, is a great way of learning that.

So these kinds of things.

Also you might be working on something.

The front end is not suitable to be picked up yet, but there's stuff going on in the way that you've reconstructed the back end with say micro services or anything like that that makes it useful then for other teams to hook in. So don't neglect that thought around internal releases as well as the external.

So it's also that way of, in the way that is actually in the B to C world.

It's just that way of kind of bringing the whole company in on board because the big thing that is often in this space is as I think was alluded to earlier, you often, there's often been a lot of failure in delivering these kinds of products.

And people are sceptical that you will do anything. And people are sceptical that it will make it work. And this is that way of going okay, this is how we're going to break it down in what way to try and do it not as a big bang, and this is really tricky in this world, because the data is flowing through, you can't just take it down and give it back and give people back, like you got to keep the business running the entire way, and you're replacing systems that are keeping the business running.

And it's tricky.

So I just wanted to share a couple of approaches on roadmaps, which is more around breaking the work down, that we've kind of found works.

So this is roadmap by audience.

I used this when I did the attorney general's department. We used with Damelo.

It's a pretty common patent, this one.

We go, if your audiences don't kind of talk to each other, so if there's a lot of hierarchy, a lot of structure, a lot of separation, so for attorney general's department, this is all the courts, right? So you've got, you know, this is supreme, district, local, and there's something at the very top, which is around the way lawyers bill.

I can't remember the name of it at the moment, it's completely fled my head.

So when we did attorney general's, we broke it down that way and we went after the smallest audience that had the least functionality first, and knocked them off, and then went for the next one that was bigger, had a slight increase and knocked them off, and then knocked off then the last one, and then tackled the final big one, which by this stage you've done a whole bunch of stuff, so it's just the final piece.

But that can work because they're not sharing data across each other.

In this case it's like that data, they're using the same system because they're doing the same kind of work. They just don't impact each other, it's how they work. But what do you do when you're in this situation where it's just a big lump? And everyone uses it? And everyone's data gets shared and gets moved through in different ways.

It's kind of that oil slick earlier on.

In this case, found most useful is to borrow from engineering.

And there's a practise in there called the Strangler pattern.

Anyone ware of Strangler patterns in the engine? Yeah, and it's great to borrow.

Where it's like you take a deep look into it, and you go what pieces can we carve out? Potentially that can be done as little stand alone bits and maybe there's a little connection through it. So you look for those opportunities, and then you start to bite the bullet and look for the bigger pieces that can be carved out and look for natural breaks in process.

That's often a good place to kind of go, "Well okay, the data goes from there "and then it sort of gets handed over "and people are in a different mindset "when they think about the next piece." So when you did that value process map, that often shows you where processes change. So that's a useful place.

It's really so dependent on what the existing system is and what the new thing is that you're proposing that I can't say there's a standard way of doing it. But it's generally called a Strangler pattern to just go and slowly strangle out all the bits until you've got a new product that actually is never the same shape.

So those are just some ways of thinking about roadmaps in this kind of world.

Again, for more detailed view on this, go look at product roadmaps relaunched I would suggest. So roadmaps, yay.

The thing that often goes hand in hand with roadmaps is my personal bugbear, and apparently everybody else's. MVPs.

Minimum viable product.

Which generally means for a lot of your stakeholders and the people who go "Where's the MVP? "Why didn't you have an MVP? "You know it's been too long, where is your MVP?" And it's like I just, just.

Look, don't get me wrong.

I do love this whole approach, and this whole thinking about it where it got us through a whole bunch of stuff about people only believing that they could do big bang, around people delivering really crappy first things going "Oh, I'm just testing it." It got us through a whole bunch of that.

It was brought in particularly to get people past that dropping confidence that happened after the .com crash at the sort of the start of the millennia.

And it can still be really valuable.

If you think about it properly.

The problem is not so much often with the underlying and natural concept of the MVP.

What's the main problem that turns up and is often being discussed is the fact that people interpret it incorrectly.

And they interpret it to mean "What's the fastest, smallest, cheapest thing "that I can get out, and who cares?" As was referred to earlier.

And as I said, this is not comfortable when really, what you're talking about, and in this world, is often this situation.

It's both very grainy, very badly done, and it's everything is being crammed in and generally loaded onto the top, and it's like how do I keep the whole business moving down that highway at 80 kilometres an hour? Hopefully I can even take them up to 100 kilometres an hour and it's much more safer, and we're not likely to lose things off the head and kill someone behind us. That's your job now.

Skateboard not going to cut it.

And I think what is kind of interesting, and I was like why? Why am I so resistant? Why am I so hating on the MVP? Why does it irritate me so much when people ask for it? And I think beyond just the sheer size of it, it's coming back to affect something that Akasha alluded to earlier on the whole behavioural economics, and this is around loss aversion.

This, as Daniel Cameron, Amus Taversky, Daniel Cameron got the Nobel Prize in economics for his work in this space, and loss aversion is a big one why MVPs often don't work in this space.

And I was going to say basically you value your losses much more, two to four times more than any potential gains. So you already have this system, and I'm going to take it away from you.

And I'm not going to give you that little feature and that little feature, and that little feature, and that little feature, and that bigger one and everything, but I'll give you this little bit here that's really, really sexy and fabulous.

And it's like no, no.

Because unless you're giving me something that is kind of basically four times better than what you're taking away from me, I'm just looking at it as a fail here.

Because uh, and your users have been using, generally, been using these systems for a long time. So they know, they've made it work for them. They've understood it.

They've constructed it.

They feel that sense of yeah, well I know everything that's in there and if you take any of it away that I use, even though I may be the only person who uses it to give me something that you think "Oh yeah, these people over here are better." They're not going to thank you.

And the reason we call it, this ongoing use of it, and this day to day, I thought you were rating me. He was holding up the ten minute sign.

(laugher) I looked at him and went "Wow, that's great, thank you." Okay, I'm going to rush through now.

Yes, and I knew this would happen.

So sorry, let's go through.

And the reason of this usage then you run into another problem, which is the endowment affect, which is "Oh, it would be good "if I could spell Richard better." Normally it's Richard, not Reichard.

Richard Thaller.

And this is anything that you own, anything that you feel you have, even if you haven't actually selected it yourself, even if you know it's not something that you willingly own, but you now have it, you now value it more than the equivalent that you'll be given.

So you put these in combination.

This loss aversion and this endowment affect, and there is no way that anything that falls into anyone's realm of an MVP is going to be seen favourably.

So that's why you need to use that reminder to go okay, how do I cut it to make it? And to do something that I'm trying to still come up with a good thing of it.

But basically what's that shortest path to value? That you can do? And that may still be a couple of Ks down the road to get it.

It's not a stroll in the park here, but what is the way that you can get to value? And when I said it was a conversation, if someone's got a better name to give this or better thoughts on that, I would love to hear it over a drink, or two, or three, or four, or five. Okay, so MVP, ba-bow.

Let's move on, hypothesis.

Let's go read through this very, early on I talked about, I hope I talked about, did I? God.

I talked about moving away from feature parody. Oh, sorry.

Away from feature parity and value parity.

So stop doing this whole where you feel like you got a match feature for feature, and that's where that value proposition becomes handy, because you're doing this this moving away from them.

Just trying to think of a shorter way to give it to you, but no.

So why hypothesis is useful in this way? Because you may think hypothesis is at a bigger level, at a bigger, higher level, is really not going to be valuable in this space.

Because while I said, like question why you're doing things, but at the end of the day, if your company is big enough to have say an ordering and fulfilling system, that they then have got enough money to look at replacing it because it's not fulfilling what they need, then they don't need to hypothesise, but they need an ordering and fulfilment system. Like we're all just taking that as given.

But it is this moving away from feature parity to value parity, that is where hypothesis really come in to their end.

So a specific example to give you of how hypotheses might work in this case, and it's on that day to day of getting people to accept. Accept the value rather than the feature that they've decided they want.

So it's often the case, say in a sales system whereby you know, there's deal management system, and it has a feature to block users from closing off a deal until they've either referred their client to a third party product, or the client has opted out.

Look, the sales person, and the sales person has to actually talk to the client before they can do this. The way that it's often handled in existing systems is they'll often put up a piece of enforcement to stop you moving.

You know the modal that just blocks your screen and says "No, have you spoken? "Are you going to refer this product? "Have you spoken to the client yet?" And you go "No I haven't, I'm not going to call him up "to do this, and I need to get this deal through "so I'm just going to hit the client is opting out. "I don't want to do it." All right, these kinds of enforcements have often been put in place because the systems are so rubbish to use that no one wants to spend any time using it, and so they need to put in places to make it go away to stop people.

A hypothesis can work where you can go, where you can go to your stakeholder, the person who is insisting that that is and go "Look, "I'm going to make a bet with you." A hypothesis really is just a bet.

And you can bet something like you know, "We believe that removing a mandatory referral completion "but making it easy for salespeople to create a referral "at any point in the process "and giving them target reminders "will result in customer conversations at appropriate times "and less opting out of referrals "merely to keep a deal moving.

"We'll know this is true when referrals are happening "with at least the same frequency.

"If it is not true, then we will put in "a mandatory completion enforcement." And this bit, this if it is not true, is very important to capture at this, because otherwise it's not a true bit.

And this is the way where you can put in front of your stakeholder and go "This is the value that I believe "that you need to build, and we think "that we can do it in a better way "that is not going to undermine "the total productivity of the system.

"Are you willing to accept that bet?" Nine times out of ten, we found that people were willing to do it.

So this is where hypotheses are really good. Really useful in there.

So hypotheses, go with them.

They just hold a slightly different place.

So hypotheses are often used in the whole build measure learn cycle, we're all aware of this. It's great, it's in everything, yay, build, measure, learn. Really useful, and this is the way that it's normally stated.

Build, measure, learn, this is not going to work in this environment.

And I think there's, you know, I'm seeing actually a lot of talk starting to merge in general, and let's be nuanced about this.

This is never actually exclusively said when it was projected that no, it has to be this way around, but it's just everyone talks about it that way and it's built into that expectation that yeah, I'll build something, I'll put it out there and I'll learn from it.

Yeah, yeah, I'll build something.

This is not going to work in a world where people have been doing this job for 20 years, where it is already set up.

It is fully functional in there.

To build anything in a state useful for measurement is just so much bigger, that when this was kind of as an approach was envisioned and then put forward in the B to C world. So don't do it, but just move around.

Just start with learn.

This is the joy of this particular environment. In this world you generally already have an entire organisation doing this thing that your product is going to slide into.

Take advantage of it.

Leverage the existing knowledge, because in this case there's lots of it, and make sure you go broader than just your direct user. Make sure you actually learn from you business stakeholders because they have a stake in this.

But also they are often indirect consumers of what's going on, but learn from them all. If in the graphic research, really easy in this environment. You are embedded into it, and you can, like, you know, even if someone's going "Oh, no." You can just go sit on someone else's floor and watch them do their work, you know? You can often just kind of slide in to things really easily in this world.

So ethnographic research is awesome for getting that show piece in there, and we all know that show is generally better than tell, because self reporting is bad, people aren't great at it. They just don't, you know, as was discussed around the episode, how many times do you go to the gym? Everyone self reports what they think they should say. But I would say in this case to go out, observe, watch what people are doing, seeing the artefacts that they're using, do that ethnographic research in there but also get them to tell you stuff as well. And one of the best tools that you can use for telling in this environment, because it serves kills two birds with one stone is techniques like co-creation or participatory design, because what, you know when we talked about that ownership? That endowment affect? Co-creation is one of those great ways of bringing, transferring ownership.

Of moving that sense of ownership now onto, of the new, onto the people who are currently using the old. So it's a great tool.

It's also a great tool to get probably the best brief that you will ever get.

No one expects that you will take the generally, let's say the idiosyncratic designs that the, you know, just sort of anyone on the floor will do. But what it does is it's a great conversation tool, and it's a great brief for the way that you would then take that forward and design that product.

So I say is that you don't in this case need to build in order to understand your organisations' needs. So just transfer the way.

And you want to know the other great place to learn? I said I'd come back to it.

Here, thank you.

Is shadow IT.

Because all these people are already running those experiments for you.

And those experiments are called Trello and Slack and Drop Box and Pipe Drive, and any other tool. Excel.

Any other tool that is easy to get ahold of and slot in and customise.

They are finding such a lack of tools in the area that they're in, that they are willing to put up with the disadvantages of lack of integration. They're willing to do swivel chair integration to make them work.

That's how valuable these are to them in those situations. So mine this shadow IT for all its worth.

In fact in ThoughtWorks we found this so valuable, we built up an entire product team to just support shadow IT.

It's also the case, you know, we're a software consultancy. Everyone builds shit anyways, so you might as well make sure they can do it safely. But we keep an eye on what's going on in there. It's a team called labs, and if there's something really good that looks like oh, that's nice.

And that will work globally, then we'll bring it in to the general, overall IT estate.

So really go with exploring that shadow IT as part of a learn, build, measure cycle.

So go with it.

Just cool.

And the last one that I want to talk about, hopefully really quickly is marketing.

And I think Tom spoke about this a lot, and the marketing, you know marketing is really one of those things that as a product manager you need to be quite close to in the B to C world, you know? Lives quite large in your life.

And it should, because you know, the marketing brings in the money.

You know? It helps to bring in that money.

So not so useful you know in this world.

And you know what is? Change management.

This is the big one.

But change management is almost never spoken of in any of the product literature.

For this again you have to go out into organisational transformation.

But it's in that same relationship that you'll often have with your marketing people. You should know enough as a product manager to enable you to have intelligent conversations and know when to bring experts in.

So it's that similar kind of thing.

Look, I'm not going to go into in depth in change management, because there is an entire specialised practise in there, and three minutes is not enough to cover it off. But I will just briefly talk about you know how I said, don't part metrics, not your friend. Change management has this thing called an ADKAR model which his around people focused change.

Which is looking at awareness, as in creating an awareness for change across the people who need to participate in the change.

So they understand why.

Why is it happening? As humans we want to know why, and this is critical for doing that.

So people go "Oh okay, cool, I'm there.

"I'm there with you, yeah." And then creating that desire for doing it, and this one's often really difficult because this is a personal choice.

Again, techniques like co-creation can help you in creating that desire where you go "I see it, and I know we have to change, "and oh, I think that would be a lot better. "So can we do that?" So that is that desire to change.

Knowledge is the next piece, and this is often where people talk about change management, this is just where they're going. This is all your training, your coaching, your webinars, your in app help, all of that sort of thing is knowledge.

This is very important, very useful, but without having created the awareness and desire beforehand, you're dooming this to failure and to a lot of resentment in people sitting back there in their training sessions with their arms crossed. I was looking around for any arms crossed.

So make that happen.

The ability.

There's a vast gap between knowledge and ability. Knowledge is knowing how to do it.

Ability is actually really being able to do it. And if your value prop, or any of the success metrics include productivity in there, this is what you actually need people to have is this ability to do it, to be able to deliver on those productivity metrics.

And then reinforcement.

And reinforcement is one of those key reasons why I think you need product things in this space, not just project things.

Because to make this stick, to make the change stick, get the value that you've put in to those business cases, that is in those value prop, you need to reinforce what's going on all the time.

So I said that there wasn't any cool acronym, but just for you, if you put together your success metrics and your change management, you have APRRA ADKAR. It's like magic, magic, okay, right, let's just move along, shall we? Sorry about that.

Drinks very soon.

So let's take a look at where we are just to recap. Take away your pirate metrics.

Give you back success metrics in general.

Takeaway marketing and it becomes change management. And that MVP? Well until somebody gives me a better view over drinks, let's just go it's the shortest path to value, that SPV. And I hope that's been useful for you.

I hope that you've learned something.

Thank you very much.

What I do want to say is also look, this is a challenging, interesting and exciting world to work in.

It may not seem it, like everyone goes, "I don't want to do an ordering and fulfilment system." But it's like oh my God, you are going to work in the most exposed and engaged way that you would ever be able to.

You have to live with your mistakes, and I know that people scares you, but this is doing, I'd like to just say, this is product management on the edge people. (laughter) On the edge. So thank you very much, and enjoy drinks.

(poppy beat)