Product management is about managing uncertainty and learning what works, quickly.
In this 30m webiner, we’re looking at how to navigate uncertainty to manage and reduce risk in digital product development.
This session covers:
- How to understand and identify risks during product development
- How to map and validate your assumptions at pace
- How to create alignment between your product and leadership teams
This webinar will be especially relevant for strategy, design and product teams who:
- Need to manage and mitigate the risks involved in creating a new product or service
- Struggle to manage and prioritise feature requests from senior stakeholders
- Want to make sure they are building the right thing, for the right reasons
"There's no magic formula that makes a great product manager great by just knowing what is the right idea. It's about being open-minded, testing things out and experimenting in order to get to the right place."
Leon Barrett, Product Director, 383
Video transcript
Hi everyone and welcome to my Canvas session on navigating uncertainty in product development. I'm Leon and I'm Product Director at 383.
In this talk today, we're going to cover off four areas. First of which is understanding risk, risk being one of the key things that can be the result of uncertainty; how to spot the main types of risks. Second, is on mapping assumptions; how do we frame our assumptions to bring clarity? Third is reducing risk; how do we create a plan of action to reduce risk by validating assumptions? Fourth is creating alignment; how to ensure that everyone is on the same page with what we're doing.
Before we jump into it, I wanted to really, in this talk, offer some practical guidance for how things really are in the organisations that we work in. I think it's fair to say that a lot of the books and talks that we might see are focused around startups or well established product companies.
But the reality is, a lot of us don't work in those organisations. We might be the only product manager or one of the few product managers in a large organisation. And sometimes it can be quite difficult and lonely to be able to manage your way through the role. Hopefully, in the next 30 minutes or so, I'll offer up some practical advice on how to manage through some of that uncertainty.
First of all, let's start off with a definition. I actually renamed this talk, navigating uncertainty. It was around product strategy, but actually uncertainty seemed like a bit of a better fit. So, when we say uncertainty, we're talking about, especially in this instance here, of a person, someone that's not completely confident or sure of something.
If we think about that in a little bit more context, product management actually is really about managing uncertainty and learning what works quickly. A lot of the time, the role, rather, isn't necessarily about always having the ideas and being right; it's about exploring through a number of different solutions until you get to the right point, that point being something that can add value back to your business.
The rest of this talk will make a bit more sense if we've got an example to bring everything together and add a bit of context to some of the things that we're talking about. For the purposes of the rest of the talk, imagine that we're the product manager at a company called Build Shop.
Build Shop are the fastest growing building materials and tools and hardware retailer in the UK. With an impressive online presence, they offer click and collect in under a minute from over 600 stores nationwide. They've really got their click and collect online bit nailed and buttoned down.
The founder and CEO is ambitious, results driven, and, in terms of bricks and mortar retail, at least, really well proven. She's brought many innovative ideas to the business, including the first drive through click-and-collect format. Especially during Covid, they saw some really record numbers through there. That means that she's open to discussing different viewpoints, but she's also really dedicated to what she thinks is right. And actually most of the time she is right, so it's hard to convince her.
As part of their ongoing expansion, they would like to launch a new mobile application. Their competitors have got an application and they need one too. The chief aim of that is to make it easier for their customers to order. Six years ago, a previous app was launched that didn't have the desired impact the business wanted, and it's kind of believed that it was because there was no killer feature, nothing that made it stand out from the crowd, that made people want to download it and keep it on their phone.
With all the above, as a product manager, you then need to be able to manage the actual requirements of customers and the CEO who's constantly giving their input on a long list of potential features. This is where the uncertainty bit creeps in. One of those ideas is a virtual assistant. This is being talked about as a way to make it easier for customers to be able to order products that they need when they're not too sure exactly what the products are.
Imagine the scenario; DIY customers updating something their home. They don't quite know what the tool or the actual piece of equipment is, or the part might be. And there's a thinking that we could solve that with a virtual assistant and that virtual assistant would be something that's really exciting, that will give them that key feature.
That's a bit of context for us to be able to think about as we move through this process. Maybe you might be already thinking, yeah, that sounds a little bit similar to where I'm working now. We get these ideas, but it's really difficult to then manage them through.
Let's start off with what we mean by understanding risk. This is a really useful structure for us to be able to think about the different risk factors that can lead to the bad kind of failure. Failure in and off itself isn't a bad thing. It's bad, though, when we've already exerted lots of effort on activities that ultimately don't provide much or any value back to either the business or the end user.
When we talk about types of risks, I really like this breakdown into four areas. I'm not too sure exactly who coined initial grouping, but I first was introduced to it by Marty Cagan, so I'm going to let him take the credit for this bit. It's a really great way of thinking about how and why a product could fail. Once we understand this, we can start to think about how we can change and challenge ourselves to avoid this risk. We'll come to you these four types of risk a little later on.
Breaking through it, then, first of all we've got desirability and that's whether or not customers will buy or use what we are offering them. We've got usability; whether or not people can figure out actually how to use this thing. We've got feasibility; whether or not we can build what we need to within the time, skills and technology that we have available to us. We've got viability; whether the solution that we put in place also works for various aspects of our business, ie., if we build this thing and exert all this effort and time on it, does it give us the returns that we think it will do?
Sticking with Marty, really great quote here. The role of a product manager is to discover a product that is valuable, usable and feasible.There's a key word in this here which is discover. Discover has a level of uncertainty with it and really what we want to be able to get to is a place where we can work in a structured way, de-risking it, identifying those four types of risk, to get to a place where we can then start to deliver value back to our organisations.
The next thing we want to start doing then is mapping and framing our assumptions and this helps us to really define what it is that we're trying to achieve. Here with a quote; when we say assumption, this is a thing that is accepted as true or as certain to happen without proof. And that without proof is really key. I like to frame all potential features as assumptions and they're just that. Until we've done some work, until we've got some proof, they are just that; they could happen but we don't know that.
Let's take our example. The CEO has the assumption that by creating a virtual assistant, that will be the thing that makes it easier for customers to get their items and increase their sales. But if we unpack this a bit further, we can start to see those risks and where they might be able to play out.
Desirability; if we create a virtual assistant, there's quite a high level of interaction potential that's needed. Are people going to want to be able to do that when they've got lots of things going on their life? Their focus isn't on going to Build Shop. They've got lots of different things to do. So, is this desirable to them?
Usability; well, what does the user need to do in order to be able to use this assistant? We need to give it lots of information. Does that create additional barriers?
We've then got feasibility; do we have the skills available to us, and within the time scales that the CEO wants to launch the application, to create a robust enough application that actually solves problems and doesn't just lead to dead ends?
Viability; as we've said, if we do all of that work, do we think it's going to lead to the increases in sales that the business is looking for?
Let's not forget we could go through this process and tick off desirability, usability and feasibility, but ultimately, if we're not confident it's going to make the improvement that we seek, is there a different way of achieving it?
I like to start with why. You might be familiar with exercise like the 'Five Whys' to understand the root cause of something. Essentially, you ask yourself 'why' a number of times until you get back to an answer.
If we take this, then, the first thing is, why would somebody use an AI in the first place? Sorry, an assistant, in the first place. It could be because they don't know the name of a product or tool that they need. So, they've got a task they want to get completed, but they don't actually know the tool that they need in order to be able to get that done.
Why is that a problem? Well, if you don't know what you're searching for, it's going to be hard to find it.
Okay, now, why is that a problem? Well, it might be that you either don't buy something that you needed or you go elsewhere and don't use Build Shop.
Okay, now why is that a problem? Well, then we start to get the root of this, which is that if you go elsewhere, that's revenue that Build Shop aren't able to convert.
What we've just done there is we've reframed that as a problem and not as a solution. Actually, we like to call this outcome thinking, and that is starting by understanding what the outcome is that we're seeking and not focusing on the output.
There could be some value in that virtual assistant, but if we start there, we've already restricted our field of view in our thinking. If we move ourselves to the outcome, the thing that we're trying to achieve, that now gives us more space to be able to move within to make sure that we're getting the right solution.
Outcomes are really useful in a world where we're not sure or not certain that the thing that we'll make will have the result that we want. That's a quote by Josh Seiden. It goes on to say that outcomes are the changes in the customer, user or employee behaviour that lead to good things for your company, your organisation, or whoever is the focus of your work.
I'm not going to go too much into outcomes thinking. My colleague Ross actually has got a talk, a Canvas session as well, on outcome thinking. Go and have a look at that. That's up on Wednesday afternoon, I believe, so go and check that out, it will be in SpotMe, to go into a bit more detail. One of the things that we both swear by is book called 'Outcomes Over Output' by Josh Seiden, who those quotes came from. It's only 40 minutes long and it really helps to explain it in a bit more detail.
In our example, we could frame the outcome like this; to make it easier for our customers to find and buy the things they need, and in brackets, when they're not sure about what it is that they need. That as an outcome is not turn us down to a particular solution; we can still go and explore the virtual assistant but what we can now do is start to use our brains and really think back about that quote that Marty Cagan gave about how we then can go and solve and discover solutions to this outcome.
We know we've got risk, we know what the types of risks are and how they group together. What we now need to be able to do is do something to go and remove as much of that risk as is possible to give us the comfort or certainty to move ourselves forward. Another definition; hypothesis, a supposition or proposed explanation made on the basis of limited evidence as a starting point for further investigation. Brilliant. With a hypothesis, what we're able to do is put a stake in the ground on something and then go and test or do some activity to figure out if that is going to become true and therefore removing risk and adding ourselves some certainty.
It's really important that we're able to go and experiment to investigate our assumptions. There is no magic formula. Yes, intuition plays a role in it, but there's no magic formula that makes a great product manager great by just knowing what is the right idea. It's about being open minded and testing things out and experimenting in order to get to the right place, but having a framework within to do that. We could use something like a hypothesis statement. This allows us to clearly state out what we think might happen and then we can use that as a way to then go and discover if it could happen.
Let's go and stick with our assumption of the virtual assistant. After all, we can't ignore the CEO, we've got to then take it forward. A statement might look a little bit something like this; we believe that a virtual assistant for DIY our customers will achieve better product selection and we know this is true when we see increased average order value. There might be multiple hypotheses that we've got as a team. We might want to discuss the merits of those ones. We might be able to discount some of them. But we now are in a position where we need to go and test out multiple hypotheses to get to the right answer and to give us that certainty that we're seeking.
At 383, we've developed something called the rapid prototyping framework, and it's there to enable us to do that in a really structured format. It provides us with gates and reflection points that we can use to then make sure that we're not going too far with something and we've explored an idea fully.
The first thing that we do is we have an ideation workshop. So, we've got that outcome now. There might be multiple ways of meeting that outcome. What we do here is we get a cross-functional team together; that's going to be engineers, designers, product managers, stakeholders, whoever it might be in an organisation that's going to have an input on this and also, in some instances, customers, to figure out what are the potential ways that we might be able to solve this. We also want to be making sure that we're thinking about the constraints that we've got, whether that's time, budget, other initiatives going on, there might be some technology change already happening, whatever it might be. It gets us to a point we can start thinking about how might we solve this problem in a number of different ways.
At the end of that ideation workshop, or that ideation phase, we've got a potential number of different ideas that we can then turn into those hypotheses. We now need a way to be able to go and test those out. We use something called a fast track sprint and it's a little bit similar to a Google Design Sprint, where it's five days, so it's deliberately short to keep us focused. In that five days, we'll take that idea and we'll refine it further. We'll state what we think good looks like, so, how do we know who if we are on the right track, and we'll go and do some work then to go and create some level of testable thing. Might be a prototype, might be a proof of concept, it might be a clickable thing. Whatever it is, it doesn't really matter. But it needs to be able to demonstrate the thing that we're trying to prove, to give us that confidence that we can move forward.
In some instances, these have taken more of a technology focus, sometimes it's taken more of a usability focus. What you'll see is that we use those risk categories as a way to figure out what's the riskiest thing to us at the moment and how do we go and close that risk down in a really short amount of time?
At the end of the week, a number of things will happen. One; we might have met our assumptions and proven ourselves right, from which we can persevere forward to the next stage. We might have thought something would happen and it didn't happen at all, in which case we could kill that idea. Or, we might need to pivot, so we learn something different than we expected, and that means that we now take a different course. The purpose is, over that five day period, we've been able to move through a set of activities to get us to a point where we can now say, yes, we've got confidence that we can move forward and this is the right direction that we need to move forward in.
There is more than likely going to be a number of different questions that we've got before we want to move forward and that's where we go into our optional validation sprint. This is a two week period of time that we can then go and do some further work to validate our thinking and test it out and maybe a wider audience or by doing some deeper technical exploration.
At this point, we should have a really good idea of how we're going to solve our problem and we can move then into our agile or product sprint and take it forward. This framework allows us to de-risk a process and to do it in a time-boxed way, which means that we can give it the exploration and the dedicated time that we need.
The final bit then is on creating alignment. How do we ensure that everybody is on the same page? I mentioned before that our CEO has lots of ideas and is pretty steadfast in her ways of those ideas, but is open to change if the evidence is there.
We might be familiar with a term called the 'hippo', or the highest paid person's opinion. This is where somebody like the founder or the CEO makes all the decisions and they essentially tell us what to do. That can be quite difficult and actually quite demeaning in terms of the role of a product manager.
This is a great slide from Product Board; this is other dangerous animals of product management. I'll make this available to people later on so you can go through and read those. The point is this; regardless of the people in your organisation, the biggest factor in terms of things going wrong is a lack of alignment.
By alignment, and this is another definition, it's the final one, what we mean is the position of agreement or alliance. What I don't mean though, is that everyone has to agree to the same thing. What we're not trying to do is get everyone to say, yes, this is the idea that we're going to go forward with. What we're trying to do is to get everyone aligned and aware and in agreement of the activities that need to be undertaken in order to drive the results that we want to see.
A lot of the challenge that we see sometimes is a disconnect between what the CEO wants to be able, or leadership wants to be able, to achieve and how that translates down then into activities that the product team can then go and undertake.
This then causes frictions and issues between those two teams. Product managers and product teams feel like they're just delivering things and they're not being able to input into it. Leadership think that the product teams can't just take what they've said and deliver it - why not? Like I said, the key thing here is alignment. There's not an awareness of what needs to happen in those instances in order to drive the value. We're all shooting towards the same place, all got the same ultimate goal, but what we do need to be able to do is make sure that each person can play their own part.
These are three top tips that I would give you, if you're not already doing this, around alignment. The first part is to visualise, so, bring the work that you're doing to life. Make sure that you're using tools like Miro or whatever it might be and decks to help to tell a story, highlighting the areas that we see risk and why we think it's important to go and close that risk down and the progress that's being made. Sometimes this can be difficult because you feel like you have to over commit to developing features, but that's dangerous, because we don't know if those features are the right thing. The visualisation of that is really key.
The second thing is to keep things simple. That's language simple and avoid getting bogged down to detail too early on. Read your audience and work with them. Some people really like the detail; other people are really focused on the outcome, so use that to help you to understand how you communicate, what information you pass over, in terms of the detail. You don't want to lose people along the way. Demonstrate that you're trying to get to the same place which is maximum value for the minimum amount of effort.
Then, experiments. We've spoken about outcomes. Have these clearly defined and gather evidence and data in order to then allow you to be able to prove or disprove those outcomes. Don't forget that the job here is to deliver value but we'll first have to work out and understand what that value is and then how best to create it. The point here is that you should think about judging yourself on getting people to the point of clarity and sometimes that will mean that your initial assumptions were right and you prove yourself right and sometimes it means they are wrong. It doesn't really matter as long as the thing that you get to is the thing that drives value back to the business.
With that, failure is okay. By failure, what I mean is, we start off with this assumption, we thought it was going to be this, actually it's not this, it's something different. As long as you do that and manage it correctly, and correctly is quickly, without exerting too much waste, then that's fine.
Hopefully that's giving you some practical pointers and tips on how to manage and navigate uncertainty in product management. We spoke about the four main types of risk and what they are and how we can use that as a framework to go through some product discovery. We spoke about how to map our assumptions and turn those into hypotheses. We spoke about a framework to then go and test those things out. And then we spoke about alignment and a way to keep people all on the same page so that we were aware of what we're doing and we're not forced into a situation where we're either having to over-commit to something, in order to get people off our back, or we're not giving them the details they need and that's therefore making them impatient.
That's it from me. You can connect with me on the Spot Me platform if you'd like to ask any follow up questions. Hopefully you got found something useful and enjoyed that and hopefully see you soon.
