Ryan Singer: Framing and Hard Conversations

• Slides
• Transcript
• About the Speaker
• Join the BoS community

You’ve done a mountain of customer research. There’s a million ways the customer is struggling and customer discovery and shaping have helped you define the possibilities. How do you make sensible decisions about what to do when you have too much information?

Getting technical, design and business people together to figure out what you’re saying yes to before we commit to building it is shaping work. Now framing work begins and that is the point where you should expect really hard conversations. Framing is about the problem and the business value. It’s the work we do to challenge a problem, narrow it down, and to find out if the business has interest and urgency to solve it.

Framing is about understanding the business tradeoffs involved in building new features you could build and making informed decisions about what to prioritise. The customer says they want feature A. What will the customer do without it? How much resource will it require to build? Will the feature help you gain customers? Without it will the feature lose you customers?

Ryan shares some trusted frameworks and tools that can help you to define what you’re going to go invest your precious time and energy into next and help you answer the question, what do you say no to?

Slides

Find out more about BoS

Get details about our next conference, subscribe to our newsletter, and watch more of the great BoS Talks you hear so much about.

Transcript

Ryan Singer

Good morning. I’m very happy to be here in the in the first spot. It means that I can, you know, put some disturbing influences into your subconscious, and then they can stir around, and then we can have a lot of conversations over the next couple days. So this is what I would like to do, is, you know, plant some seeds that can make you think about some things. And the topic today is, like, what is framing? Framing is actually some technical word from some stuff that I’m doing, but we’re going to find out what this word framing means.

What I really want to talk about is how we use time, and especially when we’re getting into situations where we are, we have some kind of a product development flow where, in theory, there are things that are meaningful to do that are appearing from all kinds of different corners in the business. It might be sales, it might be customer success, it might be we ourselves, who are in leadership roles, have opportunities or important things that we think are worth doing. There’s all these different pressures about what we might do, and if we’re not really conscious about how we narrow down the problem we’re solving, or how we really figure out what is the itch that we’re trying to scratch with the particular effort, then what can happen is the time gets longer and longer, the projects drag out and out, and it’s really hard to make trade offs, and meanwhile, our engineering teams, our build teams are blocked and busy with the big, long thing that they already didn’t finish when we have the new thing we want to do, right? So how do we use our time in a really conscious and meaningful way? And doing that using time well usually involves having some hard conversations.

And so I want to talk about sort of what does that look like, and I want to give you some tools for how to have those conversations, or what to have in your mind as a kind of mental image when we’re getting into these difficult conversations about what are we doing and what are we not doing, and how can we be focused so that we use our time in the best way possible.

About Ryan Singer

Maybe I should tell you a little bit about who I am and why I’m talking about this. I was at 37 signals, the makers of Basecamp for 17 years. I started off doing user interface design, and then I realized I couldn’t make my design happen if I was always waiting for an engineer to build it. So I learned how to code. And then when I was this person who had one foot in the design side and one foot in the engineering side, all of a sudden I realized that I was some bilingual person who could be useful. I kind of became that person who could connect the different parts of the company to make sure that we really got things finished and that we could all speak a common language as we were making decisions together. So I ended up going more into kind of a product management and then head of strategy role.

And then I wrote this book, Shape Up in 2019 which is about our experiences of how we actually figured out how to consistently ship things fast and enjoy the feeling of moving all the time, and not being stuck and then since then, I’ve been helping teams with these kind of things.

The Value of Time and Building

I want to start off with a little bit of common language, and I also have two assumptions that I want to check with you, and I hope that this isn’t an unreasonable assumption. I want to work backward from engineers building something, and oddly enough, this is something we don’t talk about very much, but I’m going to make an assumption here. I’m going to make an assumption that when you imagine engineers spending time to build something that you view this time as expensive. Yes? Okay, thank you. We’re off to a great start. Okay, this is going to be fine. All right.

So if this time is expensive, if it’s contentious, if it’s hard to agree on how to use it, if even when we agree, the engineers are too busy with bug fixes and the never ending rewrite and this infrastructure thing and who knows what, right? If this time is really valuable, then we need to figure out, what can we do going into this time box so that it’s used well? And I’m just going to give us some language here. Everybody has different language for this, but we’re going to use these words in the presentation.

Shaping vs Building

So there’s a step immediately before we build something where we have to figure out, what the heck are we actually building. And I’m a little embarrassed to have to point this out, but we are in the universe where a lot of people do something called scrum. I don’t know if you’ve heard of it. And scrum is something where we say, well, we give up on knowing what we’re going to do. We give up on being able to estimate. We give up on being able to make a promise. So we will do something two weeks at a time until you we all get exhausted and stop.

So this notion of shaping is that there’s some work that we’re going to do to actually understand, like, what is important and what are we actually going to go build? So imagine the builders appear at the site to build a house. They appear at the at the building site, and they don’t just have a bunch of tools and materials, but no blueprint, right? There’s actually an understanding, This is what we’re going to go do. So that’s the shaping. That’s on the solution side. It’s on the building side. It’s like, what are we going to go make?

But of course, if we’re going to make something, if we’re going to invest time in building something, and if we’re going to create a plan of this is what we’re going to build. Before we do that, we have to have some understanding of what is the problem that we’re solving, which of the many problems and opportunities are we actually choosing to spend time on right now? And this is what I want to use this word framing for. So we can think of kind of framing the problem, framing the opportunity this is looking at it more from the business side, more from the customer standpoint, trying to figure out where the value is, where the itch is to scratch. And then if we understand this out of all the different possible problems we could be working on, is the important thing to do next. Then we can go into how do we shape that? What does that actually look like as a building plan or as a concept, or as a solution idea, right?

Framing the Problem

And then, of course, when we are identifying which problem, which opportunity is the thing that is meaningful to do next, that has to be informed by some bigger picture, and there’s going to be some sort of now, I’m going to be, we’re going to pretend that there’s just some strategy, you know? But of course, like very often, there isn’t strategy. There’s just a constant barrage of different pressures, right? And so there can be, but there are different, let’s say, imperatives and pressures and objectives and things that we kind of have to do based on what’s going on in the business. So this is a little bit of a big picture of where we’re at.

I want to zoom in on this framing work now to talk about how we can narrow down our understanding of the problem. A lot of times we’re churning over here trying to make things go better, but it’s actually our lack of clarity and focus are on what we’re solving that is the real problem. It’s further upstream.

The Decision Moment

So here’s a picture that I like to use for when we’re in the this is what framing is all about. So there is a moment in shape up, we call this the betting table, but there is a moment where we need to make a decision about how to use some time that’s coming up, and there’s a million problems and ideas and requests and competing arguments for what is important. Sales wants this, and the CEO wants that, and customer service is banging the table over this, that, and the other thing, and I want to this, is the second assumption that I need to check with you. This one’s a little less obvious.

The second assumption is that when we think about making a time investment, that we imagine finishing something like we’re going to start doing something, and then there’s going to be an end, and when the end comes, we’re going to be done. And this is finite, okay, so this is, of course, it sounds a little bit funny, but in practice, what we often see is something more like this. You know, sales says that we need to have a new set of permission options around this part of the of the app, and changing those permission options touches the user model. So we’re going to, like, start working on that thing. How long is it going to take? Engineering says, Oh, it shouldn’t be too bad. And then, and then, and then there’s basically a blank check, right? Because it’s the next most important thing. Sales needs it. We have to do it, but then we get lost in this never ending dragging thing, because we just said we have to do it, and we didn’t really get clear about what’s the maximum time investment that makes sense and practically, operationally like technically, What can we actually do that’s going to land inside that amount of time? So I’m not talking about making a decision that’s just open ended. This is the thing we’re going to do next.

The other thing is, I’m not talking about a decision about a little, tiny slice of time that doesn’t make a difference. Again, as now you may have heard of this term sprint. So if we have a two-week slice of some big, important thing. If we try to say we’re going to get really clear about how we’re going to spend that two weeks, it’s not going to make a difference, right? We can’t. We can only do so much in two weeks. There are a lot of meaningful, small things that we can do. If we have a small, little, juicy fix or a hack that’s going to remove an obstacle, or we’re going to be able to improve activation or remove a pain point somewhere. That’s great, if we can do it in a two-week window. But this is not a strategic unit of time, right? This two-week sprint is an implementation detail of the scrum sausage machine. You know, it’s just how the machine works. It’s not a strategic unit of time. So I want to propose to you imagining something which is a little bit more like a six-week block of time. And there’s a lot of opinions about this in the in the universe of shape up, but just imagine that there’s a unit of time that’s big enough that we can actually finish something that works, that scratches an itch, and it’s small enough that we can see the end from the beginning, and we can actually make a commitment that it’s going to be over, right? That we’re going to reach a completion point. We’re going to finish something okay, if you can allow this mental image of making a decision about a unit of team’s time, this can happen in a couple different ways.

One way this can happen is if you are in kind of a shape up model, then you have this notion of a new cycle of time comes, a new unit of capacity comes from the team, and we’re deciding case by case how to use that in a lot of teams. That’s not the case that you just kind of that the engineering leadership is giving you a kind of a free, open, ready team every six weeks and saying, here’s a clean plate put on it, what you want, what you like, that’s a quite luxurious situation. It actually does exist in some teams, by the way, and it’s an amazing thing. But it’s a bit rare.

What can happen more often, if you want to be able to relate to this picture, is there are some contention around what is the idea, what is the thing that sales wants, what is the problem we’re trying to solve? And you have to imagine, how can I kick and fight and squeeze my way into the time of the engineers so that we can make that space to do something right? How can we insist on carving out that time to do something? That’s another way to think about it.

Hard Conversations in Practice

So what usually happens when we have an idea or a problem or a request or something from sales that we need to do is we don’t have the hard conversation at all. The idea comes in the form of the solution. We need notifications. We need push notifications in the app. We need to build a dashboard. We need to add the permission option. We need to make the template builder right. We have to integrate this thing with the SSO, like, whatever it is, right? There’s this thing that we have to do, and we just say yes to it.

So when we talk about hard conversations, the hard thing, one of the hardest things, is to be able to push back on this in a way that feels like progress for everybody. You know, because the sale says, look, the customer insists that they need additional permission options when they upload the invoice documentation, if we just say why? Well, they’re a big customer, and they say that they need it and. But why? And now that’s not a productive relationship.

So what we want to be able to do is look at everything that goes wrong, if we just take these things at face value, and probably I don’t have to describe this to you. I think you’ve seen this before, right? We say yes to notifications, but we don’t actually know what it means, and it spirals out. We say yes to the permission option, and before we know it, it’s a giant scope of things, and we don’t see the end of it. So there is a necessity to somehow reverse engineer what is this request actually mean for us? So we need to be able to understand it in order to resource it and to weigh it against other things. The other thing is, there’s an element of, if I’m playing the role of the person that needs to go get a build team together and make one of these things happen. I need to be able to have a lot of answers for the build team so I can play this off. Not in the sense of like, I don’t want to do this and I’m challenging you, but more like, I need to ask you a bunch of weird questions about this that even sound like stupid questions, so that I can get so much understanding about it, that when the build team is asking questions, I have good answers.

Understanding the Demand Side

So this is a way to lean into this, a way to think about this is, I’m borrowing a page from Bob’s book here. There’s going to be a few things from the universe of Bob here. We’re at Business of Software. So it’s very fitting. We can say that all of these descriptions are from the supply side. They’re referring to what to build, and to have the hard conversation about, what is this really and is it really important now? And what does it mean? We can flip to the demand side.

So the demand side isn’t, what are we building? The demand side is, what is the problem? What are people struggling with? Why is now the right time? You know why this, instead of something else, it’s all the context of what’s going on in the real world around this around this thing. And here is the mental picture that always works for me, that helps me to have this conversation. So if someone says we need a permission option, or we need notifications or we need a calendar, I just try to imagine that there is a gap in the universe, and the person who’s saying they need something, they’re like on one side of this gap, they’re almost one side of this river crossing, and they’re saying, Look what I need to get over there, and what I have isn’t working. And so I need permissions. I need notifications. I need a calendar. Whatever it is that that request that that thing that they’re asking for is that supply side idea, right?

So they say, like, I need a calendar, but we don’t actually know what it is that they’re trying to get to, what it is that they’re stuck, what they’re trying to kind of cross over to, so the shore that they’re on. We can call this the context. You can call it a million things, but we’ll just call it context today. And the mental trick that really helps to have a productive conversation here is to play a little game where we say everything on this side is about current reality, not about an opinion, not about a wish, not about what somebody hopes for, but like, what is going on, what are people feeling today? What’s not working? So in the current reality, what is going on, and then on the outcome side, we can talk about, if things were different, how would we know, right? If things were better, how would we be able to tell? So that’s kind of like where we’re trying to go to, what would progress look like.

Case Study: Notifications

So let’s take an example of this. So this is actually a case study of some friends I worked with. Notifications was something that leadership was asking for, for like 18 months. And why was it so hard to get notifications? Well, there’s a story behind it. Basically, they had a kind of an intranet, which was serving a big global org that had many, many branches. It was a kind of a global nonprofit org, and they had many branches all over the world, and they had built up this big intranet. And this intranet was web based. There were individual project spaces and areas that all the different members of different global branches could go to. This thing was not mobile friendly at all.

There was a very small web team. There was no iPhone team. And the idea of building a notification, a push notification, on a phone, seemed very far away, because we don’t even have native developers, and we have a million features across this big surface area, it just it kept coming up and it wasn’t happening. And the thing that was weird about this was that, I kept hearing again and again and again, we need notifications. We need notifications. And there comes a point where you have to ask, okay, look, this is never going to happen unless we can understand this better.

So I got into a room with leadership, and I started asking them some questions. What in the world do you mean when you say notifications? If I ask from the supply side, they’re going to say, oh, notifications means when somebody posts something on the internet, my phone goes ding, right? Which I understood. You know, what are we actually trying to solve here? So I go into the, I’m not drawing this on the wall, but I have this in my head, okay? And I’m saying, Okay, you guys want notifications. So what are they doing today without notifications, and what’s going wrong as a result of that? And the story that they start to tell by my digging, is we have an old mailing list.

We have an old mailing list, and this mailing list has like tens of thousands of people on it, and it’s not integrated with the new single sign on system that we recently launched. And the single sign on means that we know who everybody is and that they should have access, and we know they’re standing in the organization and everything like that. But this old mailing list isn’t at all integrated with the SSO, and we have some changes in the organization, and there are some big conversations happening in some boards here and there, and this newsletter is the way that we send out the announcements about what’s going on, and we just don’t know who’s on it. So we don’t have a way. There’s some sensitive things happening in the org. We don’t have a way to send out announcements where we actually understand who is receiving those things.

So they’re getting more and more and more nervous. I look at this and I say, interesting. I don’t see much about phones and native. Where’s the notification part? So basically, what they were really imagining was, Oh, we’re going to be able to send announcements to verified identities instead of who knows who these 40,000 people are on this old email list, and we’re going to be able to turn off that list that is giving us nightmares. And of course, when I said, if you could literally just send emails from the internet to the verified identities, would you be satisfied? And they said, well, we kind of still want notifications. But yes, right? So that’s why I have this last point here.

They still can imagine a bunch of really interesting cases where it would be nice to have notifications, but the reason there’s urgency, the reason there’s pressure to do something is because of the situation with the mailing list. What we really need to be able to do is move off of that. Once we understood this, then we could reframe the whole problem. And we came up with a different kind of little supply side idea. Instead of push notifications, we came up with this idea of, like, what if there was something like a news feed in the overall intranet, and this news feed is something that you could follow, and it would send you emails, and it would all go through the SSO, so we reached a point where we’re looking at each other in the eye and we’re saying, I think we have understood the actual problem here. Having understood it, we narrowed down what it is that we’re trying to solve, and now we don’t need to figure out how to hire an iOS team. We don’t need to figure out how to integrate notifications with a million different features across the entire internet. We were able to shape a solution that had just a few moving parts.

So one of my favorite quotes about shaping comes from Bob here, you can’t put 10 pounds of dirt in a five pound bag. This is this a polite version. This is high wisdom. You know this statement. And so if we imagine that we want to actually build and ship something in under six weeks, here we can actually describe a solution that fits into the bag, that fits into that time box. We can say, Aha. So we already have the notion of projects in this intranet. We’re going to add the ability to follow and unfollow, then we’re going to use that follow unfollow bit to know which project updates to reveal on the news feed that we put on the home page of the internet.

We’re going to have email notifications when a new thing is posted to a project that you follow. And we’re going to make mobile friendly, web-based detail pages for the news updates, so that when you get the email on your phone and you click the notification that you get in your email, it loads the internet, but you can read it nicely on your phone, right? And then, of course, there’s a couple other things, like the ability to unfollow and blah, blah, blah, but basically, we came to a point of like, if we do this, this, this, this and this, we can accomplish it with a small web team. We can get it done in less than six weeks, and everybody can be happy. And this is actually what we did, and it was a palpable sense of relief when we actually shipped that.

And the other thing that’s quite interesting is having narrowed down the problem so much that we threw native notifications out of the window, we actually set ourselves up so that we could easily see a path to native notifications. And today there’s actually an iPhone app running that uses mainly web views, and they were able to integrate push notifications because they had all the end points they needed. Based on this work. So sometimes completely ignoring the thing that we think that we want, and redefining the problem gets us closer and faster to that original thing even.

Case Study: Calendar Feature

I want to give you another example of this. This is an example that’s in the book, Shape Up. It’s an example I like to use very often because it’s so easy to relate to. But we didn’t yet have the word framing when I wrote the book, and I wanted to look at this from a framing lens instead of a shaping lens.

So we had this problem at Basecamp where we didn’t have a calendar in version three of the app. We had built a full-fledged calendar in the past, and it was a giant effort. It was very complicated, and it turned out that people didn’t even use it. They used it very little. So we had left the calendar feature out of version three of the product. We had just had a simple agenda list, but we kept getting these requests over and over and over again. Can we please have a calendar? We need a calendar. We need a calendar. And the requests kept coming. Even though we had built a calendar in the previous version, people didn’t use it. They’re still saying we need a calendar.

So this is another case where we said, look, we have to have the conversation around what does this actually mean? When we started digging into what calendar meant, again, we got to some clarity. So what are they doing today without a calendar? What’s going on? What we found out is that customers were trying to schedule something with a third party. So they had, sometimes it was a physical resource, like a meeting room. Sometimes it was planning a milestone in a project. They’re trying to schedule something with a third party. They can’t see the availability on the existing agenda view, all they could see was the scheduled things in a list. They couldn’t see the time that was available. And when they tried to hack another tool and integrate it with Basecamp, nobody knew how to find it and where to go to see the calendar. So just using a separate tool for the calendar wasn’t going to solve it. And the outcome we understood we needed was we didn’t need to build a calendar. We just needed to show empty spaces.

This was all about being able to make a decision around where is the available time to book something, and the missing piece was just being able to see empty space. And if we could just show empty space in our existing agenda view, we could stop saying no to all these requests, and we would be able to, well, basically, we would be able to solve the problem. This is something that we could imagine. There’s got to be a solution to this again, in under six weeks, we’re not going to spend a year and a half building a calendar again.

So we came up with this concept that we called the dot grid. And basically what happened here is, once we understood, if it’s just about seeing empty space, I don’t have to have high fidelity interactions to drag and stretch the calendar events. I don’t have to have a fancy, complicated like meeting planning features, or I don’t need to have a lot of special notification features. This is just about booking something. So we came up with this concept when we brought it into shaping, which was like if we could just have something almost like an airline calendar, with two months, and we could indicate when there is a scheduled event with a… On the day, if you tap a dot, then we can scroll an agenda view underneath, and we can either see the empty space when you tap or we can see the scheduled events. And we’ll have some navigation to go forward and backward in the months. And then we’ll have some kind of an add button so that if I’m looking at an empty space, then I could just hit a button to create an event there.

Again, if we kind of look at the list of the kind of main moving parts, you can see this is something that we understand, that we can get our hands around if we just say calendar. It could be Google Calendar, right? It could be Doodle. It could be integrating with all kinds, with Exchange, with all kinds of other Outlook calendars and stuff like that. This is a very specific idea. So, this is something that we could because we were able to understand that we just need to show the empty space we could get to a very simple idea here. So, this was a little bit about narrowing down the problem.

I want to point out that when we’ve narrowed down the problem, when we’ve done that framing work, it’s not only helping us to get to a simpler solution idea. It’s not only helping us to spend less time and still scratch the itch. It’s also a big help when we’re inside of the build of the time box, when the team is actually supposed to be working on this and building.

From Shaping to Building

So how does this usually look if we kick off a project? Let’s say that we framed and shaped and we came to the point where we have this clear concept normally, what would happen in a kind of a scrum universe is we would produce some sort of a document, or there would be a big, kind of a whiteboard with everything worked out. This is what we think the project is. And then when it came time to kick off the project, we would feed it through the paper shredder. This is the, what is it called? The there’s a scrum ritual, you know where you create tickets, right? So this is the paper shredder. So we take a big idea, which is one idea that is has full of meaning and connection, and we can see, aha, this is how all the pieces connect. And then we and now we have 100 tickets, right? And we imagine that these 100 tickets will all glue together again into something that looked like the picture in the first place. Of course, it usually doesn’t work out that way, because if we give a developer a single ticket, you know that says scrollable agenda, it’s like, what is that? And how do I know if it’s working? And how do I know if it’s done? And there’s going to be all kinds of questions and all kinds of problems and inability to make decisions they’re not going to have the context they need to make trade offs or judgments or creative decisions. So this paper shredder technique has its faults.

Tickets, by the way, are fantastic for isolated pieces of work that have urgency. This is the whole universe of help desks. They know what they’re doing. The reason that a help desk is based on the notion of a ticket and an issue number is because there’s a person who is who is waiting on the other side of this thing, who has a problem. And we need to know status along the way until we fix it, and we have a dedicated capacity for handling those tickets and making sure that people don’t wait too long. That’s the universe of the help desk. But in the project universe, splitting things out into tickets doesn’t have any meaning. It’s actually, we just inherited this tooling from a different problem. If we’ve clearly framed and shaped, what we can do is we can just give this to the team. We can say, do you understand this? They can say, Yes, we understand that. Do you understand the problem? Yes. Do we understand the solution approach? Yes. Do we see what we need to build to make that a reality? Actually? Yes. So do we need tickets? No, we can just go build it. So when we go into the time box, the perspective from the builders is they have a kind of stack.

There’s some implementation work that needs to happen at the lowest, most concrete level. There’s code that has to get written, there’s design that has to get implemented. There’s front end engineering that has to happen. There’s pixels that have to be painted beautifully, right? There’s a level up from there, which is the big picture of the shape. This is the concept of what we’re building, and then the level even higher of the frame. This is the itch that we’re scratching. This is the problem that we’re solving.

When we have this whole elevator where we can go up and down in altitude to figure out where we are and what we’re trying to solve, we can be very productive the engineering team can be very productive inside the build phase. So it helps to think a little bit about what happens when we don’t have some of these things inside of the build phase. If we’re inside a time box and we’re supposed to be building something, and we don’t have a frame. So somebody created a concept, and here’s what we’re going to go build, and it’s all supply side. It’s just the solution idea, what’s going to go wrong here? Does anybody have any ideas of what could go wrong if we don’t have the frame?

Yes, so when things change then, so the project can kind of wander off into some different direction. That’s very good. Yeah, anything else?

Very good. When we run into a technical difficulty, we don’t know how to adjust, to make a trade off, because we don’t know what it is that we’re aiming for.

That’s a very good one. That’s a very good one. Because the frame is actually the, what could you say? It’s like a kind of macro unit test for the entire project. It’s like, does the project do what it’s supposed to do or not? What I want to point out here is, very often what we see is that the frame tells us when we’re done, which is kind of similar, by the way, to this point about the test, it tells us, is it working or not? If we don’t know what we’re supposed to achieve, then that the build team, very often, is going to boil the ocean and the scope is just going to keep expanding. Or when the technical complexity comes up, instead of saying, how do we make a trade off, they’re just going to say, well, I guess we have to do this and this, right?

So every time the team comes into a situation where it starts to get harder, and then, instead of saying no and figuring out how to narrow down, they say, Well, I guess it’s harder. Another two weeks, another two weeks, another two weeks, right? It’s because we don’t have that clarity about what we’re trying to solve.

Similarly, if we sometimes, we see teams, especially, who are just trying shape up, where they just do the framing work, and then they think, I’m going to give this to the build team, and I’m going to give them, let’s say, full autonomy. You know, they’re going to figure out how to do it. I’m going to give them, I’m going to empower them by not telling them what to do, and what happens when we empower people by not telling them what to do?

You’re lucky if they build anything, because usually what we see is we don’t see any movement. We see a lot of discussion, oh, what does it mean? What should we do? What is it really? You know, because imagine you have a PM and some engineers, and they’re all under pressure to build the right thing, and they don’t have enough direction. So this is often you’ll see the PM saying, oh, we need to do some more research. We’re not ready to start. And then we started shaping. We had another question, so we went back and we needed to do some more research, right? And you have the never ending cycle of user research, because we never feel clear enough about what it is that we’re actually doing.

When we have a frame and we have the shape so we know what we’re solving and we have direction on the big picture of what to build when these little questions come up about, what about this? Don’t we need to color categorize the events? Every calendar has color categories. It’s a reasonable thing, especially when you’re from the perspective of a designer or the builder inside the time box, and you’re saying, oh, I want to make this. I want to make this good. I don’t want anyone to think I did a bad job here, right? Oh, we didn’t do color categorization. And we can say, what do we see here that tells us we need that, right? Do we need color categorization to see empty space, to see availability? You say, actually, not. Okay, then we can cut it. That’s how we can have the conversation, is by playing it against the frame.

What about multi day events, instead of dots repeating in the cells, wouldn’t it be better if we drew beautiful bars that for each multi day event that wrapped around the calendar, like it would be better, right? Well, how much more would it cost, right? I mean, a dot that repeats inside of a cell, versus rendering a variable length thing that wraps around in different calendars and months and everything. I mean, you’re talking about easily another six weeks of scope just to fit, just to get the front end engineering for that to work reliably. We can say, Ah, I don’t need that. All I need to do is find the available days. Can we still manage without doing that? Yes, we can still do it. So this is what enables us to keep the scope under control.

Choosing What to Build Next

So until now, we talked a lot about looking at one effort, one problem, one thing that we’re trying to solve, and narrowing it and getting clearer on what it is through the framing. A big aspect of framing is not just narrowing down one thing, but actually choosing. Because we have a lot of different options for what we could be investing time into next. And this is often a challenge figuring out which is the thing, and if we look at it from the supply side, it’s very difficult. Notification versus the permission option, versus adding this versus adding that. I mean, when we look at it in terms of solution, they all sound good. And if we look at it in terms of personality, then we just have politics. Sales wants it. The CEO wants it. Support wants it. So we can kind of pretend they didn’t ask. Do you know what I mean, like, it’s not good for relationships, you know? So we don’t want to operate that way. We want to be able to look at the things on the merits of the things, and say which of these things is going to have more impact and have actually get us to where we all want to be as a business.

So this is another place where flipping to the demand side can be a very helpful kind of tool in the conversation, because the conversation always kind of naturally falls back on the solution idea, or who’s asking for it, or some kind of personal stuff. If we want to really step back and look at it more objectively, we can use this picture of the person trying to cross the river, the struggling moment of, I’m in this context, and I’m trying to get here, and we can weigh the difference in the current version in the context. So here’s an example.

Let’s say we have two different projects that people are debating about, and we only have one time box coming up. So there’s this idea where we have a request from customers to be able to upload archived invoices into the system of record. And we also have an issue having to do with permissions, where some customers are saying they want to be able to grant access for searching old contracts both sound reasonable. They both have people asking for them what to do. So what we want to be able to do is especially focus on the context for each of these things. What is going wrong in the current world? So where is the pain greater? And then we can make a comparison. So I’m not even going to fill in the outcome. I’m only going to look at the context side of what’s happening today. What are they doing today, and what’s wrong with that?

So if we start with uploading archived invoices, and we investigate and we can hear a story that, well, there’s no place in the system of record for the old invoices that weren’t generated through our new invoicing system. And what are you doing instead? Well, we’re uploading them into a folder in Dropbox, just because we need to have them stored. And what’s wrong with that? Why is that a problem? Well, it’s just kind of feels gross to have things in two systems. Do you know what I mean? Like, it’s kind of, I’m sure it’s going to be a problem. Probably is. There’s maybe going to be a compliance review coming up, right? And if it’s not in the compliance system, then there might be some problems. So this is real, right?

But by the way, sometimes we try to weigh impact with, is it three stars or four stars, or is it a 3.5 or a 3.8 I don’t know what that means, but if we look at the actual story, and we talk about, how much does this hurt, and how bad is this, and what does this mean for the business, we can have a meaningful, qualitative conversation about, like, do I feel it here? It’s kind of almost a true false, right? Does it? Give me the heebie jeebies or is it like? Well, probably we can live with that. Compare that to another story.

We need more permission options to be able to grant access so other people can search contracts themselves. Well, the story here was that we had someone who was working on lining up a major deal. They were trying to close this deal, and they needed to look at some past contracts to see how it was, how the engagement was designed before. Okay, the person doing this needed to ask around to figure out who had the access to load up the past contracts in the system of record, because they themselves didn’t have access. So they’re asking and asking around. Finally, they figure out who is the person who has the right administrative access to dig through the old records.

They ask them to search for them. They’re waiting. This process is taking longer and longer, and in the end, I mean, they’re up all night, and they nearly missed the deadline for when they were supposed to be providing the answer to close the deal because they couldn’t get it themselves, and it took so long to get there. So this is a very pissed off customer who had a really bad time.

Okay, this is a case where we can say, I don’t know if that’s ever going to happen to somebody else, but I definitely don’t want it to right? It’s the kind of thing where, when you hear about a customer being almost missing a deadline, and your system of record didn’t get them what they needed to get to your little like, we might have a problem there. So this is the kind of comparison, not looking at the solution, not looking at how great it’s going to be if we change it. But actually is that, can we see a difference in the pain side.

Validating with Data

I want to touch on two more things. When we hear stories like this, what can happen sometimes is some of us might have a visceral reaction where we say. Ah, that’s going to happen again. And if it happens again and again and again, it means this for churn, or it means this for satisfaction, or whatever, right? There’s other people who are going to say, it’s just a single case that’s not real. So there is a quantitative aspect of this, which is, what can we do to come to a clear conclusion together if this is real or not? And that sometimes can mean there’s an opportunity to measure what is described here, to see how often it happens or what the severity is.

So here’s an example of when we can’t agree on if this is real or not flipping over to the quantitative side. We had a project at Basecamp that I wanted to do for years. I was imagining we were going to add this setting to people if they were truly involved in the project, or if they were just kind of observing as a manager, or they just needed access to look in from time to time, and I was sure that we needed to do this, and I did my best to make the case. I mean, I tried again and again and again to make this feature happen.

Here’s the story I was telling. Look, there’s a whole bunch of projects that I’m not involved in. Basecamp is this project management platform, and it sends a lot of notifications for the work that’s happening in projects you’re working on. Okay, so there’s a bunch of projects that I have access to, but I’m not actually involved in every day, and I’m getting all these notifications clogging my inbox from things that I’m not actually working on. So I open Basecamp, and it’s like 13 things that have nothing to do with me, and then one thing that’s really important, and then five things that have nothing to do with me, and two things that I care about. And I’m looking at this and I’m like, this is terrible. This doesn’t feel like it’s helping me. This feels like junk mail, right? And I’m saying, We got to do something about this.

So I proposed this solution. What if I only got notifications from projects I’m truly involved in. What if we knew the difference? And then I could still look at the projects that I’m not actually involved in. I would still have access, but they wouldn’t be bothering me. Seems like a no brainer. The problem is that there was a lot of natural resistance. There was anxiety about changing the people management screens, because they were full of UX problems that we had wrestled with for years. It was one of those things. Every time you went in to change something, it was just like a never-ending problem of difficult experience issues.

And the other thing is that we had this culture against adding steps. We didn’t want to ask another question when we were doing the invitation process to join a project. So there was this resistance. But I said, Man, maybe if we could only see how real this thing was, we could finally get over the hump. So I finally defined a metric.

I got into the data systems, and I defined some metrics. What were the metrics that we could look at that would be able to measure this so simple metric for each user. Let’s look at the projects they actually look at versus the projects they have access to. And for the notifications, the ones that they click on, versus the ones that they are the recipients of, we can just look at the proportion. Just think of it like a signal to noise ratio for how well these things are working. And this is just a graph from our own.  I can show you data from our own account, from our own company. Basically half of us were constantly seeing stuff that we weren’t involved in, like half of the volume of stuff that we were looking at in Basecamp we weren’t even involved in for. This is the majority of the company is, like 30, 40% of the stuff I’m looking at is relevant to me. So when we actually saw data on this and we could look at it on a wider basis, then we could finally say, Oh, this is real. You know, there are tons of people seeing stuff that they don’t want to see, and thinking, Oh, I don’t like Basecamp, right?

So finally, then this was what was able to push us over and say, this is a real thing. And then in Basecamp 4, this is finally a live feature, where when you add somebody to a project, you can say, are they on the project, or are they just following it? And then they get totally different notification behavior, way cleaner, much, much better result there.

PMs, Strategy, and Responsibility

W looked a little bit at this whole arc from some bigger imperatives and some things that are driving us from a strategic level down to the problems and opportunities we choose to focus on one, one project at a time, through shaping and building. And a big part of this is we can sometimes make mistakes around who we expect to be involved in which conversation and how we expect people to contribute. And one thing that I’m seeing kind of a lot of these days is people who are hired at.

Product Managers have an expectation that they are going to be working in strategy. And I think I know why, because I’ve been to product management conferences. I don’t know if you’ve ever been to a product management conference, but if you go to a product management conference, you sit in the audience and there’s about 10 Junior PMS to your left, 10 Junior PMS to your right, 10 in front and 10 behind. And then somebody stands on the stage and talks about company strategy. Have you ever seen that? Yeah. What Junior PM is being invited into the exec meeting to talk about the strategy for the next quarter. That’s not real. It’s not real. There’s an aspiration. There’s some fun things to talk about there. There’s some interesting things there, but it’s not the actual work. What we see is that usually when PMS get brought in, it’s because of this problem. It’s such a mess in the building, because there isn’t the clarity from the framing and shaping that there’s a whole bunch of herding of cats and chasing after people and micromanaging to see that things actually are going well right now. This is not a successful situation. The PM isn’t happy. They would like to be at least closer to strategy, and the build team isn’t happy, because if they need a babysitter, it doesn’t mean that things are going well, right?

So once we start to frame and shape better, what we usually see is that the team isn’t in this paper shredder universe. There aren’t a million unanswered questions all the time. The team has more clarity. So a technical lead can be making sure that things run well. It’s more of a building problem. Think of the foreman at the construction site, as opposed to project manager running around everywhere. And when this shift happens, the PM can move leftward, and the PM can start to focus more on the strategy side.

But this is where, again, we have this misconception where this PM thinks they should be involved in strategy, and a lot of CPOs who are hiring their first PM. So if you’re kind of start up into scale up, they have this expectation from product management books that I should be able to just kind of leave the PM alone with the team and empower them again. Empower without clarity, empower them to like, just decide what they’re going to do, and when you’re scaling, it’s understandable, because you say, I don’t have time to have my fingers in anything every more anymore, so I want to have individual squads making their own decisions and doing things. But there can be a lot of misunderstandings here, because there are trade offs that have to get made. There are decisions that aren’t easy to make that the PM isn’t going to be able to make on their own. So what we see a very kind of healthy division of responsibility looks more like this, which, I mean, should be probably obvious, but sometimes we just don’t reflect on these things, that the big picture strategy belongs at the exec level.

But what the PMs can do is a lot of very meaningful work on what is the problem? How do we better narrow it down? What does it really mean? What is the context? Where are people struggling? How would we know if we were solving it? We see PMs doing very well in this they need to scale up a little bit. They have to come closer to the business. They have to come closer to the customer domain. They have to get to know the demand better. But it’s actually the kind of strategic work that a lot of PMs are wishing they could do, and when it’s linked to the bigger strategy, but they’re not under the illusion that they set the bigger strategy. Then they have a lot of constraints around them where they can be very productive and they can contribute a lot. Here we have some really great, we can talk on the side about some very nice case studies of what it looks like when companies do this.

So the thing I want to point out, though, is that there does still need to be a connection between, for example, CPO and PM, or somehow between the Exec level and the PM level, because if we just give the PM some kind of a task, and it starts to get hard. It starts to get complicated. The PM rarely feels that they can say no to a chunk of that problem. It’s very, very difficult when you’re not, when you don’t have them. What do you call it? The authority, the backing from an executive level to say we can’t do everything we thought we could do, but we still are going to invest time in this piece of it, because it’s still worth it. That’s a difficult trade off to make.

An example of this, just a simple example. Worked with a team they were supposed to be changing the onboarding flow for a financial product, and there was a step in the onboarding that was just, it was asking for a million things, and they were seeing much too much drop off in the funnel at that point. What they understood was they could actually pipe in data from one of their bank partners so they wouldn’t have to ask those questions, and they would expect much higher conversion through the onboarding funnel. It was a no brainer. They could see that it was a good idea, and they tasked a team to go do it. But as soon as the team started to actually get real with it, and they peeled back the code and looked at how they could make this change, they understood that this onboarding step that they were going to pre fill had completely different data and different rules and different agreements depending on which bank the customer was integrated on.

So what seemed like one step in one flow was actually three totally different cases with different rules and different logic and different integrations. And the scope of the project was, I mean, it wasn’t just 3x, it was because of all the different interdependencies. All of a sudden it was a big project. If you were tasked with that and you’re at the PM level, all you can do is say, I guess we have to push harder, right? Because you were told to do it, you have a responsibility and sorry, it turns out it’s harder, so I guess we’re all going to do something that’s harder.

The thing that an Exec can do is say, I don’t like the look of that, I don’t like that this, I don’t like spending 18 weeks on this, because we have this, this and this other very important thing in mind that we need to be doing sooner, and we can’t push off all that other stuff. So from the Exec level, we can say, out of those three different integrations, are they all the same size? Are they all the same value to us? And what they in this case, discovered was that there was one integration segment that accounted for a good solid 40% of the traffic in this funnel that they wanted to improve, and if they could simply pipe in the data for this one branch of this 40% that it would still be a very big win, that if they could for that chunk of customers, if they could get more people through and significantly improve the conversion there, they could do that in three weeks. They could show it to the company. This is what we did in three weeks. And everyone would say, fantastic. Well done. Thank you very much, right?

So this ability to redefine the win, to make trade offs and what counts as a victory, is very hard for a PM to do, but with a little bit of interaction at key moments with Execs, that kind of trade off can happen.

---

---

Upcoming Event

BoS Europe 2026 🇬🇧

13–14 April • Cambridge, UK

First speakers announced.

Save Your Place