The Knowns and Unknowns of Building Products (featuring Jason Fried and Bob Moesta)

Hey, product people, it's Mike from Product Collective and we're going to try something new here. Just the other day, I was hanging out with a product leader in my hometown of Cleveland, Ohio, and I said, hey, have you ever gone through the hundreds of hours of video content that we have in the Product Collective archives? And he looked at me and he said, mike, no, I've never gone through it. I don't have the time to go through hundreds of hours. Are you crazy? And I thought about it and he's right. Nobody has time to go through hundreds of hours of videos. But we have all this amazing content. Content from keynote talks at our conferences, fireside chats that we do in our industry Interview, live video chat series, our podcast. So, so much. And I thought, you know what, I might be able to help with this. And so what we're going to do, we are going to go through the archive and we are going to zoom in on the content that really matters to you and not feature an entire keynote talk. Even that is a lot to sit through. Right. But we're going to find the best talks and zoom into the best golden nuggets of information from those talks. And we're going to break it down for you, starting with right now. Because what I've gone and done, I found a talk from industry, the product conference back in 2019. Early pioneer of jobs to be done. Bob Mesta sat down with Jason Fried, CEO of 37signals and Basecamp, right on the main stage, ad industry. And they talked about the way that Basecamp does work. It's pretty unique. It's a lot different than most product oriented companies. And there's two big takeaways that I think you're going to get from this. So I'm going to break it down after I play this clip. But what I want you to do is think about two things. I'm going to give you a little bit of a hint here. The big takeaways have to do with the way we break down our work and the way we measure our work. So let's go right to the clip and I'll break it down right after. Let's take a look. Like, most people plan like they know what to do, but most of the time they don't. And so can you talk a little bit about how you go about finding the.

Going from the unknown to the known? Yeah. This is something that I've seen a lot of teams struggle with. We struggled with it years ago as well, which is going into a project thinking, you know, everything that you need to do, and you line up a lot of work up front, and then you assign work to people. Right. This is backwards. And it doesn't work. It is a broken way to work. Yet it's probably the way most teams work. What you really want to do is you want to assign a project. You never want to assign tasks to people upfront. People have to discover the work itself as they go through the project.

What do you mean by discover?

So we'll have an idea. So we'll have an idea for a feature that we want to build over the next, let's say six weeks. And we'll do what we call shaping the work, which is kind of roughly explaining going through the idea and roughly getting to a point where we can explain the concept to a team. We'll eventually hand the project over to the team. A team's usually three people, and it's up to them to figure out how to execute that project. We all know up front that this is an idea, but an idea is not a finished. An idea is a malleable piece of clay. Like, I don't know what this is actually ultimately going to look like, but we have a general sense of the shape, kind of. Now you have to mold this thing. You have to. The team has to figure out how to turn this rough ball of clay into a final thing. And so that involves talking to each other and figuring out how they want to execute on the idea. And that involves them coming up with the actual work they need to do. They have to discover the work by thinking through how they're going to approach the problem. They're problem solvers. That's why we hired them. I don't hire people just to type code. You hire them to solve problems. And if you give them the work to do up front, by assigning them tasks up front, you're removing their mind from the process. Like, I want 54 minds, 55 minds. At our company, we 55 people. I don't want four minds and, you know, 50 some odd, like executors. That's not what we really want people to do. So people have to discover the work by getting into it. And the only way to discover it is to start somewhere. And you start with. We typically like to start with the unknowns first. We try to think of. When we map out a project, we use something called hill charts, which are something that are available in basecamp and only basecamp. We invented this thing, put them in there. We think that work is shaped like a hill, which means it Starts here, goes up, comes down and flattens out. It's not linear or this way, it's a hill. Because projects feel like a hill. There's a point of the project, the first half of the project, where it's full of unknowns. Like, I don't know what's going to work. We don't know what we're going to do yet. We need to get over the hill first. When we get to the top of the hill with a problem, we go, oh, now it's downhill from here. Like, now it's just about execution. But you've got to discover your way up the top of the hill. You've got to push things up the hill. And so we start with a series of unknowns and we get clarity on those unknowns until they become knowns. What we don't do is we don't say we're 25% done. That means nothing. Like, done with what? What 25%? The hard part, the easy part. 25% means nothing. 80% means nothing. These percentages don't mean anything because there's no context. If you're 90% done because you finished nine out of 10 tasks, that last task is the hardest thing. And the thing you don't know how to do, and you only have a week left to do it, you're fucked. Like, that's not gonna work. So you've got to figure out what's known and unknown and measure projects based on that. Not on completion, not undone and not done, but what's known and unknown. That's where you gain confidence. If you've got a bunch of stuff and you've got two weeks left and all of it's known and you can coast downhill, great. But if you're stuck at the top, or if you're not stuck at the top yet, you have two weeks to go and everything is unknown, or the big points remain unknown. You're in deep, deep.

Okay, that was only like four minutes long. But there's so much to take away from that. And really, there's two distinct themes again. It's the way we organize the work that we do and the way that we measure the work that we do in terms of how we organize the work that we do. What you heard from Jason is at 37 signals, they don't assign requirements. It's not like, you know, a developer is handed a list of requirements and they go off and build those features. Instead, what they do is they organize around a product team, essentially, that typically consists of, from what I understand, Two people, a designer and a developer. Guess what? Products people. A product manager is not a part of that mix. I think at 37signals, the designer plays the role of the product manager. So it's not like they hate product managers or. But. But at 37signals, you kind of have to play that dual role function. That designer is also acting as the pm, and those two, the designer and the developer, they're given a lot of leeway in terms of what they actually have to come up with. They talk about the general idea, the general concept of what they're trying to achieve with a particular feature or a product. But then it's up to that product team to develop what that means together to come up with what those features might look like and. And really run with it. And why do they do this? Well, according to Jason, any other way, you know, if they were to just assign requirements and developers go off and build those requirements, it limits creativity. What might happen is that the requirements that end up getting built aren't the right requirements. They're not what's best for that particular product. So they want that product team to actually have the leeway and the flexibility to come up with all that together. And I think it's pretty unique. It might be different than the way your company does work. It might ultimately be somewhat similar. Right? Like if you had a product manager in a function that. That was in a defined role. And yeah, they might be coming up with requirements, but. But you are collaborating with that team of designers and developers, and you are flexible, and it is an iterative process. Maybe it's similar. Maybe, you know, it seems like it's a lot different, but it's similar. I think it's a different mindset, though, compared to the way a lot of people might approach product. And I think it's one we should all think about. So I love that big takeaway from that video, that clip from that keynote fireside chat at Industry the Product conference. The other theme was the way that we measure our work. And this is definitely different. You know, oftentimes our leaders might ask us, okay, what, you know, what percent complete are we with this product? And we might give them a percentage. We might say, all right, here's the timeline. We started here. We're going to here. We're midway through. We're 50% through. But that doesn't really tell the whole story because the type of work that we do, there are knowns and there are unknowns. Right when we are scoping out an entire product that we're working on even an individual feature, there's some work that we know the amount of work it will take, we know the time it will take. That would be the knowns. But here's the thing we all know once we get into building something, there are things that pop up that we just didn't think about, that we just weren't planning for. And how could you ever measure something that is a complete unknown? So the way that 37 signals approaches this, and this is even baked into a feature within their product base camp is they like to think of it not as a linear path, the work that they're doing, but more like a hill. And as we're going up the hill, we're working through the unknowns, the type of work that we're doing, it will require a lot more of us. And we don't even know how much time it's probably going to require of us because it is a big unknown. It's something that we don't even know how to. How to define. At first we know that we're gonna need to do some things, but once we get into the work, there's going to be things that we just aren't so sure about. Those are the unknowns. And so what we want to do is get to the top of this hill and make it so that then we're going all downhill all through the knowns. Jason mentioned in the in the Fireside chat. Look, you could be 90% done with your work if you're talking about in a linear fashion, but what happens if it's the 90% of known work and it's the 10% that you're saying is left? That's the unknown work that might take you twice as long as the first 90%. So it's just a different way of thinking about the work that we do. Again, that is a feature built in Basecamp. But even if you're not using Basecamp, trying to think about your work as more of a hill chart kind of a thing instead of a line graph might be a better way to think about the type of work we have to do as product people. So again, there are takeaways about organizing the work that we do and about measuring the work that we do, all from this four minute video clip that took place at Industry the Product conference. And look, I hope this is helpful, breaking it down a little bit, if anything, just to get you thinking about things a little bit differently. What we're going to do here at Product Collective is we're going to find the best nuggets out there from other keynote talks, fireside chats, webinars, whatever it might be. And we're going to break these down for you again and again and again so that you could just focus on the stuff that will actually help you as a product person. So I hope this helps. I'll see you again soon.