Hi, I'm Ryan. Hey, I'm Chris. And we've got some new pretty interesting material that we're here to share with you. And both of us come from the product development world, software, design, programming, and kind of pulling it all together and figuring out what to build, why to build it now, and basically the product role. And we've seen a lot of the struggles with it, and we've got some new tools and some new thinking that we're trying to share here. And in order to kick it off,
we're going to use sort of put two concepts out there that we're going to refer to over and over again. They're going to sort of frame the discussion. And these are two words that we borrowed from economics, but we're going to look at them in a different way. Basically anybody who does product design has to switch between looking at the world from two different perspectives.
And this perspective is what we call supply. The supply point of view is all about what we make, what we build, what we ship, what we put out there. It's the app that we're designing, it's the work that we're doing. So this is what you make. And then the other side is the demand side. And the demand side is all about what you can't control.
This is about what's going on for the customer in their life. So we don't get to decide what's happening to the customer, what they're trying to do, what they value, what's important to them. Those are all the things that are out there happening in the real world. And so that's the demand side. And as kind of modern informed product designers, we try to be very user centric. Right. And so we like to think about what we're going to do.
So we like to think that we're sitting in the demand box, a lot of the time figuring out what to build over on the supply side. But it turns out that in reality, a lot of the things that we think are demand really aren't. And a lot of the times when we think that we're understanding the user, it's actually not the case. So that's kind of what we're going to get into today.
Yeah, so I think the first thing to do right is probably just dive through an example here. And like you said, we feel like this crosses a lot of different disciplines, the UX, the user experience person, the designer, the product manager, the engineer, we're all sort of in situations where we're getting feature requests and different sources of input sort of piled on us.
And it's prompting us to think about moving the product in different directions and prompting us to think about building different things. And sort of what you and I have gone through over the past couple of months is talking about these things and coming to the realization that a lot of the times we we would have a conversation we get comfortable like this is how we define the demand.
Okay, let's think about what we're going to build and then we'd step back from it and say, that's still supply right and then we look at a different way we try to shape it. It's like, okay, this has got to be demand language and now we're in a better place to go figure out what to build and we'd say, no, we're still talking in supply language.
So what we've figured out is that oftentimes supply in different forms will masquerade as demand as strangers this concept sounds. So what we're out here, what we're out to do today is is introduce you to sort of this way of thinking and run through a quick example of of how to tell the difference and understand the contrast between these two things. So let's let's do an example.
Yeah, so here's an example of a feature request that we've seen. So working on a project management app and a customer writes support and they say that they want permissions in the project management app they want to be able to add a permission so that they can prevent contractors from archiving projects.
Okay, so this is the kind of thing where if you get a support request like this, you get a feature request, you say, well now we have we have demand for permissions customers want permissions, right? And you never get one feature request, right? I mean, once you open the door to this, it's like the role becomes like let's bucket these things, which ones are similar.
When we look at sort of all the topics that we hear about, what do we hear about the most? And this is when it surfaces, right? We have a lot of customers asking us for permission. So how do we go, how do we go build this? Yeah, every week X customers asked for permission. So we must have to build it at some point, right? But then what happens is if we look closer at it, we realize that when they ask us for permissions, that's just defining supply. That's just telling us what we should make.
And it's really not any different from having somebody who's higher up in the company, walking in and saying, okay, in the next cycle, we're going to build permissions and it's going to look like XYZ, right? It's no different from that. So what we want to do is we want to get some kind of a notion of what the demand is, right? Because if permissions is just a supply side idea, well, then what the heck is the demand other than I want it, right?
So here's a way to look at that. The demand is actually a totally different animal. Usually when we start talking about a feature request, we're just inside of the app. So this is, I'm just going to move this down a little bit. This is the app. And what we'll start talking about is, well, what would it take to build permissions? So we start saying, we'll have a new permissions feature on the admin screen and that'll be part of the user model and the access model.
You'll see it if you go to the archive screen and it's going to affect this then the other thing. And we're just talking about the implementation. But what we want to do to get to demand is we want to go outside the app. And really critically, we don't want to ask, what do you want or why do you want it? We want to ask, when did you want it? Because that's going to put us into a real life situation.
And remember, the demand is out there in the world that you can't control, right? So what was happening out there? So we actually take this jump outside the app and we ask the customer, we actually got on the phone with the customer and we said, can you tell us what was happening before you wrote the support request?
And then the customer said, she tells us that actually she was in a meeting at the time. So she was in a meeting. And at that meeting, she was saying that she didn't want to use the product again for the next project they were doing. Because in the last project they did, there was a contractor who just archived the project and it disappeared on everybody. So she didn't trust the tool.
So she's having a conversation and the other people are saying, yeah, but what else are we going to do? So she says, well, okay, I'll write them and I'll ask them if they can put a permission in. So I can feel secure about this matter, right? And so we asked her, well, tell us about the story here. What the contractor archived, something? So we're putting a dot here in our timeline that there was a vent that happened in the chain of cause and effect here.
Where the contractor archived the project. And we say, well, how did that come to your attention? And she says, I just loaded the app one day and the whole project was missing. So she opens it and the project is missing. And we said, well, what did you do then? And she said, well, I started asking around. It said, does anybody know where the project went? She started emailing all the people who were on the project.
And one of the contractors answers and he says, hey, I archived it. I didn't know that it would affect anybody else. I thought it was just going to take it away from my view. Right? So the contractor explains. This is another big part of the story. The contractor explains what happened. And he says, I didn't realize it affected anybody else.
So now we can see why this happened. Now the meeting comes and she says, come on, people aren't going to realize that if they do things that affect other people and stuff is just going to disappear on us. This is not stable ground for us to build on top of. So this allows us to compare two different approaches to how to think about the solution here. If we just take the solution that the customer gave us to add permissions, that's a big, difficult, complex thing. Right?
We have tons of open questions to answer. It could be a lot of engineering work. It, who knows where it starts and where it stops. I mean, how many things are we going to build permissions for? Once we start to go down that road, right? It's a big, hairy thing. So what we want to do is we want to ask ourselves, is there an alternative here that we can contrast with?
Is there another solution that scratches the itch? And now we actually have some understanding of the demand to ask the question about. So now we can go through her story and we can play the role of a contractor and we can see for ourselves if there's anything along the way that we could change. So we go into the app and we click the archive button. And what we notice is that on the archive screen, there's a confirmation and it says, are you sure you want to do this?
But it doesn't say anything about the fact that it's going to impact other people. So here we go, all we need to do here is add a message that says, hey, if you do this, these 10 people are all going to, it's going to be archive for these 10 people as well. And we could even show their faces. So it's totally clear. This affects other people. Now we have a new idea on the supply side because we properly understood the demand.
So we could say that the alternative here is something called, let's call it a social warning. And if we compare this to the permissions idea, I mean the permissions thing is like 100 times more complicated. The social warning is something that a designer could whip up in an afternoon, probably takes 30 minutes and do a quick check across devices and commit it and it could go out in the next release. No problem.
Yeah, so this is a big contrast. So the one thing I want to point out is when we get back to the roles that we're talking about, it's about managing priority, it's about managing risk. So when I compare these two solutions, the risk on the social warning side is so focused and so small, we can find downsides, I'm sure if we play with it enough, but the impact is so small compared to the bloat that comes in with permissions having to explain new features.
So if we're taking up screen real estate, if we build it wrong, then we've alienated a bunch of use cases, right? There's so much risk associated with going down the permissions path in addition to just the cost of building it and documenting it and all that sort of thing.
And there's that there's also that feeling you talk about all the time, like the pity or stomach feeling, where if you're building the permissions thing, you're like, oh man, this is like months of work, it's a big bet, it's a big change. And we're going to have to live with it forever and the whole time you're kind of like, am I making the right call here versus you do the social warning and it's like, okay, I know exactly why I'm doing it. I know exactly how it changes the story.
Like it is a lot of certainty there. Sure. And it stops at the beginning, right? If I can keep this from ever happening, then we have a happy user and we don't have this use case at all. The other thing that I'll point out is we talk about getting outside the app, Ryan mentioned a lot of times if we're dealing with feature request or bug request, we end up focusing on our interface and saying, okay, how do you use this?
And when does this issue arise and that sort of thing? And we've highlighted that it's important to get outside the app to understand what led up to this. I just want to point out that this is different than getting outside the app in different ways because it's very natural for us to want to say, you've asked for permissions. Tell us about the different types of users that you have. All right, all I have contractors and I have authors and I have my executive team, that sort of thing.
Okay, tell me how big these different teams are. We feel like we're getting more information about demand and about sort of this use case, but we have no sense of time. So this is where we keep getting back to. I don't want to ask why and I don't want to ask about this about the solution. I want to ask when what led up to this, this point where you were in a situation where we weren't providing the value that you needed us to provide.
Yeah, and then when we have that kind of chain of cause and effect, that's something that we can play through as designers. So now we know the exact detail of what to put to play through and through our heads when we are evaluating different design ideas.
Yep. So as Ryan mentioned, we've both been in product management, product strategy roles. We were out to figure out how to best manage the inflow of requests, of information, of sort of forces that play on these teams to push the product in different directions. And obviously it's our job to move the needle. We need to figure out what to prioritize, what to work on, and we call it passing. What to pass on, right?
Because it's not a matter of pushing back so hard that you say, I'm never going to build permissions. It's a matter of saying, okay, I hear everybody talking about it. Let's take a deeper dive and figure out if this is worth working on and if it is getting to getting to the right solution or the right supply side notion.
Yeah, and there's a lot of kind of user centered methodologies out there. But when we try to look at those, I mean, we basically see a lot of, I mean, that's a lot of squishy, fuzzy kind of BSE stuff. You know, it sounds good to go focus on the user, but in the reality, if I don't have a real concrete kind of rigorous, clear understanding of this happens when, you know, and I don't have that cause and effect, I'm not going to be able to make really trustworthy informed decisions.
So what we're trying to get to and what, what Ryan and I are working towards is, is how do we make sure that we're not misinterpreting supply side ideas as demand from our users or demand from the market? Because what we've shown here is there are methods that we can use to create a lot of contrast between those two and get us all to a place where we can say, that's not demand, that supply, that's not demand, that supply.
This is demand. Now I feel comfortable about what I'm working on and how I can expect the solution and what I'm going to, what I'm going to deliver on and it has a lot of, a lot of concreteness to it. So we've been developing a handful of tools and using them on real projects over the course of the last year or so. And these are different tools that we can use to get at the demand and also to use it to make decisions and projects we're doing.
So we're talking about specific interview techniques, specific ways of mapping the work around the people are using, and ways of modeling and kind of articulating to the team, what the requirements are, what the circumstances are and the outcomes are that people are expecting or what's happening to people so that we have really clear sharp requirements for the problems that we're trying to solve.
So we have methods, we have tips, we have tricks. In the example that Ryan drew out, he alluded to having a conversation with a customer. What we found is it's not as easy as picking up the phone and starting to talk, there are certain ways you have to frame it and certain tips and that sort of thing. I will say it's early days. So the way we talk about it with each other is we're in the Wild West, we're in the Frontier.
We don't have the hardcover book that we can hand you to say, turn these pages and when you're done you'll know exactly how to do this. But we have methods that we've tested, we've used with success and now we're in the process of packaging them up and we're going to be sort of serving them up for you to consume and provide us feedback on and help us shape it up.
So if you're struggling with the same sort of thing that we're describing and you have this stomach for it to be able to live in the Frontier and to play with these different things, then we welcome you to sort of follow along and participate in this. And if not, wait for us to make it concrete and we'll ship it down the line. Yeah, this is going to be a winding path and we'll be exploring and sharing a lot of the things that we're chewing on ourselves and the things that we've been testing out.
But we're pretty excited to show you what we've been working on and we really are aiming to move the discipline forward. We think we have some things that can change the way all of us think about design. Yeah, and this is so we always say, this is the hard work. And anyone can come up with supply side ideas, with feature ideas, with new designs, that sort of thing, right? Not to say anyone, a good designer will come up with good solutions, right?
But the hard work is saying, where do we actually go with this product? Where is the true demand and how do we guide it and make the right decisions? And we feel like those things are in touch, the demand is in such stark contrast with the supply. We think we can peel these things apart and really start to identify them. The thing that I'll leave you with is, or one of the things we'll leave you with, is the notion of when.
We've talked about time over and over again and I explain this method to the head of design a couple of weeks ago at a SaaS company. And he said, you know, I was taught in design school to always ask why, and that's going to guide me to details, right? So somebody, my boss comes and says, hey, we're developing this new feature or a customer says, well, why don't you do this? And I always say, why? Why? Why? It's the five whys, right?
And he said, they look at me like I'm digging my heels in, like I'm lazy, like I don't want to build the feature. Like you're fighting back. Like I'm fighting back. And it's not my intention, but I was taught, like, get me to why.
And what we're trying to figure out here, or what we've come to understand is, if I switch my mode of thinking to when, what happened that caused you to get into a situation where you felt like you needed something on the supply side, if I can understand that, that, that order of events, that is truly one aspect of what, what demand is.
And it's the biggest, I think, challenge for all of us who work on products is figuring out what the heck the requirements should be, how to define what matters, how to find what the focus is, what's central versus what's peripheral, it all ties back to the same stuff. So that's what we're going to be getting into here. Awesome. Thanks for your time.