Accelerating through ambiguity
This Full Stack Friday is focused on techniques successful product leaders use to generate forward momentum when the right answers (and the right questions) are unclear. We're all adapting to the now. What users need, what consumers expect, and how organizations operate continues to change rapidly. Enterprises must make calculated bets to address pain points and hedge against future uncertainty, all while enabling their business to operate under dynamic conditions. Those that move forward fast and decisively can shape their destiny.
Hear from Devbridge Director of Product Design Chris Wilkinson.
Watch the talk:
Transcript:
My name is Chris Wilkinson. I am the director of product design at Devbridge, and I'm really excited to welcome you to this week's Full Stack Friday. For those of you that are joining us for the first time, we started Full Stack Friday a little bit over a year ago, and the idea was that we wanted to have a series of conversations to give you the tools that you would need to really improve your execution and the way you think about product and leave you with specific things that you could try out with your team later in the day. So my hope is from today's talk, you're going to leave with a couple of new methods, ways of approaching and thinking about problems, and then be able to give those a shot in your work day today. I think it's pretty exciting.
Any train noises that you hear in the background is because I'm coming to you from Chicago, Illinois, near the infamous L tracks, and we'll just say that that's ambient noise that goes with our theme of accelerating through ambiguity. All right. So what does it mean to accelerate through ambiguity? Well, I think that the best place to start is to really think about our place in the cosmos. Now, stars have been this thing that has been around us for basically all time, since the Big Bang, and humans look to them to try to understand their place in the universe. They looked to them as this random assortment of dots in the sky, and they've been ascribed many different meanings over time. And with time, people began to ascribe constellations to them. And the constellations weren't actually in the sky, but they were representative shapes.
They took these random points and this cloud of ambiguity in the sky, and they ascribed meaning to it, and those constellations provided a sense of the tracking of time, the tracking of seasons. They provided a sense of people's place in the universe. And when you're working on a new problem, when you're working on a new product, the way that you get information can often feel like you're looking up at the night sky at first. You have this wide assortment of spots in the air, and you're trying to sort of ascribe meaning to them. And at this point, really all you have is some assortment of just information. It's just this cloud of information that you're trying to understand. And what we do as humans is we look at that information, and we try to ascribe meaning to it. We try to ascribe context, and we try to ascribe some sort of pattern. So we start to say, okay, well, let's get to the point where now we actually have some data... Has some information behind it.
It actually has some context. I have that context. And your pattern-driven brain looks at all of this and it goes, "Okay, good. I took in the data, I've decided what it actually means, and now I can begin to draw connections between those points." And those connections between those points is our attempt to bring some sort of sense of order to an uncertain situation, to bring some sense of order to ambiguity. Now, we have knowledge. We have these units of knowledge, and our brain traverses these paths, and it understands where we fit inside of that entire context. Now, for a specific problem or specific area, once you have enough points of knowledge, the brains are really amazing at creating these moments of insight to actually have these individual sparks of insight. And once we have enough sparks of insight where we really understand what we're getting at, we then kind of reach this higher level of understanding.
We have a sense of wisdom, a sense of belonging, a sense of how everything fits together. And this is a very natural form of evolution for how we process and understand new problems, and how we begin to process data and information when we find ourselves in ambiguous situations. Now, a word of caution is that our brains really like making patterns, a lot. And it's very possible to take that data and attempt to rearrange it into something that maybe fits a specific narrative or maybe something that doesn't exist at all, and so we have to bring a certain sense of professionalism and caution and verify and validate that data we find a way and don't get caught up in fantasy and conspiracy, and instead really anchor our beliefs and our thoughts in what is true and what is real.
When we think about space and we think about ambiguous concepts like, "Where do we fit in the universe," we've evolved those thoughts over time. We've begun to find our place in the universe, because we looked up at the sky and we used to say, "Well, the earth is the center of everything." And then we said, "Well, maybe the earth isn't the center. Maybe it's the sun." Over time we began to learn, well, the earth also rotates around the sun, which rotates around the galaxy. And I think when a lot of us think of a mental model of the solar system, these mental models are very powerful for us to understand ambiguous concepts. We think of it as rotating on a plane, but it's even cooler when you think about the fact that we're revolving at 900 miles an hour on a planet that's orbiting at 19 miles a second, tranversing the Milky Way at a million miles a day.
Now, I only remember that because of Monty Python, so thanks to them for that brain worm that has stuck with me for the rest of my life. But really, our sense of how all these things come together builds on our previous understandings. We encounter the next level of ambiguity, and then we break that ambiguity down. We understand in pieces what we can understand, and then we evolve our understanding. When we take on these ambiguous problems, we encounter ambiguous problems, it allows us to achieve more than we could previously. And you don't break down an ambiguous problem, you don't encounter a new opportunity by simply standing still. I think it's really, really important whenever you encounter any kind of ambiguity or uncertainty, is that you have to keep moving.
You have to keep your feet moving. You have to keep trying to move forward, because if you don't, your brain starts to worry because it can't form new patterns. It can't form new connections. That ambiguity becomes uncertainty. And in that uncertainty, teams working on products can find themselves without a clear path forward. They can find themselves without a clear way to build on anything, because they don't know where to start, and then you have inaction. That uncertainty breeds inaction in teams. And maybe they might start running off in one direction or other. Maybe they're all moving in different directions, but if everyone's pulling in different directions, you're still standing still. And what happens in that cloud of inaction in that cloud of uncertainty is everything stagnates. A product will stagnate, a business will stagnate, the opportunities become lost, and the things that are moving through an ambiguous situation, through uncertainty, they continue to evolve while you slowly fade away.
And that stagnation and that fading away generates a fear response in us. It's a natural part of our evolution. And in that fear response, it can become even harder to break out of that cycle of inaction. So I want to share some philosophic advice, if you'll allow me this morning a little bit of philosophy. Very important to not give into fear. Ambiguity is not a scary thing. Uncertainty is not a scary thing. When you come to the situation prepared, and when you come to it with a plan, and when you come to it with the right tools, you're able to navigate that situation.
And today, I'm going to share some tools, some approaches that will help you encounter ambiguity and hopefully overcome it and accelerate through it to achieve a new level of understanding and a new level of success for your products. Now, a little bit of ambiguity, again, is a very good thing when used properly. It gives a sense of narrative pull on the situation. It provides context for why we do what we do. It is a frame in which we can posit sort of the great questions, such as, "Is this Baby Yoda, or The Child?" I'm in camp Baby Yoda personally, but the entire tension of who is this and where they come from is why The Mandalorian was such a great show. For those that haven't seen it, excellent, excellent, excellent watch. Now, don't worry. Modern Disney references aren't the only reference I'll be sharing this morning.
I also think there's a certain '90s movie with Keanu Reeves that also applies to the situation. You see, if you're traveling across the situation and you find yourself burdened down with any kind of problems, and you have this desire to start, but you see all this uncertainty, doubt, and anxiety ahead, it might cause you to freeze. The answer here is to speed up. You have to build on what you know to overcome that gap of uncertainty, doubt, and anxiety, and then rely on clear goals and metrics to land in somewhere that is actually delivering value back to the product and back to the business. You have to go fast, and there's a couple of reasons that you might not be able to do that. Usually, it's because you're lacking either the question, or you're lacking any context of how to answer the question itself.
Here's where you need to start. You have to build on what's known. You have to build on the context that you already understand and rely on that to be true. I want to share a story with you about a time that I found myself working on a product with a team, and we encountered a little bit of ambiguity, and it caused us to freeze. We had everything that you could want in the world. We had executive sponsorship, we had funding, we had runway, we had a large purpose, but the place that we had to start and why we had to start there was unclear. And that story starts with car washes. Car washes, of course, one of the top forms of drive-in entertainment ever for humans, kids, dogs, cats alike, but it started with car washes. And the reason it start with car washes is because we were proving out the idea of a reverse marketplace.
And for those that aren't familiar with a reverse marketplace, it looks a little bit like this. Most marketplaces place the seller in the middle of the equation, and the buyers come to the seller to receive goods. In this situation, we had the buyer in the middle. A reverse marketplace puts the buyer in the middle, and different sellers come to the buyer with options on what they might choose to buy from. In this case, we were looking at a reverse marketplace modeled after people looking to get car washes. The idea was that the concept of a reverse marketplace could be proven out with something as simple as a car wash. Now, when you have that kind of a problem, and you're looking through, "How does this actually fit together," you have some questions that naturally come to mind to try to sort of clarify that situation. Well, what would the car owners think?
How do they think about their car washes? How many car washes are there out there? And really, how many car washes are there? But really, should we focus on car washes at all? Is it even the right question? And before we wrote any code, and before we wrote any stories, we realized that we really needed to answer the question of, "Is this the right idea to move forward with?" And so what did we do? Well, we picked up this classic divisive technology, the phone, and we made a list of car washes. And we split up the list among the team, and rather than try to solve, "How are we going to build this reverse marketplace? How is this all going to work? What stories... Where do we start," we instead answered a very simple question of, "Should we even be doing this?"
And so we took the phone, called someone, "Hello?" "No." Just, "No." Started talking, was just told no. All right, well, that was a good shot. Pick up the phone again, give another call. "A what?" All right, so we're 0 for 2 now. We've called a couple of people, but maybe a third person will be interested in people that are driving around being able to get a car wash whenever they want from an app on their phone call. Call again, "You know they're in cars, right?" The market wouldn't bear the idea. And instead of writing a bunch of code that had to prove that out after it was shipped and then realize after the time and effort had been sunk, we, fortunately, had only invested a few hours of pulling up a Yelp page and calling a couple of car washes, then having a conversation as a team.
We overcame an ambiguous situation not by just sitting there and trying to break down all the problems and coming up with an elaborate user research plan and validation study, and doing a market analysis of reverse marketplaces. We simply took the smallest but attainable question that we knew we could answer, "Would car washes even participate," and then we sought to answer that question. Now, the next stage of this became a conversation about everything being important of the idea. Now, you'll hear this a lot in product. People will say, "Everything is important," and it isn't. It can't be. Everything can't be at the same level of importance. But when you hear that happening, it's a sign that there's actually a different kind of ambiguity happening. It's a kind of goal ambiguity.
The business doesn't necessarily have the cleanest line of sight into its goals for why it wants to pursue a product, or why it wants to pursue a direction. And when you encounter this kind of goal ambiguity, it's important to break down the problem in such a way that the business can then begin to ascribe what actually is important. Now, when you talk to product managers, and I'm sure product designers as well, a pretty common way to talk about this is, What do we do first? What do we do second? What do we do third? What did we do fourth?" And anyone who's gone through an exercise like this usually sees the breakdown actually ends up looking more like this, where there's a lot of things to do first, a couple of things to do second, I guess there's some stuff to do third, and well, nothing's fourth because we all have to do it. We have to do all.
And I think this is because whenever you're dealing with an ambiguous situation and you start any kind of prioritization that's objective like this, you're also bringing everyone else's previous experiences with that problem for a second, third, fourth to the equation, and so they have a harder time mapping an uncertain situation to those buckets. And out of fear or anxiety or uncertainty, or even doubt, they push everything to the middle at the front, because they know if they get all of it, then some of it's going to stick. Rather than have the conversation this way, we broke it down into buckets that probably hadn't been thought of before. What do we have to do now? What do we have to do soon? What can we do later, and what do we know we have to take care of someday? And when you're working on a product, and especially with a new team or especially working with stakeholders who may not frequently be involved in the day-to-day effort, you can create a stronger foundation for conversation when you have that kind of goal ambiguity by breaking down the problem in a little bit of a softer way.
You can also do this with a 2x2. You can rank everything from what is clear to unclear, and then you can understand where that tracks on a scale of having value to having potential. And for the things that you know, the things that are clear and the things that are valuable, those are the problems that you can tackle now. For the things that are clear and they have potential for value, well, you tackle that later. The things that are potentially valuable but also unclear is the category that you could pretty reliably ignore. You don't have to worry about it. And when you begin to remove segments of information from the parts of an ambiguous problem, it actually makes it easier for you to break down that problem, and it makes it easier for you to move forward.
And so what you do once you have it in these categories is you then break everything into known features and various hypotheses that you have for how to move forward. You have a set of features, you have a set of hypotheses, and now you can prioritize each of those independently. When you take the top few of each, that forms a discovery backlog. That discovery backlog allows you and the team to then work through each of those items of feature validation, and also disambiguating business requirements, or potential business solutions, as you would stories in a normal backlog.
And to do that effectively, you break that down into smaller tasks. And it's important, especially when you're dealing with ambiguous situation, is to break it down into the smallest possible tasks that you can answer, like we did with just calling the car washes. When you break something into a small task, it eliminates a lot of the variables in the situation and allows you to focus on achieving that specific goal. Also, when you have a lot of smaller tasks, it allows you to make a decision more effectively. There's all this possible data, all of this possible direction, all of these possible things that you can prioritize, but to understand the scope of the impact of each decision, you have to be able to understand those variables. And when everything's in a smaller piece, when everything's in a smaller segment, it's much easier to take that on. It's also important in these situations to openly and plainly talk about the ambiguity and the risk as a team. Understand that you're all a little bit uncertain, and that's okay.
That collective admission of an ambiguous situation creates trust, and that trust provides courage and sort of the fuel and momentum you need to move through the situation. Now, what if it's a little bit more unbounded? You don't know the question or the answer. The situation is limitless. You're in a situation that's like baseball without fair and foul lines. What if there was no foul line in a baseball game? How long would a baseball game go for? But then if you don't have fair and foul lines, you don't have home runs either, and that becomes a very different game. Or imagine playing hockey on a wide open lake, and you're just skating around a lake with sticks and a puck. Now again, probably a pretty good time. I personally can't ice skate, but I bet it's a good time. Probably not a very dynamic game of hockey. There's probably no score.
And how do you golf on the moon? Okay, that one's pretty cool. That one's pretty cool. That's Alan Shepard golfing on the moon. But still, there's no hole. All he could do was hit the ball into space, which again, objectively cool, but you can't come under par if you're golfing on the moon. And this is because those situations lack constraints, and those constraints are what provide the drama. They are what provide the excitement. They're what they provide the energy behind those sports. That framework, that sort of context, the things exist within, that is what drives the excitement of being a fan, that drives the satisfaction of being a player and scoring the goal. And so the same applies for when you're working with a product. It's really important that you identify your constraints. And you have to understand if the constraints are baked into the problem themselves or there are limitations that you have of your execution effort, or it is a problem with the business constraint.
Whatever that constraint might be, you have to understand what those are. And when you don't have those constraints in place, or when you don't understand them, it only fuels your uncertainty and fuels your inability to act. And so in the absence of having constraints, you can also create them for yourself. And you can say, "Okay, let's assume based on our understanding that these things are true." And when you assume based on that frame set, that how do you move forward? And here's a way to sort of talk about what that system might look like. So within any system and within any context that you're trying to sort of have the constraints on, it's constrained by a few things. First, it's constrained by the people in it, and the people in that system are governed by a set of rules. And with that set of rules, those people then have a set of tools that they use to accomplish a series of tasks that's a division of effort.
And within this larger system, there's probably some key journey that is taking place, and that key journey is the user trying to get an outcome. I like to actually draw this diagram in the corner of my notebook when I'm talking about a new product, and I draw it right in the corner, and I just put a little check mark when I understand each of these things. How do you understand each of these things? Well, a system is something like a carpool. That's a really great example to understand this framework. In a carpool, the people involved are the people carpooling. The rules are show up on time, and we're going to listen to the radio at a certain volume. The division of effort is everyone takes a turn driving every week, and the tools involved are a car and maybe a spreadsheet to track things.
The key journey is getting people to work on time, and the user in this case is the person driving the car. And the outcome is everyone's arrived, and we have less cars on the road, a very admirable goal. Now, what happens if one of these things is missing? What happens if you don't know the tools or you don't know the user, or you don't know the outcome, or all you really have is a key journey? This is where you can deploy aspects of design thinking like research, service design, and solution design to break down the problem into manageable pieces. You can understand the people and the tools they're using by doing contextual observation or by doing user research of the situation. You can understand the division of effort, the rules and the outcomes of the system by engaging in services and understanding the larger problem.
And if the whole system feels like it might be broken, or maybe it's being approached in an unclear way, then that's where you can leverage solution design to rethink the foundational aspects of the problem itself. And on these specific topics, I feel like I could probably talk for 20 minutes each. Luckily, there's already recorded Full Stack Fridays on these subjects, and we'll link to those at the end of today's session. The key to this, though, in any situation like this, is to plan for ambiguity and assume it's going to find you. It's not possible to navigate any situation without ambiguity. Think about planning what you're going to buy for groceries, limitless possibilities. What's going to happen when you plan a party? What's going to happen when you start to make plans for what to get somebody for their birthday?
They all start as ambiguous situations. We deal with ambiguity every day, and for a lot of those things, we already have general plans for how we address them. But there could be situations where they're a little bit wider, a little bit more uncertain. And what makes those easy for us is we've dealt with them before, and we go back to our plans, and those plans carry us through. So for us and the team at Devbridge, for different kinds of engagements, we've broken them down to really three categories of ambiguity that you might encounter. There's ambiguity in the viability of a product, there's ambiguity in the feasibility of a product, there's ambiguity in how the system will respond to that new product being introduced. And for each of these different approaches, we actually have developed flowcharts, and it's very vanilla, a flow chart, but it's classic. And these decision trees help us understand how to navigate these ambiguous situations. And with each of these different situations, we have assets ready for the team to take on the problems that they're going to encounter.
So let's say we're working with a team to determine a product's liability. Is this actually something that should be built or has the potential to make the impact on the business that people expect? If there's a value proposition, easy, move forward, let's roll. If there's not, that's when you enter into a period of discovery and definition, discovering the product, defining its constraints. And through prototyping and technical exploration, you begin to answer, "Is there really a product here?" And it's okay if there's not. Sometimes an ambiguous situation, it might seem like there's something there when it isn't there at all. Admitting that and understanding and coming to that conclusion quickly, realizing that part of the decision quickly, is a very, very powerful and valuable thing.
We have playbooks ready for the team, how big the team should be, how long they should plan it, what their outputs are going to be, a rough schedule for them to follow, every week breaking down what needs to happen to actually validate that product's viable or not. And then having a key approach to breaking down that problem over time and carrying that execution through to actually delivering the product itself. And I think what makes this process successful, what makes any playbook like this successful because it's a recipe in some ways, is bringing people along on the journey with you. And that's why even from things like sketching out various ideas or breaking down problems in a design charrette, or any sort of design sprint-type activity, it's very powerful, because these acts of co-creation disambiguate the situation for everyone.
And if some people have certainty and other people don't have that certainty, that's where you create a disparity. And in that disparity, that's where you have anxiety and tension, and that tension can make it harder to move forward with the product itself. That's why it is so important to take everyone on that journey with you. Now, there's a framework that I like to try to break down these kinds of situations to bring other people on the journey, because it's not always possible to have everyone in the room. I want to give a shout out as I get started with this to Ryan Rumsey in Second Wave Dive. This is kind of a riff off of the framework that he shared on how to break down problems and share them with executives. I think that the first thing that you have to do is you have to frame that opportunity. And when you frame the opportunity, you have to frame it in terms of what it means for the business, what it means for the product, and also what it means for the team that's building it.
When you're summarizing these efforts, you pull it all together in one central location. The next piece that you need to do is break down your objectives. What are the three objectives, the four objectives tops, that you have in engaging in this effort to disambiguate a situation? Every one of these objectives then need to have a specific plan and outcome associated with it. And you nest those planning outcomes with that objective itself, so everything flows through and you're taking people on that journey with you. Once you have the plan and outcome, that's when you get into sharing what the specific impacts are. You have an impact on a product, you have an impact on the business. Either way, you share what that anticipated impact would be and what you've learned from those discovery efforts. Finally, once you have those pieces in place, you're able to actually propose that scope and that path to delivery.
And what you're doing here, rather than having a series of slides that are all walls of text, is you're showing the artifacts and you're showing the pieces and elements of the process that brought you to this place where you have this understanding. You're showing that yes, we were uncertain. We made a plan. And from that plan, we generated outcomes that then became these impacts that we can create, and here's the cost and benefit of addressing those impacts. Ambiguity doesn't have to be scary. It doesn't have to be this thing that freezes action. I think for me personally, there's this quote by Marie Curie, and it's really sat with me ever since I heard it. She's like, "Nothing in life is to be feared, it is only to be understood. Now is the time to understand more, so that we can fear less."
And it shows that really what it's about is building that understanding, and seeking that understanding and fearlessly chasing what that truth is, and then embracing that truth. When you embrace that truth, you're able to form unique insights that become wisdom, that become the kernels of a unique opportunity that become market differentiation. You don't get distracted by fantasy or conspiracy or imagined problems or villains. You're dealing with reality, and you're able to do that because you don't give into fear. You embrace what needs to be done, and you take action. You're moving forward because you have the tools that you need to act with certainty, and you have those tools because no problem is really too big to encounter. There's different frameworks that you can use to break these down.
When I first came up with this framework, and it's evolved over time, it came up just in conversation. And we said, "Well, let's try looking at the problem this way." We came up with it as an experiment, and it's through that experimentation that you're able to navigate through ambiguous situations. When you break down a problem, you're able to fully understand how to address it and then validate everything that goes into it to have confidence in how you act next. When you break down a system into its people, the rules they follow, the tools that they use, their division of effort, you really understand how people undertake a key journey in that system and what responsibilities there are for the user and what outcome that system is going to create. Understanding that system and locking down variables is a powerful way to move forward when you feel like you might not have all the constraints you need to make a decision.
Always have a key playbook of decisioning trees in your back pocket for common scenarios that you might encounter. Having a set playbook to fall back on allows you to focus on executing the place rather than trying to encounter every ambiguous situation as it arises. The key to it at the end of the day is that you got to go fast. You can't overcome those hurdles. You can't overcome those gaps in understanding without embracing and generator that momentum and bringing other people along for the ride. Now, if today's topic was interesting and you want to dive deeper on it, I really recommend these two talks that we have on devbridge.com/full-stack-friday. The first is one that Aurimas did on product-centric funding and how to incentivize business outcomes. When you think about ambiguous situations, they often present themselves in that funding cycle. This is a great talk if you want to get into more of the business side of this problem space.
The other thing that I mentioned a few times is the importance to have data and metrics backing up your decisions that you make, and I have another talk up there on data-informed product delivery, also with the space theme coincidentally, talking about a time that I went to see the total solar eclipse. I think that any time that you're trying to navigate a situation that you're not certain about, there are a wealth of resources out there that you can pull on for help, including myself. I'll share my contact information in a moment. But really relying on your network and also relying on trusted partners to execute through an ambiguous situation is a really valuable and powerful thing, especially in bringing in that new perspective.
Now, one of the things that I talked about a couple of times today is the importance of going fast as a concept, and our next Full Stack Friday is going to be coming up here in a few weeks. It's going to be September 18th, and our managing director, Raymond King, is going to be joining us from our London office. And he's going to be sharing a breakdown of really, what does it mean to go fast? And what does it mean to understand speed for product delivery, and what does it mean to understand that speed and that velocity in terms of generating results? So I want to thank everybody for joining us this morning for this Full Stack Friday. I'm going to go ahead and open it up now to questions.
About the event:
Full Stack Friday is a monthly meet up hosted by Devbridge where we share insights on product development, design, and process. The talks focus on issues relevant to product people and full stack teams. For more information about the next event, contact us directly.