Beyond The Prototype (with Douglas Ferguson from Voltage Control)

Read The Transcript:

We’re trying out transcribing our podcasts using a software program. Please forgive any typos as the bot isn’t correct 100% of the time.

Ben Aston

Design sprints are potent. In just five days, you can use a design thinking process to uncover insights, prototype, and idea and then test it with users. But what next? Now what? That was a great process. It seems to show some potential. But where do you take your prototype from here? If you’re not careful, nothing will happen.

It was fun. It was revealing and maybe inspiring. But taking the next step can seem sometimes daunting. Momentum can come to us often. So how do you actually bridge the gap between exploration and launch between ideas and outcomes? Keep listening to today’s podcast to learn about a six-step plan you can follow after a design sprint so you actually release something into the wild.

Thanks for tuning in. I’m Ben Aston, founder of the Digital Project Manager. Welcome to the DPM podcast. We are on a mission to help project managers succeed, to help people who manage projects delivered better. We’re here to help you take your project game to the next level. Check out thedigitalprojectmanager.com to learn about the training and resources we offer through membership. This podcast is brought to you by Clarizen, the Leader in Enterprise Project and Portfolio Management Software. Visit Clarizen.com to learn more.

So today, I’m joined by Douglas Ferguson, and Douglas is an entrepreneur. He’s a human-centered technologist. He’s the founder and president of Voltage Control. And he’s the author and co-author of three books, How to Remix Anything, Start Within, and also Beyond the Prototype. That’s what we’re going to be discussing today. And that’s about a roadmap for navigating the fuzzy area between ideas and outcomes. So, Hello Douglas, and thank you so much for joining us today.

Douglas Ferguson

Thank you so much for having me. It’s great to be here.

Ben Aston

And we are on a Friday afternoon and it is getting hot in here. So we’re at the end of the week. But let’s finish this with a bang. I want to find out a bit about your story and how you got into design sprinting and why you think this is interesting and useful and applicable.

Douglas Ferguson

Well, you know, I think every component of my history lead to where I am. Like, I feel like they’re stepping stones all along the way. And I guess I’ll start by saying that early in my career, I was a software developer and I got into leadership. And as a sovereign developer, I was always really curious about the intersection of technology, the market, and design, and so forth, function, feasibility, desirability, all those things were kind of forefront for me.

And so as a leader, I typically was really not only focused on how we’re going to go about implementing it technically, but it’s why we should build it, what exactly we need to build and how it comes to life. And and and so that involved a lot of really understanding the process that we use to build software and how we get teams working better together and, you know, design processes, etc.

And so whether it be agile, lean, etc., we were dabbling in experimenting with it. So I caught onto Jake Knapp’s early blog post and we were trying to design Sprint’s my last startup, and then Google venturers invested in the startup. And so Jake and the design team at Google got to come down and work directly with us. And so that first-hand experience watching them, the Masters of design sprints had done hundreds of them who had created the process and adapted it, you know, numerous times was really eye-opening.

And I think that experience lead me to have opportunities to run them for other people because they saw that I worked directly with the inventor and they said, hey, come show us what you learned. And then those experiences led to other experiences to where I’ve run hundreds of design sprints for folks.

And now I have even started to, you know, over the years, stitch together many other different disciplines of facilitation. So to build an even broader practice. And so we’ve developed our own workshops and we continuously in search of new methods and new even modalities to bring in. Because there are so many silos out there, we’re really interested in supporting the broader facilitation community and bringing all those silos together.

Ben Aston

Cool. So in terms of bringing their silos together, are you talking about design thinking, meets service design, and meets lean or what? What are you talking about?

Douglas Ferguson

Yeah. So, gosh, there’s facilitation frameworks that are rooted in the architectural community. So certainly these MG Taylor is one example and architects have for years done charrettes and types of things. So they have ways of bringing people together. They make decisions and collaborate. There are things in the social justice space. There’s the art of hosting. There are relationship-building frameworks like authentic relating.

There are certain methods of design thinking. There is another industrial design type of critiques and different tools that people use. And so those are the silos we’re talking about, because usually when someone’s introduced to ways, a meeting to ways and making decisions, they usually especially if they resonate with those things, they will tend to go deep. They will tend to really identify as part of that of part of that movement if you will.

And there’s a real risk of becoming dogmatic because that because it’s easy to fall in love with the thing that opens up new possibilities for you. But we also have to equally unlearn those things and realize that, like, there are different ways of doing it. And not everyone was introduced to this way of thinking in the same way you are. So is being more of a growth mindset, like what will how else can we apply this thinking, and what else is there out there? That’s kind of what I mean by busting the silos. And it’s a bit of a chocolate peanut butter type of thing.

Right. How can we come up with these new combinations of things to really elevate the experience that was or were created? Because ultimately, if we think about our meetings and our collaboration sessions and experiences and we apply some service design type of thinking and even like a learning experience, design techniques, we can really elevate those moments and get even more business value or more much more momentum out of them.

Ben Aston

That’s cool. And so in terms of your role at voltage control, you’re in your day job. What do you what do you actually what do you actually do?

Douglas Ferguson

Yeah. So, gosh, as the founder and president, I end up doing almost everything. So, you know, every day is a little bit different. Some days I’m facilitator, so I’m still actively engaged in the execution of workshops. So I might be designing a workshop or facilitator. I might be training a group of people on how to do this works or some training on how to facilitator or how to apply learning experience, design principles to your workshops. Or I might be coaching someone one on one or appear on a lot of podcasts for the book. I’m actively writing another book and you know, some as I’m preparing and writing content for our website and blog.

And then I started my own podcast. So some days I’m recording for that as well. So it’s quite a mixture of things, you know, still involved and sales and marketing and client management. So sometimes I’m sending out thank you notes. So. So it’s quite a bit of thing. And we’re still on the grand scheme of things for a small organization. So even though we started to specialize a bit, everyone’s doing a lot, a lot to kind of keep things on track. And, you know, I think the whole team is really skilled and everyone kind of contributes in all the ways they can.

Ben Aston

Awesome. And so what are some of the challenges you’re dealing with right now? You’re still executing workshops. You’re bringing together people in your teams, your I mean, you’re always very broad there. But what are some of the big challenges that you’re having to deal with?

Douglas Ferguson

Yeah, you know, gosh, there’s a chorus like we’re in a pandemic that creates a set of challenges because we had to retool everything to be virtual. And we were a remote team. So we were no stranger to the tools and methods and approaches for working with the distributed team. However, our marketing, a lot of our products were not dialed in and tuned to work in that space, that environment, there are a lot of methods and approaches that we use that quite frankly, you just assume that we were in the same room.

For instance, cadence and turn-taking take on a different life altogether and the virtual space. Also, agendas have to shift. Timing is completely different now when we’re talking about designing for the virtual space. So there’s a lot of principles that we still apply. We can still lean on the purpose that we brought to the situation. But we have some new constraints we have to consider—and new opportunities for that matter. That’s another big challenge that is managed just operationally.

The logistics around what we do can be quite challenging. And so as every time we bump into another level of scale, there’s this extra complexity from managing quality and follow through and delivery and making sure those things happen consistently and in a way that is representative of, you know, the experiences we really want to deliver for our clients. And so that’s something that I spend a lot of time worrying about and planning for the future.

Ben Aston

And so, as you’ve yet made this transition from your real-life workshop, dilatation to taking it virtually, hey, it is great if you could expand a bit on thinking through. Everything going virtual, everything becoming remote for everybody.

How is that a change in actually adapted the process that you use and the tools that you use to do that? I’m curious if there are any adaptations you’ve made to the process itself and if there are any tools that have facilitated that or actually that you’ve dropped using because you’re having to work in this virtual room world.

Douglas Ferguson

Yeah. You know, there’s certainly some tools that we continue to use. Session Labs, one of my favorite tools. That’s a tool for planning schedules and agendas. And, you know, maybe we use it even more, especially because we’re redesigning some things that we had already had in place and that had already we’re working really well for us. And so now we have to reimagine some of those things. And so it’s coming in handy, handier now that we’ve had to rely on it more.

The other thing that I think has shifted a bit is our use of Miro. So we have these virtual collaboration space is even more critical now because we don’t have Post-it notes in the room with each other. So that’s important. And also, you know, heavily using Zoom breakout rooms. And, you know, I think Cisco, WebEx, Trayner has breakout rooms support. And, you know, some people have successfully used Google meet. I think there’s a browser plugin that going to mimic some of this capability. And Microsoft teams. But with both of those examples, you have to basic you have to create all the extra rooms and then you can’t remotely move.

You can’t remotely move your participants in and out of rooms like you can’t with Zoom or WebEx trainer. And because of that, we’ve developed some of our own tools because there are some things that we do live in person, some games we play that that require a certain mode of interaction and the tools, systems support it. And so we create a tool called control room that we use. And we’re currently working on some breakout rooms support because one of the issues with the existing breakout tools solutions is that especially if you go if you can go with a conference room tool like a hop-in or an on 24 or air meet, then those tools are really designed to try and mimic the hallway conversations and discern into this interaction that kind of happen.

And so you can do breakouts, but the breakouts are going to be very loosely controlled. And then inside of a Zoom, they become very tightly controlled. And these tools are very opinionated on tight and loose, and none of them support both. And if you’re going to do a really high lead facilitated with intention and purpose session, then you want to be able to move quickly between tight and loose, because there’s going to be moments where I need to bring people together for a plan every session and maybe explain some things and then send them off.

They’re going to be sometimes where I want to put them in a group and then, you know, a group or two and they be merged, those groups of two and a group of four. And that, you know, that’s tight control, but with loose direction, they can explore and maneuver within that tight control. Other times I might want to do an open space where I set up different affinity groups and people can go to their place of their choosing. And so we’ve really found the challenge and the lack of versatility—the tools are opinionated and they’re simplistic in their view. And so we’ve had to build some of our own software to work around that. And there’s still lots of room to grow. We’re still not 100% there. But I definitely say we use Zoom and Miro quite often. Session Lab is really handy for making those agendas, too.

Ben Aston

And as you all doing things virtually I mean, your role as a facilitator then becomes quite administrative as well as your figuring out. Okay, let’s break up in groups of two and then you’re kind of doing it all, say, does it require an additional role to do all that kind of functional facilitation rather than just the I mean, that’s making the decision let’s break up in groups of two and now setting that up in real-time. I mean, that’s quite a work. So how do you manage that? Virtually.

Douglas Ferguson

Yeah, you know, it’s if the tools were easier, it wouldn’t be quite as daunting. But I can tell you, especially if you’re emerging and expanding groups and things like that, it’s very time-consuming. And because of that, we usually recommend having two facilitators, which is kind of a conundrum because a lot of times people come with the expectation that virtual is gonna be cheaper for some reason. You know, my response is always like, well, it is cheaper because you don’t have to fly anywhere. You don’t have to rent a room, you don’t pay for lunch, etc.

But it actually requires more labor. And sometimes we manage to pull it off with one facilitator. But you have to have a very understanding crowd if you’re gonna do that, because if you’re really focused on, you know, during the production aspect where you’re moving people around, then you’re not going to be holding space for the participants. Know it’s going to be difficult to read the room and to comment and do the kind of verbal facilitation and kind of stuff. And so because of that, we really recommend having two people, you know, one, the production staff is not always is not really a full-time job, per se.

So usually that the second facilitator is potentially a scribe as well. So they might be capturing all the things that are happening. So we make sure nothing’s lost. Sometimes it’s more of a tag team kind of effort. So you might have two facilitators that are kind of equal masters if you will. And they just kind of trade-off. So it’s like, hey, I’ll launch this breakout room because you’re gonna be leading this module. Then I’m going to lead this module. And the end, you know, so and then we have this extra burden of chats and these other distractions and things. So having another person who’s on the lookout for that stuff, what we call reading the room, is really critical.

Ben Aston

Cool. Well, let’s dive into talking about what Next after the design sprint and to set the scene. We’ve been talking about facilitated sessions and many of these kinds of activities that we talk about would happen within the context of what was mentioned earlier as a design sprint. So if you haven’t checked out Jake Knapp’s book Sprint, it’s an amazing five-day process for idea generation and revolution in which you uncover insights. You prototype something, come up with some ideas. Choose the best ones.

Test them with users. And then by the end of the week, you’ve come up with something that’s been validated. And I’ve been involved in a few sprints doing everything from the future of lottery and what that looks like to something quite tactical, the future of a Web site. So if you’ve not done one yet, you should you can come up with loads of ideas in a really short amount of time and actually validate them within a week.

So as a process, it can be really helpful for IT generation and getting to a point where something is validated. You don’t just come up with the ideas. You don’t have this situation where clients kind of throw their weight around coming up with ideas and choosing their own ideas. Actually, it gets validated and vetted, which means the quality of the ideas at the end of the week that you get to a normally much better. But what you actually do Next is tricky and well, it depends on the situation. But a guide would be nice. And so now there is one.

And if you say for anyone who hasn’t read Douglas’s book and you listen to this, the book is called Beyond the Prototype. And it’s a roadmap for navigating the fuzzy area between ideas and outcomes. So I want to talk about this problem, though, that you see and obviously this is why you write the book. So for anyone who’s unfamiliar with design sprints at the end of day five, it’s normally Friday afternoon at this point. Where are you? Where are you Left? And you talk about the post sprint slump. What is it and why does that happen?

Douglas Ferguson

Yeah. You know, there’s a lot of reasons why it happens. I think that the thing that folks should keep in mind most is that the design sprint is atypical of how most projects unfold. So most of the time, we build momentum gradually over time. And then and often we would build it, lose it, build it, lose it, in little spurts. And then and then there’s a deadline that’s looming. And then we just like really, really haul at the end to get it all done. That’s a fairly common scheme. Right. Or maybe it’s fairly linear with some little bumps along the way. And so when we flip that around and we gain a ton of momentum upfront, that can be really disorienting and unexpected. And so, first and foremost, people need to understand that this will happen, that we’re going through a design sprint is going to yield a ton of momentum.

And if you’re in a big company and you don’t know what that feels like. And you never saw this before. You’re going to be standing at the top of the mountain going, whoa, how did I get here? And then it’s going to all slowly slip away, like air seeping out of an inner tube. And so we don’t want it to go to waste because we magically got all this progress. Let’s make sure we make use of it. And so if we and if we don’t start making use of it, we just like we just lose it, lose it, lose it, lose it. And then we get into this mindset of like it’s almost like the depression, right. It’s like, oh, we knew what it was like to be up there, but we’re not up there anymore.

And it’s like much harder, Dad, to get back up to make use of this. It’s sort of like, you know, you could jump off of the hang glider now or you could just like slowly, you know, just walk down and then try to use the hang glider like, you know, three-quarters of the way down the mountain is like not going to be as effective. Right. And so the book’s really about how do we harness all that energy we built upon the bus? The best thing to do is just to know that it’s gonna be there. And then there’s a lot of upfront work we can do to set the stage and make sure that we set initial conditions for the design sprint to be successful.

And one of those initial conditions is understanding that this momentum is going to be there and we should be ready for it. And one of the things that people struggle with is thinking that the design sprints everything right. There’s a ton of talk about how magical it is how awesome it is. And the reason that people get that excited about is because of all this momentum you can build. Well, the irony of it is like if you just build it up, hype it up and expect it to be the deal end or you’ll walk out and then not there to harness the momentum it does create because you don’t anticipate or prepare for the work that needs to come after.

And so absolutely not the be all end all. There’s gonna be work to do after to take this thing through. And sometimes, you know, it’s about making sure that we preserve resources, whether that’s money or people or time. And then also another thing I see people grappling with is not knowing who’s going to own it, because innovation can yield brand new thinking. And if we don’t have a vice president or her department to support whatever this you know, we have a Matrix organization and then we invent some new thing. Then there may not fit on a matrix neatly hand. So who owns it? And so that could be a conversation that needs to happen. And so preparing for these things ahead of time and anticipating them, knowing that we’re going to need to address all of these things can go a really long way.

And then, of course, there’s a lot I mean, there’s tons of tactical stuff like making sure we pick the right decider, which is a role in the design sprint. That’s is maybe one of the number one reasons people can’t harness the momentum is because they come out of the design sprint and the real decider rears their head and shuts it all down. They say, hey, like, why did you decide to do that? I mean, why weren’t they on the room? So if they’re gonna be the one calling the shots, they need to be in that decider role.

Ben Aston

Definitely. Yeah, I’ve I think what you’re talking about here. I mean, I’ll go over the steps and your steps are for this roadmap. Well, firstly, wrap it up. Share your story. Chart the course. Expand the inner circle, cultivate the culture and get guidance. And the first two steps of that process. I think it’s something that we can do ahead of time. Right. So I think sometimes when we’re planning a design spent so much effort goes into planning the sprint itself that we don’t think about those next two steps, how we wrap it up effectively, how we share the story of what happened in order to create the credibility to BI the mandate to continue the project or continue the initiative. And I think an important takeaway for us is as project managers, as we’re thinking about, okay, how do we give life to this process and extend its shelf life beyond the week? Well, I think it’s to be thinking about it.

And I love what you talked about, thinking about the resources that you need ahead of time. And I think it can be really hard to plan a designed sprint because of the number of people that you need to get involved to get the clients and the stakeholders and the decider in the room for a full week, as well as all the resources on your team. It can be super tough. And I think sometimes if we’re just focused on that week and we don’t think about, okay, well, what about this next week when we’re wrapping it up and we’re sharing the story to show what we accomplished and why that’s important if we haven’t thought about that as part of the project. We’re kind of shooting ourselves in the foot because we’re not setting ourselves up for success, for the implementation.

So thinking about this step three, which is we’ve had to up we’ve kind of shared our story, charting the course for what happens next. Now, at the end of the design sprint, we come out with some validated ideas. Ideally, the user testing that we’ve done has been successful. And we’ve got some really good insights on some ideas. So what I want to kind of dove into a bit more is how you then effectively chart the course. And there are different ways of doing this in some ways that I’ve been involved in is that we then go into another design sprint and all. We actually go into our parallel workstreams of design and development or whatever that that might be that we’re building. But how do you then take these ideas that come out of a design sprint and transform it into something actionable or a roadmap for development in a way that makes sense?

Douglas Ferguson

Yeah, you know, I think this is a really critical topic and one that’s not discussed nearly enough. And, you know, I was hoping that you could write an entire book on, you know, how to how to even package up ideas and the results of ideation sessions for agile projects specifically. And so this chapter highlights a few of those things and talks about the mindset that you need to take to that. And then the next version of this is expanded quite a bit.

The thing that I love the most is this notion of milestone moments. And, you know, for instance, if you’re trying to learn, you’re trying to learn Spanish, you know, you don’t want to say I want to become fluent in Spanish, set these intermediary goals so that you can have little victories along the way. And these little victories can be celebrated. And you can reward your progress. And it keeps you engaged. And so if you can take that same philosophy to your project and then look at where the destination as you see it today and think about what are these little moments that we can hit along the way as. And think about waypoints.

And as we’re hitting those moments, we’re kind of reassessing. Is our destination still correct? Are we on the path? And and and allow that to guide the flow of work going forward. And so that can be an interesting way of thinking about organizing the work that you’re doing in a way that’s not dissimilar from agile. And so the fact that as we’re exploring these next steps, you’re already starting to kind of mirror some of those behaviors. But maybe in a looser way, we’re not quite as stringent on this kind of like, scrum kind of stuff. But we’re starting to think about what are these milestones were hidden and some of these things where we need to understand in order to really pack it up for the product team.

Also, you mentioned, you know, a follow on a design sprint. So there’s like, you know, people talk about the iteration sprint. There’s you know, you could certainly iterate through multiple design sprints, even just thinking about, you know, whether you might do it might be necessary to do a cup or in parallel and then. And then and then do them together potentially to kind of explore some other territory, because design spreads really, really targeted insight on a specific goal.

And when you’re doing these iteration sprints or these kinds of parallel nested sprints, you can also shorten them and rely on some of the work that’s already been done. And then the initial sprint, which can be can be helpful because, you know, we still want to follow some of these approaches and some of these methods that we’re that we can find success on. We just don’t need to necessarily all the steps now that we’ve gotten some momentum and we can kind of repeat some of the considerable parts of the design sprints early thinking about how we might design some meeting systems and some workshops that will help us kind of continue to learn and continue to borrow from that culture. Also, talk about sharing the ugly baby.

And, you know, we don’t want to. You know, similarly, we should have adopted this mindset of like test and learn, so we built a prototype and shared it with users. While we should be willing to share that with people regularly and continue to learn and continue to iterate. And also, you know, we want to make sure that we are thinking about our metrics and we communicate those metrics. I think often people get in trouble when they don’t take a moment to think about what is what are the critical components of success and how do we know when we’re going to pull the plug. And that can be great for setting expectations leadership, because if they start asking tough questions or you can say, well, you know, we’re not. We certainly haven’t seen success yet.

But we said we would pull the plug if this happened and we recurrently haven’t gotten there yet. So let’s our trust our plan and continue to map toward those metrics can be really liberating. Also, talk about user story mapping. And I think, you know, there’s a really fantastic tool from a product development standpoint. I believe it’s something that you can introduce really early into the planning cycle to help start to add a little fidelity to our understanding of all the constituent parts of what we’re building and kind of lay it out and a user journey type flow.

And it’s it seems like a fantastic start time to start doing that type of thing versus waiting until now. Now we’re full-on developing this and kind of almost seems like a lot of teams are doing it retrospectively, if you will, because they’re already in the flow of something and they’ve already started to build something and say, oh, we should be mapping this to figure out like our next sprint or whatever. And so before we even get started, it can be a really great activity to kind of prioritize and understand, like how we might cut, cut whatever the initial release might be. And then also can be helpful for identifying further experiments. We need to run before we start even cutting an initial release.

Ben Aston

Yeah, I think I think what you’re talking about here about generating momentum, keeping momentum, you know, and identifying those small wins to continue the enthusiasm and yet momentum for the project to a really key. And I think one way that one maybe you can do this, as you talk about in the book, is through user story mapping, thinking about the user journey and identifying what the pieces of functionality are on that user journey that we can create in order to optimize the experience. And it might be that as we’re developing the next thing after the design sprint is, is normally we going to be developing some kind of MVP and a really useful lens for prioritizing those user stories on the user story map is thinking through the feasibility, the viability, and the desirability.

So is it technologically feasible? Is it economically viable? Is it desirable from a human point if you do? Do people actually want these things? And I think evaluating pieces of functionality on that user story map can really help us drill down to the MVP. And I think really aggressive prioritization is really key for us developing the MVP. That is actually something that is going to be feasible, viable, and desirable, getting something out the door so that we hit that milestone of we released something. But can you talk through how you some of the prioritization techniques you use in establishing your MVP to get something out the door and to generate momentum?

Douglas Ferguson

Yeah, for sure. You know, desirability is a big, big component. When we think about prioritization, so when we’re doing the initial interviews with prototypes, we are listening deeply to gain insights into, you know, what resonates with the user, how they’re reacting to this, does it bring them delight? Does it get them excited to use the product? Does it solve a need for a problem that they seem to be desperately seeking to solve? Those insights usually drive prioritization and a very obvious way, like it’s usually super clear after having these conversations, what we need to prioritize and deprioritize.,

if we are kind of tied on a few things, then, you know, the old faithful Eisenhauer matrix is always, always handy prioritization over impact. And, you know, if something’s going to have a high impact, which we probably know from the interviews, then we can look at if the ones that are the least amount of effort so we can prioritize those first.

We also need to look at it from an offering or portfolio standpoint when we think about how features relate to each other and how they tell a story. For instance, if our product vision looks small and. And maybe. Not cohesive then. Then we might want to consider adding other things so that the user understands the vision because we were there. We certainly don’t want them to think to pigeonhole us or to think that we are we’re heading down a path that we’re not. So they can sometimes be a branding decision or a perception decision that might help us, like, round out the MVP and make it to make it more understandable, believable.

So my point is, is that there are maybe beyond just the desirability and the and the like that an urgent and sorry, that important vs. difficulty mapping. We also need to just think about the things that really sell or explain or allow the user to perceive things. I think that makes it that helps us dip into that realm of viable. Yes. So I think that can really help us on the viability front, because it what it does, it helps make the story understandable and relatable.

And so we need to make sure that people don’t stop using that because they perceive it to be something that it’s not or like that it’s that there’s not a lot of value. Even though it solves this problem, what’s the bigger problem that that sits with them or relates to? So just thinking from an ecosystem or an or a holistic standpoint, I think is important because sometimes I see NBP is getting lost. And in the notion of like, well, what’s the smallest thing we can build real? Does it make sense to build that? Does that, does it even like this? Does the like show the vision as it is as marketable? So what does that holistic thinking that we can apply to it?

And so I just I encourage people to to to think a little more deeply. There there are two other lenses we want to look at as well. We want to look at risk. So, like, where might we have assumptions or if we’re wrong about something? How might that blow up in our face? And if there are things that we’re looking at stuff or like, well, if we’re wrong about this, I’d be really, really bad. Well, it’s like, well, we better go like address that so we can go where you are to attack our riskiest assumptions first. And that can tend to really help with some of this prioritization.

And then the last thing I’ll say is, is there an opportunity to delight? And rather than just thinking of them, MVP as hey, here’s this really simple, brain-dead, easiest way, cheapest way, the most economical way to solve the problem. We get it out there to validate. Well, is there any way to add a little delight, a little surprise? A little joy? if there is, we should consider it because life’s too short. And users will always prefer to be delighted.

Ben Aston

Definitely. And I think I think your emphasis here on changing the mindset and I think like project managers, we’re very output orientated, we’re thinking about, okay, well, what are the things I need to deliver and how will I get to deliver them? I need to think about the budget and I think I need to think about the timeline and the component pieces so that I get my deliverables so that my outputs happen. I think the way that you’re framing this is a really useful mindset to be thinking about is that shift from outputs to outcomes.

Like, how do we actually see the change that we want to see? It’s not about necessarily creating the widget. It’s that is the outcome that comes as a result of us creating that. So are there other ways that we can get to that outcome and thinking about prioritizing for the MVP around generating an outcome rather than necessarily the outputs that deliver that outcome? Now, one of the things that I just want to touch on before we finish is your step in here.

The last step, which is all about getting guidance, knowing when to reach out to the experts. And I think this can be a tricky thing for people trying to source the right voices so that you don’t create too much noise within the project or the initiative that you’re working on. So what was your insight that you can give on knowing when to reach out? When does it make sense? And when should you kind of stick to your guns and just platform with what you believe in?

Douglas Ferguson

Yeah, I mean, that’s I don’t know. That’s a tough one, you know because so many I’ve seen so many people listen to interviews and then say themselves, oh, we didn’t recruit correctly. And then, you know, they’re disconsolate, making excuses for why the world doesn’t want to see things the way they see them. Yeah, you have people like Steve Jobs who somehow like distort reality.

My advice to people generally is, you know, that’s fewer and further between and. You know, you just know that you’re making a very, very risky bet. If you think you’re going to shift people’s behaviors in some way and, you know, if you feel super strong about it, you’ve got the money to burn.

To find out, you know, then maybe go for it. But in my experience, most people don’t have the money to burn. And most of the time, they are a sample set of one. And they are typically sorely mistaken even when. And I’ve gotten to the point where I’ve had to stop even trying to judge the stuff ahead of time, you know because I’ll often hear a founder with an amazing idea and the.

I get excited. You know, I like the sound score. This totally works immersion. And then, you know, a few months later, I bump into them again at the local accelerator or whatever in my house. I go and they’re like, oh, yeah, no one really wanted that. Oh, well, I hope so. I don’t know. It’s like I’ve kind of. I think the designs friends told me one thing and that is like, you know, we got to talk to humans and validate the stuff because no matter how smart and intuitive we are, we. We were gonna be missing something.

Ben Aston

Yeah. I mean, let’s talk about that. Where does it all go wrong? Like, where have you seen this unravel? We took it right at the beginning about momentum falling because there isn’t. It’s not wrapped up properly to show the story isn’t sold. Their course hasn’t been charted. And obviously, we have this problem as well where the insight is just not actually we might have validated it or thought we validated it, but maybe we didn’t validate it properly. So where do you see it all going wrong in that post sprint phase as people chart the course from designed sprint to MVP? Where did it most typically fall apart? What are the things to watch out for?

Douglas Ferguson

So. You know, it’s interesting because it makes me think of the the the later chapter cultivate the culture because that’s really kind of what you were alluding to, which is people don’t cult. They’re not cultivating the culture or the sprint mindset. They’re just kind of going back to normal business as usual. And so that can go wrong. Often I see people getting excited about the designs and getting people to clear, clear the schedules and they, you know, go and do the work and then they can come out afterward and, you know, just go back to the sprints they’re working on. Here here is the roadmap. And here’s the here’s the. The delivery cycle. And we have this due next week and this and that. And they go back to the factory, you know, making the widgets like punching the buttons.

And if we can adapt the sprint mindset and then by then and what we do with it, where do we start? I point out the methodologies, testing, learning, really continuing the prototype. Continuing to put that in front of users. I love this idea. Concept. If a picture is worth a thousand words, then a prototype’s worth a thousand meetings. Yeah. And so that’s you know, again, there are lots of things that can go wrong. But and the context of what we’re just talking about, the big thing is that they’re just not there is going back to business as usual.

And so if you do that, there’s little hope that that much is going to happen out of what you learned in the sprint because we have to continue to refine the prototype. We’re going to we got to kind of plan around this new project that’s unfolding. And we’re going to continue to learn because although we’ve got some cool insights, I don’t have them all. And there’s a lot more to to to discover about where the potential lies.

Ben Aston

I think that mindset is so important. I think that’s what’s great about the design sprint where you begin is unpacking. It’s understanding what is the what’s the background, what’s the situation? What’s the business challenge we’re trying to solve? How does that align with user needs met and unmet? And I think, yeah, if there’s one thing that’s super important in this process, as we’re thinking about what happens after the design sprint is to not lose focus on why we’re doing it in the first place. We’re trying to deliver an outcome. We’re trying to incrementally increase value. And it’s as we do that, that we will see some of the change happen that we want to see.

So, Douglas, thank you so much for joining us today. It’s been great having you with us.

Douglas Ferguson

It’s been great here. It’s been great being here. Thanks for having me.

Ben Aston

Cool. So I wonder what your hack’s tips and tricks are for design sprints and in that post designed sprint phase, what are you doing that works? what doesn’t work? If you have checked out Douglas’ book let me know what you think.

But if you want to learn more and get ahead in your work, come and join our tribe with DPM Membership head to thedigitalprojectmanager.com/membership to get access to our team templates, workshops, and AMA sessions, office hours, e-books, and more. And if you like what you heard today, please subscribe and stay in touch on thedigitalprojectmanager.com. But until next time. Thanks for listening.