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

We get a bad feeling whenever we’re tasked with working on a feature with a lot of unknowns.

The project starts when someone says, “we’ve all been talking about making that better for a long time.” But when we start to discuss and detail the project, a concrete definition of “better” is nowhere to be found.

Better to who? Better in which situations? The upside of the project is unclear.

The same lack of clarity exposes us to downside risk. We are free to include anything in the feature that can be justified as making it better. We don’t have the ability to say no to any idea, and because shipping is a one-way street, we’re committing to maintaining, improving, and expanding these new aspects of the product far into the future.

In this episode you’ll learn how to think about these projects by going into a mode of risk management. Ryan and Chris also introduce a tool that they use to diagram a demand-side struggle and work towards a solution.

CONCEPTS: TWO MODES, MANAGING RISK, THE HOPPER, CSR DIAGRAM

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

Transcript:

Chris: Hey, guys. So, what we've noticed is that as, a product manager, we've discovered that we end up sort of operating in two modes or wearing two hats, as we like to say. And these two modes come across as one it's things that pop up and what I like to say is projects that creep up because of long-standing anecdotal hunches, so these things bubble up. And the way they get talked about is, you know, lots of customers talk about how we need to improve this feature, right? And well, for a long time we've been talking about doing this and when the meeting gets called, we all get together and we talk about how to make the future better and what to improved and that sort of thing. But when you start to probe into, "Why are we actually here? What caused us to all come together and actually dedicate resources to this?" It's very hard to get sort of down to the real cause, right? And everything starts to feel like, "Well, we've got to make it better." You know, like everybody on the team knows we have to make it better, we've been talking about this for a year and now it's time to put the rubber to the road. And when this happens, there's like this notion of "I go into the mode of managing risk." It becomes less about how to make the best feature in the world, and I go into this mode of, "How do I make sure that we don't get ourselves into a situation where we push something out there that ends up spiraling and puts us into a bad situation where we're under-delivering or we have quality problems or anything like that?" So that's mode one, anything to add to that Ryan? Does that sound familiar?

Ryan: Yeah. Well, so I'm thinking of cases where we say, you know, "We need to redesign the search section," or, "We need to totally rethink our dashboard," and everybody agrees because there's a lot of, like you said, this kind of longstanding anecdotal hunches. It's like we've all heard a dozen different stories and seen a dozen different problems with the search area or the docs and files section, or the way that we have are To-Do's report or whatever it is, there's a big area where we all know it should be better, and then there's this kind of tendency to bring it up as this kind of big overall, right? Or this big new thing that we should build like, "Oh we really have to build," like the example we'll talk about in a little bit here, the calendar, "We really need to build a calendar." And everybody is like, "Yeah, we have to do it." And I think when you talk about that risk it's... Yeah in a sense it doesn't feel risky because everybody knows that people have been asking for the calendar, but as a product manager, you're starting to think through, "Well, what does it really mean?" You know, what if there is a lot of moving parts to this feature and we start, let's say like with the calendar, if we start building a week view and a month view and we have to integrate with other calendars. I mean just the integration part could spiral out of control.

And a week view with a really good UI for dragging, you know, the length of your meetings and making everything line up and stuff like that, I mean that could be a really expensive, time-consuming, open-ended problem. And how are we gonna make choices and how are we gonna kind of... I don't know how you say like, "Box this thing in, so it doesn't spill out all over the place and become a never ending project or worse sometimes." You know, sometimes worse than we talk about how... Sometimes worse than a project that fails is a project that ships that you wish hadn't shipped. You know what I mean? Like you put a whole bunch of functionality out there that leads to more and more feature requests or there's a bunch of UI now that you can never take back, that's taking up space, that is in the way when you wanna put a new feature out.

Chris: Yes, something that you said to me really struck home which was "Shipping is a one-way street." I think that's an incredibly powerful notion. It's very hard to take these things back. And the nightmare in my mind when you talk about the calendar functionality is the integration side of it, right? You've got to integrate with Outlook and Google and their protocols and that, but now somebody launches a new calendar, right? And well, if you don't integrate you're lacking, right? So we're putting something out there. We're not incredibly concrete about the benefit. We think that improving the calendar is a good idea, but we're not real sure what the upside is, but we're committing ourselves. We know we're committing ourselves to a lot of maintenance down the road, right? So these things are sort of like they're not matching up perfectly. And I think the other thing you said is there's like bottomless ripple effects, like I can't see the end of what I'm committing to and that becomes very risky.

Ryan: Even sometimes these features that seem smaller can have ripple effects. You know, you offer, let's say color labels on files in an app.

Chris: Yeah.

Ryan: And now, as soon as you do that you realize, "Well, people are gonna wanna customize the colors." And then if we allow them the label, they're gonna wanna be able to bulk change the labels, right? It's just like one thing leads to the other, you know.

Chris: Yeah, absolutely. So there's this rule, I think what you and I have talked about is we wanted to surface this because there's a little bit of a danger. In episode 1, we talked about getting to what we think is, I can't use the word ideal, what we think is a better state which is basing decisions on demand, right? But the thing that we didn't want to have happened is everybody who listens raced out and cancel all their meetings and saying like, "This is what I'm working on," right? Because the reality is time is flowing forward, we have resources we need to get dedicated, we need to continue to make the product better. So there will be things that we are going to work on that do not necessarily have this perfect... Perfect is the wrong word, too. This good grounding and demand, and we just need to be in those meetings, we need to be productive in those meetings, and when you and I sort of thought about that we said, "It feels like when we're in those meetings, we're managing the risk." That's kind of like what we call that mode, right?

Ryan: Yeah, there's the stuff that's already gonna happen, right? The stakeholders want it or somebody made the decision that this has to get built or there's already just momentum already, and you can't just say, "Everybody stop the world. I wanna go and study. I'm gonna do my demand research on this and get back to you in a while." You know, there's just a lot of things that you can't do that with. So in those cases the best thing you can do is actually work, that's something we can talk about, right? Is kind of having these smaller projects prepared that you can put in that have the lower risk, right? So it's kind of a question of when these risky projects come up. You're in the meeting or you're working with other people on the team, and then the big hairy idea comes up where maybe for other people it seems like a clear win, "Of course we should build the calendar." But you're seeing all the risks as the product person. We talked about how... I need to have options there where if it's something that I really have a lot of doubts about, I think it's gonna spiral out in scope or whatever. I wanna be able to say, "Hey, I'm gonna take that on as the product manager. I'm gonna take that on and put that into my hopper of things that I'm kind of chewing on and learning more about, and we're not gonna schedule that. I'm gonna get this down to a point where I understand the demand better, so that we can have a more crisp and detailed conversation about what really matters about the idea instead of just building everything we can think of and hoping that it covers the case." Right? But then the tension there is that we can't always say, "Hey, I'm gonna go research that." Because otherwise, everybody would just be sitting around all the time while we go do our research, right? So we also have to have this sense of other kinds of projects that we can line up that don't have the same kind of risks.

Chris: Yup. And so that, working the hopper is what we think of as the other mode. Right? So I had the first mode which is I'm managing risk, I'm playing defense, I'm trying to make sure we don't go into some big unknown, some bad territory. And the other mode is this, I am working with my team, we're working on figuring out demand, making sure it lines up with a strategy, talking to users, doing interviews and that sort of thing to sort of get out ahead of these things and really shape up ideas and insights that we can then bring to the design team, the product team to say, "Here's a really crisp understanding of demand. Now let's have what is hopefully some concrete conversations on how to address this demand that is free from all of that risk." And we're gonna get into the calendar example in a little bit. But I think you also touched on something else, is we use this notion of nook and cranny for things that are close in and sort of like the cracks that we can fill in the product that don't have those ripple effects, right? So that we can spot things where we say, "There is not a lot of potential harm down the road. This is pretty close in, it's well-constructed, and we can work on that while I go do the work that I need to do to shape up those big unknowns into concrete things." Right?

Ryan: Yeah.

Chris: And yeah, one of the nooks and crannies, what does it feel like to have a nook and cranny?

Ryan: Yes so, the nook and cranny feature there it's all about those little gaps that are already there waiting in the app where there is a clear space for the new piece of functionality or the change. You can see the edges of it, it's not something that's gonna spill out and affect a lot of other screens. I'll give you an example, we sketched out a feature idea at Basecamp recently where we noticed that you can move documents between folders in Basecamp and you can drag and drop them between folders. And what we noticed was that when you copy a folder or you copy a document to some different project, you don't have any way to choose the destination folder. But it turns out that we actually have a dedicated screen for doing the copy, so you can click on the document and say, "Copy it to this project." And you have a whole screen that you get to choose which project you're copying to. So there's room on that screen for some kind of a drill down to choose the folder on that project that it should get filed under when you copy it and or when you move it.

And because we don't really have any kind of a fear that there's gonna be something else that we're gonna wanna put on that copy screen. You know what I mean? Where we're gonna say, "Man, I really wish we didn't devote that real estate on the screen to the folder drill down." No, this is a natural part of the copy that we didn't implement yet. The space is there waiting. And because we have a dedicated screen for it, there's no uncertainty about how this is gonna spill out and affect other things. There's plenty of room there versus if we had maybe some kind of a crowded menu or something or a crowded screen where we'd have to figure out a way to squeeze this in. I wouldn't feel nearly as comfortable about it, it wouldn't feel like a nook and cranny feature.

Chris: Yup. So there's edges to this. And it doesn't have that feeling that you described of the colored labels, where is like they're gonna ask for batch operations, they're gonna ask for customization. This is like the real estate is already dedicated so I'm not gonna need to get that back anytime soon, and I can see sort of the edges of the feature requests and that sort of thing. So it feels more well-defined and I can hand this off to the team and have them work on it.

So I think that was the first point I wanna touch on with just these two modes. The last thing I'll say, because I think this is great and we talked about this earlier, the things to look out for are one, feature 2.0. It's like one of those triggers, anytime you come out it's like, "We're doing Search 2.0, we're doing dashboard 2.0." It's like okay, we've called it that, but what's the reason? You know, try to dig back in and a lot of times you'll find yourself in these situations. The other thing is you use the metaphor "trolling with a net" as opposed to "hunting with a spear." In these conversations, a lot of times what we end up doing is we take a ton of use cases and we drop them all on the table and we say, "When we build this new feature, all these people are gonna be happy." And I almost view it as like it's a cheat, like because we can't name the few things that we really know are gonna get better, we just pile a lot of stories in and we say, "See all this is a justification for doing things better." The problem is it might be good justification, but it's bad data when it comes to making design decisions. Even of all these things are true, I don't know how to interrogate this big lump of use cases in a way that leads me to choose building one feature over another or one button over another, so things get things get very murky very quickly.

Ryan: Well, you know when people don't really know what the problem is that they're solving, an easy way to make everybody relax is to just say yes to all the stuff that you might need. You know what I mean? It's like if you're packing on a vacation, if you can take as many bags as you want and you don't have to make any decisions. You can take your whole closet if you want to. Right? It's only when somebody says like, "Hey, we've got this much space. What's gonna fit in there?" Then you have very hard questions to answer.
And if the whole concept was framed as build a calendar or redesign the dashboard or whatever it is, when you start to ask everybody, "Well, what goes into this box if we scope it down to one change, or if we scope it down to seven weeks or whatever it is, right?" Then you realize like, well, there's this feeling like we have to do it all, and if we don't do it all, it's not enough, you know? And usually, when that happens, it reveals the fact that we haven't done that homework, that thing where we take it in the hopper for our kind of solo time. You know, because as a product manager, there's these things that we have to chisel them down and figure out what the real demand is and what the real problem is so that we can go back to the teams with a much more stripped down and precise definition of the problem. And that way people can say, "Yeah, if we do this, this, and this, we're done and we don't need those other things because we have a clear definition of what done looks like or what success looks like or what the problem being solved looks like."

Chris: Absolutely. So you have a story around this on your team, right? There was this... I guess I'll let you tell it, you'll tell it better than I, but the way I am interpreting is you had this anecdotal thing happening where people started talking about...

Ryan: Yeah.

Chris: "Let's do the calendar thing, let's build the calendar, let's make it better." And it's not that people are like advocating hard for this, but it's like murmurings and like it keeps coming up in just random conversations, things like that. Right? Do you think that's right?

Ryan: Yeah. So the case that we had here was we knew that customers were asking for a full blown calendar. The version of Basecamp that was in production until very recently just had a very stripped down agenda view. And we were hearing from customers all the time, "You should build a real calendar." People internally knew that we had calendars and previous iterations at Basecamp and we didn't build that into version 3. And so there was this kind of general sense that we didn't build something that Basecamp needs. And Basecamp needs a calendar, right? But every time it came up, we just said no to it because it felt like a big engineering project, it felt like a big open-ended huge piece of work, especially now that we're also supporting multiple devices, you know, with iPhone and Android and everything. And what does it really mean to build a calendar? Does it mean a month grid and a week view? Does it mean that you can drag events between days interactively? Does it mean that you can stretch the height of a meeting in the weekly view? Does it mean integrations? There's just like a ton of questions about what, why, like what do we need to build here for it to be good? Right? When do we need to stop?

And it's one of those things where the ripple effects just never stop, you know? So it feels like a six-month project minimum which for us, I don't know it depends on where you work, but for us, that feels like eternity, you know what I mean? Our typical big feature releases are eight-week cycles of work. So we kept saying no to it but the thing is that, you know, these things they keep bubbling back, you keep hearing it and then you say, "Okay, we have to try to come up with something." So this is a case where it comes up in conversation and then you say, "Okay, I'm gonna take that one. I'm gonna take that one as one of my research projects. And I've got a handful of good kind of nook and cranny features that I'm gonna line up for the next few rounds of work, and then while we're doing those things that have a kind of a nice bounded downside risk, I'm gonna see if I can find an angle on this problem." Right?

And we talked about that in episode 1. So what we did was we did these customer interviews where we talked to people who had written in support and asked about needing a calendar. And we came to a very specific way to frame what they were asking for, and this allowed us to focus the problem and focus the team and end up coming up with a very different design than what we had ever thought that we needed to build. Actually, we ended up with a version of a calendar that we were able to release in seven weeks with three people working on it. So we really came up with something lean and...

Chris: Amazing.

Ryan: I can show you actually kind of how we drew it. This is using one of the tools that you and I've been talking about a lot. It's a sort of a technical product manager tool, you know, we call it the CSR diagram, and basically, what we wanna do is we wanna be able to spell out a very specific problem case where if that thing gets better, then the feature worked, okay? So we don't want the problem to be "a calendar is missing," because that's too open ended. But if we strip it down to a specific story that comes from a detailed struggle that happens on the demand side, then we've got something to work against.

So I'll sketch it out here. The basic structure is like this. We make three boxes, and there's three things that we use to define the problem. So the first thing is the circumstance. So that's the situation that the person was in. And the story that we were hearing whenever we talk to customers who were asking us for the, you know, we walked them back and we did the same, we talked about in Episode 1 asking "When?" Right? What was the chain of cause and effect that led you to ask for this? What were you trying to do? Right? And they said, "When I'm trying to schedule a resource..." So what we mean is, somebody has designers and they're trying to figure out who to schedule on this specific project this specific week, right? Or maybe there's a certain number of meeting rooms and they're trying to find a room that's available to schedule a meeting there, right? So they're trying to schedule a specific resource.

And then the second thing that we do is the current solution, and this is on the supply side. So they were using the plain agenda view that Basecamp had at the time which was just a listing of everything that was booked. It was just a list of everything that was on, every event that was in the system. And it didn't show any blank spaces, so you couldn't see the free days. All you saw was a listing of events. So what would happen is, we say, the result of that is they said, "I can't see free spaces." So they didn't know when they could schedule the work. It was just too difficult to see.

And basically, what happens here is this leads to the struggle, right? This is what leads them to write us and to seek out, work around, and to try different things. So we heard stories about people who would always have a wall calendar at hand as they were looking through the events to see what it was or people who would export all of their events to a different calendar app so that they could see them, you know? So...

Chris: And just to connect it back, when we think about demand and supply side language, right? This is another example of the reason that we had these long-standing anecdotal stories and things like that is because when the customers are creating the feature requests or they're writing into Basecamp, they're thinking of the grid they see in Outlook or the big desk calendar that they have on their desk where they can glance down at it and say like, "I've got things on this day but, you know, very quickly, this day's empty." Right? So all they know, and this is not like to cut down customers, but the easiest way to describe it is like, "Why don't you guys have a calendar view? Right?

Ryan: Yeah, it's what we all do. We define it from the supply side. We're like, "This is what you should build instead of this is what I need."

Chris: So it took to translate like, "What you're doing is into this diagram under C, under circumstances, you're using the interview process to basically unpack that and say, Well, it's not that you want the calendar, is what happened and what were you trying to accomplish."

Ryan: Exactly. It's a specific case of using it where we can understand the struggle. Right? And then the second part of what we do with this diagram is we use this to frame an alternate solution. So what we're gonna do is we're gonna say in the same circumstance they're gonna use a different solution. So this is gonna be S. And they're gonna get a different result. Otherwise, why bother changing anything, right? It needs to be a different result. And now, what we can do here is we understand what the after needs to look like, what the different result should be, so we can say, "I can find a free day to schedule it," right? And then what we do here is we take that circumstance, we take that result that we want and we put a question mark here and we let those things be the requirements on the solution space. So what we wanna do is we wanna get together now as product designers and say, "What could we do that would allow people to see the free spaces?" And now that's a totally different conversation than, "How do we build the calendar?" Right?

Chris: Absolutely. It gets rid of a lot of things, right? Immediately, I might not need integrations. There are things that I can start to set aside now that I have the situation and the result sort of tightly defined.

Ryan: Yes, and it also opens us up to things that we could have never considered when we were in the box of "It's gotta be a calendar." So, for example, one of the things we considered very early was an interface like you see if you try to book a haircut or a massage or something like that. You know, you see only the available days, and then you pick the free day. So we said, "Oh, could we do something like that? Could it just be, show me the open times and it's like an appointment booking interface?" But then we looked more closely at the use cases and we realized that a lot of time when you're trying to schedule a resource, you work with the other people who also use those resources and you wanna actually see how everything else is booked to make your decision. If you're getting a haircut, you don't care who else is getting their haircut and when. You just either take the slot or you don't. But if you're working with other people, you might see that somebody is available to work one day, but they might be totally slammed the rest of the week versus somebody else has a really thin week. So it's useful to be able to see how other people are booked when you're doing this kind of resource allocation.

So what happened was, Jason and I actually sat in the room and I presented the problem in this way. I said, "Is there something we could do just to allow you to see the free spaces?" And then there was this kind of different moment of creativity that happened, and Jason pulls out his phone and he goes, "Yeah, you know, check out this calendar on the phone. It looks like a month calendar but it's just dots, and you can't drag anything between the cells. You can't interact with him at all. All you can do is click on a day and then it reveals in the agenda view underneath the calendar what's going on that day, and you can click, click, click, or tap, tap, tap different days and quickly get a sense of what's happening on any given day and where there's an opening and where there's not." And we said, "Man, that's not as good as a real calendar." Right? It's definitely not as good as seeing everything beautifully rendered, you know, like with these long pills for multi-day events and everything. It's not as good as that, but if we plug it into the CSR, it's a good solution, right?

Chris: It's back to having a definition of better, right?

Ryan: Yes.

Chris: The hard thing is if we just define better calendar than I need best in class, I need to beat every other calendar or least the parity, right? So I need to build everything up to that.

Ryan: Yes.

Chris: But now we have in the R, in the result side, is something that I can actually measure. I can measure design concepts against. Can I see the free spaces or not? It's not, can I integrate with everything under the sign? Can I send invites? Can I receive alerts? All that, it's a very clear way to understand, is what we're proposing, doing a really laser focused job of answering this demand, answering the demand that we identified in the first place.

Ryan: Exactly, and the real definition of success in the design concept it's here, it's in the delta between the two Rs, you know? It's not about, are we better than other calendars? Or do we live up to the definition of a calendar from the supply side? It's about... There was a status quo and people were struggling in this circumstance, and now if we replaced the solution with this alternative, have we made things better or not? Yeah.

Chris: So back to your metaphor of the, you know, fishing with the net versus the spear, right?

Ryan: Yeah.

Chris: If I can build the calendar that is better in every way, and what I'm hoping to do is catch some great use cases. Because people use calendars in all different... they're on the road or they're at their desk, they have big teams and small teams. What I'm hoping to do is make it better in every possible way and have people sort of float through and say, "Oh yeah, this works for me."

The difference between that and what we're talking about is the spearfishing. We have identified one very specific struggle and now we are designing to fix that thing and we should be able to see, like you said, that Delta immediately. Like the satisfaction should go up immediately, and we're not in this position where we're out there searching and saying, "Did things get better? Did they get better for some people and worse for others?" And we're not sure what's working and what's not. That's the real contrast that we're trying to highlight here.

Ryan: So we ended up with a very concrete idea that we just call the Dot Grid, and then we also had another thing that we called Simplified Agenda. And basically what happened was we stripped back the visual styling on the agenda because it was just gonna show you the events that were selected on the Dot Grid and put more of the visual styling on the Dot Grid. And the Dot Grid, mechanically, was a much simpler idea than a calendar. And we said, "We're gonna do these two things together. It's gonna be a similar experience to using these kind of a common phone calendar apps, but it's gonna be on the desktop and it's gonna scratch the itch. And we're gonna get the thing done in a single, one of our typical working cycles, which we have eight-week cycles of work." And we actually ended up finishing it early and getting it done in seven weeks.

Chris: And what did you finish? Because it's more than design and engineers documentation support. Like what did you actually get done? Because that's astonishing for me, three people, seven weeks for something. It's not a calendar, we can't call it a calendar but for what you guys pulled off and implemented, that's pretty impressive.

Ryan: Yeah. Well, you know, it's all in the scope, because the scope was tight and also there's also technical decisions that allow us to do that. If we had to build a native version for iPhone, that would be a totally different thing but because we were able to use a hybrid approach and reuse our web-views on the phone, then we really had a very manageable scope here. But of course, that's getting into a whole other area of the discipline of how we only build what is absolutely necessary to scratch the itch. But the thing is that if you don't have a definition of requirements that is that specific, you're never gonna get there. You're never gonna be able to chisel the thing down and get and scope smaller because you're always going to have the what ifs, right?

Chris: It gets bigger. If anything, it goes bigger, right?

Ryan: It always gets bigger, right. Exactly. And the other thing too is that, you know, I wanted to mention that we put the Dot Grid here in S2 as our new solution. If you plug the calendar, the big bad calendar, if you plug that into S2 here, it's also a good looking solution. And I hope from what we've talked about in the beginning of the episode, it's clear that it's the risk side and the cost side that made us say, "We don't want to plug that into S1 or S2", right? It's, "Yeah, okay, we could build a super-mega-ultimate-calendar and then you would be able to find a free day to schedule, but it would cost us 10 times as much, and who knows how many open-ended... you know, there's too many rabbit holes there."

Chris: Yeah, I think this presumes that you have an eye for simplicity, for getting the most simple elegant sort of solution to the problem. If you're not worried about resources and you're not worried about complexity and risk, this tool is not necessarily for you, like go [crosstalk 00:32:11].

Ryan: If you don't mind waste and then shipping a whole bunch of stuff that you could never take back that's gonna be in your way for every future iteration you wanna do.

Chris: Just have at it, build the calendar. It'll work out great.

Ryan: Yeah.

Chris: So hopefully, what we've done here is illustrate sort of the next step. So when we think about building, in Episode 1 we get to the notion of walking back the story and getting the whole story based on a supply side request, right? And I think what we have here with the CSR is now a way to take that data and plug it into a tool to say, "Here's what the story looks like. This is the circumstance. This is what they did. Here's the result." And most of the times if it's a video request or bug request coming in, it's a negative result. And now we can, like you said, draw those lines down and start to plug different solutions in and have conversations around, "Is this bloated? Is this an over-engineered thing? If we're just trying to figure out how to see the free spaces, do we really need to build all this stuff?

Ryan: Right.

Chris: And we can then start to have some better conversations.

Ryan: Right. Yeah. Just to tie them together like you were saying, that the CSR is actually kind of focusing in on one part of the story that we got. So we talked last time about going into the demand side asking when and then getting that series of events, right? So I went here, and I tried this, and then I use this, and then that happened, and I didn't like that, and then I wrote you the support request. So we're actually taking one of those events and saying, "That was a circumstance." And then they used this and then they got that result, and what we wanna do is we wanna give them a different path, a new story that's gonna happen from that moment. And I think this is something that, you know, people are interested in and that we can get into it in more detail. But the CSR is actually a really powerful tool because we can pick different moments in the chain, you know? We can go backward a step and say, "Well, why were you even trying to schedule an event?" Right? Or, "Is it actually arbitrary where you pick the starting points?" The critical thing is that we actually pick a point from a real story with a real struggle and look at the real cause and effect, and then we focus on that Delta. So we've got a bottom line for figuring out what's valuable and what's not.

Chris: I love it, and we'll be back with more stories and more tools and different uses for this tool and all those great things.

Ryan: We sure will. Yeah. And maybe we'll drop a link to the announcement about this feature into the transcript so that if people wanna see what we're talking about, that this isn't just talk, but this is, you know, this is real stuff that's happening, they can check it out.

[Here's the link: New in Basecamp 3: An all-new Schedule design]

Chris: We're building stuff. Absolutely. Cool.

Ryan: All right

Chris: Thanks, guys.

Ryan: Yep.