The Venture Design Framework

We’ve talked about the importance of narrative collaboration and learning the right things at the right time as you move forward. One thing that we’re going to use throughout the course to help us with that is the venture design framework. And the idea is that we kind of go through loops with our product executions, where we want to make sure that we’re starting with personas, that we’ll cover a lot in the second module. These are humanized views of who our customer is. Then we move onto problem scenarios and alternatives. These are jobs to be done, habits, desires that we can observe and verify on the part of our user.

And this helps us make sure, we know that we won’t deliver something valuable if we solve a problem that doesn’t exist. And we likewise know that we will not deliver something valuable if we build for a user that either doesn’t exist or we don’t know who they are. Then we move forward to value propositions and assumptions. And what we’re really asking here is, why do we think that what we’re going to do is better enough than the things that our user is using right now to solve this problem? And what do we have to assume for that to be true and how do we test those things? And then we execute discovery and experimentation.

Things that we can do without investing in a lot of software, if at all possible, through prototypes, through experiments about motivation, where we can verify that what we’re going to do is compelling to the user. Then we move forward to the user stories and the prototypes that we’ve talked about as being the centerpiece of driving to a high quality valuable solution. And these are anchored in the items that proceed them, and yet we’re able to use them as a very vassal, very narrative day-to-day focal point for our activities. So we keep our eye on the ball, we know what’s valuable to the user. And we look at whether those deliver or not.

And then if we know this is working, we can drive to good product. And if we see it’s not working then we loop back through and we make sure that we understand the sources of value to the user. And that we’re not building this software that is so ubiquitous that nobody wants. Another nice thing about doing things this way is that this works in reverse. And a lot of the work that I do in practice is about kind of debugging products or features that users don’t like. So here, we move backwards from product and promotion. We look at how do we implement what we implement, and did we instrument observation into that?

Were we doing something compelling to the user, what problem were we solving with that? And then, do we know who this person is, so that we can figure that stuff out. So that is a framework that we’ll be referencing so that we have a little bit of a structure to think about. What to do when and how to make sure that we’re not wasting time on the wrong thing and building something that nobody wants.