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 like it's things that pop up and what I like to say is projects that creep up because of longstanding 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, we've 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 feature better and what to improve 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 got to make it better. You know, like everybody on the team knows we have to make it better and 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 this sort of 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. And any to add to that, Ryan, is that sound familiar? 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 re-sync our dashboard.
And everybody agrees because there's a lot of, like you said, these 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 the docs and file section or the way that we have our 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 overhaul, 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's 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?
If there's a lot of moving parts to this feature and we start, let's say, 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 really good UI for dragging 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 going to make choices and how are we going to kind of, I don't know what 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.
So what do you 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 want to put a new feature out. Yeah, 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 is 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 got to integrate with Outlook and Google and there are protocols 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. Yes. I can't see the end of what I'm committing to and that comes very, very risky.
Even sometimes features that seem smaller can have ripple effects. You know, you offer, let's say, color labels on files in an app. And now, as soon as you do that, you realize, well, people are going to want to customize the colors. And then if we allow them to label, they're going to want to be able to bulk change the labels, right? It's just like one thing leads to the other, you know?
Yeah, yeah, yeah, absolutely. So, so there's this, there's this role. 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, in, in episode one, we talked about getting to what we think is, I can't use the word ideal state. What we think is a better state, which is basing decisions on demand, right?
The thing that we didn't want to have happen is everybody who listens, race out and cancel all their meetings and say, like, this is what I'm working on, right? It's like because the reality is time is flowing forward. We have resources we needed 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, wrong word to this good grounding and demand.
And we just need that we need to be in those meetings. We need to be productive in those meetings. And, and when you and I sort of thought about that, we said, it feels like when we're in those meetings, we're managing risk. That's kind of like what we call that node, right? Yeah, there's the stuff that's already going to 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 want to go and study. I'm going to do my demand research on this and get back to you in a while. You know, there's a lot of things that you can't do that with. So in those cases, the best thing you can do is actually work with, 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, the big hairy idea comes up where maybe for other people, it seems like a clear win. Of course, we should build a 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 going to spiral out in scope or whatever. I want to be able to say, hey, I'm going to take that on as the product manager. I'm going to take that on and I'm going to take that, put that into my hopper of things that I'm kind of chewing on and learning more about.
And we're not going to schedule that. I'm going to 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 we can't always say, hey, I'm going to go research that because otherwise everybody would just be sitting around all the time while we go to our research, right? So we also have to have this kind of, we have to have a sense of other kinds of projects that we can line up that don't have the same kind of risks.
Yep, and so that that working the hopper is what we think of as the other mode, right? So I have the first mode, which is managing risk. I'm playing defense. I'm trying to make sure we don't go into into some big unknown, some bad territory.
And the other mode is this, I'm 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.
And now let's have what is hopefully some concrete conversations on how to address this demand that is free from all of that, all of that risk. And we're going to get into the calendar example a little 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.
So 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. 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.
Yeah. One of the nooks and crannies. What does it feel like to have a nook and cranny? Yeah. So the nook and cranny feature, it's all about those little gaps that are already there waiting in the app where there's 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 going to 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 going to be something else that we're going to want to put on that copy screen. You know what I mean? We're going to say, man, I really wish we didn't devote that real estate on the screen to the folder drill down. No, like 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 going to 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 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.
Yep. So there's there there's edges to this. And it doesn't have that feeling that you described of the of the colored labels where it's like they're going to ask for patch operations are going to ask for customization. This is like the real estate is already dedicated. So I'm not I'm not going to 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's it's it feels more well defined and I can hand this off to the team and have them have them work on it. The last so I think that that was the first point we want to touch on with just these two modes. The last thing I'll say because I think these this is this is great.
And we talked about this earlier that the things to look out for are one feature 2.0 and anytime like it's one of those triggers anytime you come up it's like we're doing search 2.0. Yeah we're doing dashboard 2.0. It's like okay we've called it that but what what's the reason what you know try to dig back in and a lot of times you'll find yourself in 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 on the table and we say when we build this new feature all these people are going to 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 going to get better we just pile a lot of stories in and we say see that all this is 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 if 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. 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 then you don't have to make any decisions you can take your you can take your whole closet if you want to right it's only when somebody says like hey we've got this one this much space what's going to fit in there then you have to then you have very hard hard questions to answer and if the whole concept was framed as build a calendar or 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 or or if we scope it down to seven weeks or whatever it is right then you then you realize like well we 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 that homework that that thing where we take it in the hopper for our our kind of solo time.
You know because as the 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 and we don't need those other things because we we have a clear definition of what done looks like or what success looks like or what the problem being.
What the problem being solved looks like.
Absolutely so so what you you have a story around this on your team right there there was this I guess I'll let you tell it because you'll tell it better than I but but the way I'm interpreting is you have this anecdotal thing happening where people started talking about let's let's make let's do the calendar thing let's build a calendar let's make it better and and it's not that people are like advocating hard for this but it would it it's like murmuring.
And like it keeps coming up and just like random conversations things like that. Yeah. Yeah. Yeah. So the case that we had here was we we we knew that customers were asking for a full blown calendar the version of of of base camp 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 of base camp and we didn't build it into version three. And so there was this kind of general sense that that we didn't build something that base camp needs and and base camp needs a calendar right and 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 you know it's like 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 stream. The height of a meeting in the in the in the in the weekly view.
Does it mean integrations there's just like a ton of questions about what why what what what what do we need to build here for it to be good right when do we what do we need to stop. And it's one of those things with a ripple effects just don't never stop you know so it feels like a like a six month project minimum which for us I don't know depends on where you work but for us that feels like a like eternity you know what I mean.
Our typical big feature releases are our eight week cycles of work. So so we kept saying no to it but the thing is that you know these things they keep bubbling back you know 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 going to take that one.
I'm going to take that one is one of my research projects and I've got a handful of good kind of nook and cranny features that I'm going to 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 going to see if I can find an angle on this problem right and and we talked about that in episode one so what we did was we did these these customer interviews where we talked to people who had written in support and asked about needing a cat.
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 we needed to build actually we ended up with with a version of a calendar that we were able to release in in seven weeks.
With three people working on it so we really came up with something lean and I can show you actually kind of how we how we drew it this is using one of the tools that you and I've been talking about a lot it's it's a it's a sort of a technical product manager tool you know we call it a CSR diagram and basically what we want to do is we want to be able to spell out a very specific problem case where if that thing gets better then the next thing that we do is we can do that.
Then the feature worked okay so 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 the detailed struggle that happens on the demand side then we've got something to work again so I'll sketch it out here the the basic structure is like this we do we make three boxes
and there's three things that that we use to define the problem so the first thing is a circumstance so that's the situation that the person was in and and and the story that we were hearing whenever we talked to customers who were who were asking us for the you know we walked them back and we did the thing we talked about an episode one asking when right what was the chain of cause that what was the chain of cause of 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 to find a room that's available to schedule a schedule
a meeting there right so they're trying to schedule a specific resource and then the second thing that we use is the current solution and this is on the supply side so they were using the this the the plane agenda view that that base camp 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 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 it's the the the we say the result of that is is as 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 and this basically what happens here is this leads to the the struggle right this is this is what leads them to to write us and to seek out work around into 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 to a different calendar app so that they could see them you know so and and just to just to connect it back when when we think about demand and supply side language right this is another example of the reason that we had these long standing anecdotal like stories and things like that is because when the customers are creating the feature requests or they're writing into base camp right
they're thinking of the grid they see in outlook or the desk like the big desk calendar that they have on their desk where they can glance down at it and say like I've got I've got things on this day but you know like very quickly this day is empty right so they all they know this is not like to cut down customers but it's like the easiest way to describe it is like why don't you guys have a calendar view right
yeah it's what we all do we we define it as from the supply side we're like this is this is what you should build instead of this is what I need so it took the translate like what you're doing is into this diagram under under c under circumstances you're using the interview process to basically unpack that and say what it's not that you want the calendar is what happened and what were you trying to try to accomplish exactly exactly it's a specific case of using it where we can
understand the struggle right and then 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 going to do is we're going to say in the same circumstance they're going to use a different solution so this is going to be this is s2
and they're going to get a different result otherwise why why bother changing anything right you know there needs to be a different result and and now what what we can do here is we can we understand what the after needs to look like with what the different should be so we can say I can find a free day to schedule it right and then what what we what this what we do here is we we take that circumstance we take that result that we want
to do and and we put a question mark here and we let those things be the requirements on the solution space so what we want to do is we want to 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 then how do we build a calendar right
it gets rid of a lot of things right immediately I don't I don't I might not need integrations I might like there are things that I can I can start to set aside now that I have the situation in the result sort of tightly defined yes and it also opens us up to things that we could have never considered when we were in the box of it's got to 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 and then you pick the free day so we said oh could we do something like that could could it just be show me the open times and it's like an appointment booking interface and but then we looked we looked more closely at the at the use cases and we realize that a lot of time when you're trying to schedule a resource you you work with the other people who also use those resources and
you want to actually see how everything else is booked to make your decision you know if you're if you're getting a haircut you don't care who else is getting their hair cut and when you just either take the slaughter you don't
but if you're working with other people you might 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 when you're doing this kind of resource
allocation so so we what happened was Jason and I actually sat in a room and 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 and then there was this kind of different moment of creativity that happened in Jason pulls out his phone and he goes yeah you know check out this check out this calendar on the phone it's it looks like a month calendar
but it's just dots you know and you can't drag anything between the cells you you can't interact with them at all you can do is click on a day and then it and then it reveals the in the agenda view underneath the calendar what's going on that day and you can click click 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
that's not that is not as good as a real calendar right it's it's definitely not as good as a as seeing everything beautifully rendered you know like with 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 it it's a good solution right it's it's it's back to having a definition of better right the hard thing is if we just to find better calendar
then I need best in class I need to beat every other calendar at least be paired right so I need to build everything up to that yes but but now what we have in the in the R in the results side is something that I can actually measure I can measure design concepts against yes can I see the free spaces or not it's not can I integrate
with everything under the sun can I send invites can I receive alerts all that it's it's a very clear way to understand is what we're proposing doing a really laser focused job of of of answering this demand answering the demand that we identified in the first place exactly and the the real definition of success in the design concept it's it's here it's in the delta between the two
R's you know it's it's not about how are we better than other calendars or do we live up to the definition of a calendar from the supply side it's it's about there is a status quo and people were struggling in this circumstance and now if we replace the solution with this alternative have we made things better or not yeah so so back to your back to your
metaphor of that you know fishing with the net versus the spear right yeah if I I can build the calendar that is better in every way and what I'm hoping to do is catch some great use cases right because people use calendars and all different they're on the road or and they're 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 is the spear fishing we have identified one very specific struggle and now we are designing to fix that thing and we we should be able to see like you said that delta immediately yeah like the satisfaction should be it should go up immediately and we're we're not in this position where we're out there searching and saying did things get better did
get better for some people and worse for others and we're not sure what's working and what's not right that's a that's a real contrast that we're trying to highlight here so we ended up with a very concrete idea that we called we just called it dot grid and then we also had another thing that we called simplified agenda and basically what happened was we strip back the visual styling on the agenda because it was just going to 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 and and we said we're going to do these two things together it's going to be a similar experience to using these kind of a common phone calendar apps but it's going to be on the desktop and it's going to it's going to scratch the itch and we're going to get the thing done in a single one of our typical working cycles which we have eight weeks cycles of work and we actually ended up finishing it early and getting it done in seven weeks
but what did you finish so because it's more than design and engineers like documentation support like what did you actually get done because that's that's that's that's astonishing for me three 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
well you know it's all in the scope you know because the scope was tight and also there's also technical decisions that that that allow us to do that you know if we had to build a native version for iPhone that would be a totally different thing but we because we were able to use a hybrid approach and reuse our web views on the on the phone then then you know what we really had a very manageable scope here but of course that's part of that's getting into a whole other area of of is that we're going to do that
area of a discipline of of of how we only build what's absolutely necessary to scratch the itch you know but the thing is that if you don't have definition of requirements that that is that specific you're never going to get there you're never going to be able to to chisel the thing down and and and get that scope smaller because you're always going to have the what if's right it gets bigger if anything 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 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 you know from what we talked about in the beginning of the episode is 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 to find a free date schedule but it would cost us ten times as much and who knows how many open ended you know there's too many rabbit holes there
yeah I think this this this presumes that you have an eye for simplicity for getting the most simple elegant sort of solution to the prep if you're not worried about resources and you're not worried about complexity and and risk this tool is not necessary go like don't mind waste and then ship a whole bunch of stuff that you can never take back that's going to be in your way for every future iteration you want to do just have at it build the calendar it'll be it'll work out great
yeah so hopefully what we've done here is illustrate sort of the next step so when we think about building an episode one we get to the notion of 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 feature request for a bugle cross coming in it's a it's a negative result and now we can like you said draw those lines down it start to plug different solutions in and have conversations around is this is this bloated is this an over-end
near thing if we're just trying to figure out how to see the free spaces do we really need to build all this stuff right and we can start to have some better conversations right yeah just a time together like you were saying the the CSR is actually
kind of focusing in on one part of the 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 used this and then happened and I didn't like that and then I wrote you the support request so we're we're actually taking one of those events and saying that was the circumstance and then they used this and then they got that
result and what we want to do is we want to give them a different path a new story that's going to happen from that moment and I think this is something that you know people are interested in 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 to step and say well why were you even trying to schedule an event right or there's it's actually arbitrary where you pick the starting
point the 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.
And a lot of and we'll be back with more stories and more tools and different uses for this tool and all those great things we sure will and maybe we'll drop a link to the announcement about this this feature into the transcript so that if people want to see what we're talking about that this isn't just talk but this is you know this is a real thing that's happening they can check it out we're building stuff absolutely cool all right guys yep.