Demand Thinking - New perspectives for designers and product managers from Ryan Singer and Chris Spiek

In any product role, deciding what to build, what to prioritize, and what to avoid can be stomach-turning work. The closer we get to identifying demand (what people want from our product), the better we feel. The trap is that in many cases, when we think we’ve identified demand, what we have really identified is just supply-side thinking (features to be built).

In this episode you’ll learn how misinterpreting a feature request as demand can lead to building an expensive feature that nobody wants. Ryan and Chris also give a preview of what's to come in the series.

CONCEPTS: SUPPLY, DEMAND, CAUSE AND EFFECT, ASKING "WHEN"

Do you have questions or feedback for us? Tell us your thoughts.

Transcript:

Ryan: Hi I’m Ryan

Chris: Hey, I’m Chris

Ryan: And we’ve got some new, pretty interesting material that we’re here to share with you. Both of us come from the product development world, software, design, programming, and pulling it all together and figuring out what to build, why to build it now. Basically the product role.

We’ve seen a lot of the struggle with it, and we’ve got some new tools and new thinking that we’re trying to share here.

In order to kick it off, I want to put two concepts out there that we’re going to refer to over and over again that are going to frame the discussion.

These are two words that we borrowed from economics but we’re going to look at them in a different way.

Anyone who does product design has to switch between looking at the world between two different perspectives.

The first 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. This is what you make.

And then the other side is the demand side. The demand side is all about what you can’t control.

So 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. That’s the demand side.

As modern, informed product designers, we try to be very user-centric. 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 time when we think that we’re understanding the user, it’s actually not the case.

That’s what we’re going to get into today.

Chris: So I think the first thing to do, Ryan, is just do dive through an example, and, like you said, we feel like this crosses a lot of different disciplines. The User Experience person, the designer, the product manager, the engineer. We’re all in situations where we’re getting feature requests and different sources of input 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.

What you and I have gone through over the past couple months is talking about these things and coming to the realization that a lot of the time we would have a conversation and get comfortable saying, “this is how we define the demand - let’s define what we’re going to build.” Then we’d step back from it and say, “that’s still supply.”

Then we’d look at it a different way and we’d try to shape it and then we’d say, “this has got to be demand language, and now we’re in a better place to decide what to go build,” and then we’d say, “no, we’re still talking in supply language.” So what we’ve figured out that supply in different forms will masquerade as demand, as strange as this concept sounds.

So what we’re out to do today is to introduce you to this way of thinking, and run through a quick example of how to tell the difference and understand the contrast between these two things. Let’s do an example.

Ryan: Here’s an example of a feature request that we’ve seen. Working on a project management app and a customer write support and says that they want permissions in the project management app. They want to add a permission so that they can prevent contractors from archiving projects.

This is the kind of thing where if you get a support request like this, you say, “well now we have demand for permissions; customers want permissions.”

Chris: And you never get one feature request. Once you open the door to this, the role becomes, let’s bucket these things and find which ones are similar. When we look at all of the topics that we hear about, what do we hear about the most, and this is when it surfaces: “We have a lot of customers asking us for permissions, so how do we go build this?”

Ryan: Yeah every week X customers ask for permissions so we have to go build it at some point.

But then what happens is that 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. It’s really not any different from having somebody who is 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 x, y, z.”

What we want to do is get some kind of a notion of what the demand is.

If permissions is just a supply-side idea, then what the heck is demand, other than, “I want it.”

Here’s a way to look at it. The demand is actually a totally different animal.

Usually when we start talking about a feature request, we’re just inside of the app.

What we’ll start talking about is, “what would it take to build permissions?” We’ll say that we’ll have a new permissions feature on the admin screen and that will be part of the user model and the access model and you’ll see it if you go to the archive screen and it will effect this, that, and the other thing.

And we’re just talking about the implementation.

What we want to do to get to demand, is 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?” That is going to put us into a real-life situation.

Remember that demand is out there in the real world that you can’t control. So what was happening out there?

So we actually take this jump outside the app. We have a conversation with the customer. We actually got on the phone with the customer and said, “can you tell us what was happening before you wrote the support request.”

The customer tells us that she was in a meeting at the time.

And she was saying that she didn’t want to use the product 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.

She’s having a conversation and the other people are saying, “what else are we going to do?” She says, “okay I’ll write them and ask them if they can put a permission in so I can feel secure about this matter.”

We asked her, “tell us about the story. The contractor archived something?"

We’re putting a dot here in our timeline that there was an event that happened in the chain of cause and effect where the contractor archived the project.

We say, “well how did that come to your attention.” She says, “I loaded the app one day and the whole project was missing.”

And we said, “what did you do then?” And she told us that she started asking around and emailing all of the people who were on the project and one of the contractors answered and said, “hey I archived it, I didn’t know that it would affect anybody else. I thought that it was just going to take it away from my view.”

So the contractor explains — this is another big part of the story — the contractor explains what happens, and he says, “I didn’t realize if affected anybody else.”

Now we can see why this happened. The meeting comes and she says, “come on people aren’t going to realize that if they do things that it affects other people and stuff is just going to disappear on us. This is not stable ground for us to build on top of.”

This allows us to compare two different approaches to think about the solution.

If we just take the solution that the customer gave us, to add permissions, that’s a big, difficult, complex, thing. We have tons of open questions to answer. It could be a lot of engineering work. Who knows where it starts and where it stops.

How many things are we going to build permissions for once we start to go down that road.

It’s a big, hairy thing.

What we want to do is 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.

Now we can go through her story and we can play the role of the contractor and we can see for ourselves if there is 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 is 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.

Here we go, “ah! All we need to do here is add a message that says, ‘if you do this, it’s going to be archived for these 10 people as well.” We could also show their faces so it’s totally clear that it affects other people.

Now we have a new idea on the supply side because we’ve properly understood the demand. We could say that the alternative is something called a “social warning.”

If we compare this to the permissions idea, the permissions idea is one hundred times more complicated. The social warning idea is something that a designer could whip up in an afternoon - it probably takes 30 minutes. Do a quick check across devices and and commit it and it could go out in the next release.

Chris: This is a big contrast. 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 and 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.

We have to explain new features, we take up screen real estate. If we build it wrong we’ve alienated a bunch of use-cases. There is so much risk associated with going down the permissions path in addition to just the cost of building it and documenting it.

Ryan: And there’s also that feeling that you talk about all the time - that pit of your stomach feeling. 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 the whole time you’re thinking, “am I making the right call here?”

Versus the social warning idea where you think, “I know exactly why I’m doing it. I know exactly how it changes the story.” There is a lot of certainty here.

Chris: And it stops it at the beginning. If I can stop this from ever happening then I have a happy user and I don’t ever have this use-case at all.

The other thing I’ll point out is that we talk about getting outside the app. Ryan mentioned that a lot of times that if we’re dealing with feature requests or bugs 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 say, “you’ve asked for permissions, tell us what kinds of users you have.” - “Oh I have contractors, and authors, and my executive team,” and 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 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 the solution. I want to ask what led up to this point where you were in a situation where we weren’t providing the value that you needed us to provide.

Ryan: When we have that kind of chain of cause and effect, that is something we can play through as designers, so now we know the exact detail of what to play through our heads when we are evaluating different design ideas.

Chris: As Ryan mentioned, we’ve both been in Product Management, Product Strategy roles. We’re out to figure out how to best manage the in-flow of requests, of information, of forces that play on these teams to push the product in different directions. 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. It’s not a matter of pushing back so hard that you say, “I’m never going to build permissions.” It’s 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’s getting to the right solution or the right supply-side notion.”

Ryan: There is a lot of user-centered methodologies out there, but when we try to look at those we basically see a lot of squishy, fuzzy, BSey stuff. It sounds good to go focus on the user, but in the reality if I don’t have a real, concrete, rigorous, clear understanding of: “this happens when … “ and I don’t have cause and effect, I’m not going to be able to make really trustworthy, informed decisions.

Chris: What we’re trying to get to, and what Ryan and I are working towards is: How do we make sure we’re not misinterpreting supply-side ideas as demand from our users or demand from the market.

What we’ve shown here is that 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’s supply.

THIS is demand. Now I feel comfortable about what I’m working on, and how I can spec the solution and what I’m going to deliver on. And it has a lot of concreteness to it.

Ryan: We’ve been developing a handful of tools and using them on real projects over the course of the last year or so. These are different tools that we can use to get at the demand and also to make decisions in projects that we’re doing.

So we’re talking about specific interview techniques, specific ways of mapping the work-arounds that people are using, and ways of modeling and 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.

Chris: 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’ve found is that it’s not as easy as picking up the phone and starting to talk. There are certain ways that you have to frame it and certain tips.

I will say, it’s early-days. The way we talk about it to each other is that 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’ll be serving them up for you to consume and provide us feedback on, and help us shape them up.

If you’re struggling with the same sort of thing that we’re describing and you have the stomach for it - to be able to live in the frontier and play with these different things, then we welcome you to follow along and participate in this.

And if not wait for us to make it concrete and we’ll ship it down the line.

Ryan: This is going to be a winding path and we’ll be exploring a lot of 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. We really are aiming to move the discipline forward. We think we have somethings that can change the way that all of us think about design.

Chris: This is the hard work. Anyone can come up with supply-side ideas, with feature ideas, with new designs and that sort of thing. Not to say anyone. A good designer will come up with good solutions. 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 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 the notion of “when.”

We’ve talked about time over and over again, and I explained 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. So my boss comes and says we’re developing this new feature, or a customer says, ‘why don’t you do this,’ and I always say, ‘why why why?’ It’s the 5-Whys.” 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.”

Ryan: Like you’re fighting back.

Chris: “and it’s not my intention, but I was taught, get me to why.” And what we’ve come to understand here, and what we’re trying to figure out is that if I switch my mode of thinking to “when” — “what happened that caused you to get into a situation that caused you to think that you needed something on the supply side?” If I can understand that order of events, that is truly one aspect of what demand is.

Ryan: And it’s the biggest challenge for all of us who work on products. Figuring out what the heck the requirements should be.

How to define what matters.

How to define what the focus is.

What is central versus what is peripheral.

It all ties back to the same stuff. That is what we’ll be getting into here.

Chris: Awesome - thanks for your time!