Shipping work that matters

Not even a year later, but Shape Up is out there… So how is Shape Up shaping up, Ryan?

I’ve been pretty blown away by the results, actually. I keep hearing emails dripping in from folks, talking about “Hey, we just finished our third cycle” or “We just finished our fourth cycle…” These are six-week cycles, so it means they’ve done some reps; they’ve really learned some stuff. We’re seeing some amazing results.

I was on a phone call – I sat in on a conference call with a Fortune 50 company that adopted Shape Up on their digital teams recently, and the amount of… I don’t know what to call it - emotional energy, is very surprising. You know, you talk about something like product development, and it can be very functional… Like “Did we get the stuff done on time? Was the quality what it should be?” and stuff like that… But the amount of excitement that people have about like “We’re collaborating with our engineers in a way that we never were before.” Product and design and the development teams are working together, and they feel way more plugged in and included in the process, and the morale is up… Stuff like that has been really awesome to hear.

Have you had any teams give it a short and say “Yeah, it’s just not for us”?

I haven’t heard about it, if they have…

They probably wouldn’t tell you, right? [laughter]

It’s interesting, it does expose different weaknesses or sort of highlights the areas where people are struggling. So there’s been folks who’ve reached out and say “This has alerted us to quality problems that we didn’t know we had, in terms of performance of the programmers.” There’s other teams that have said “We sort of unlocked the potential of our programmers now, and everyone’s killing it in a way they weren’t before.”

[03:50] Other people - it starts to reveal issues on the leadership side, where it’s like “Oh, we tried Shape Up, but we were having a hard time getting everybody at the betting table to align with each other.” And then you also see the opposite, where people say like “Finally, we feel like we’re steering the company, instead of just asking for stuff and crossing our fingers and hoping it gets done eventually.” So in a way, it mirrors what’s working and what’s not working in the org structure.

Yeah. You get to see relationally who’s missing from the table, so to speak, even.

Yeah, and because shape up kind of integrates in so many ways - it integrates design and development inside the cycle, it integrates the leadership at the betting table, so that they’re actually paying attention to how we’re going to spend our time next… It creates all those opportunities for people to look around and say “Okay, how are we actually working together? Where are we on the same page and where are we not?”

Has it stayed pretty static in terms of the content, or have you gotten to evolve the idea a bit more because of it being out there, and it’s had some cycles itself?

There was one round of additions that I made that were fairly small, but you know, the same questions kept coming up. In the very first version, people kept writing and saying “Well, what about bugs? What about tiny little changes? How do you deal with that?” So I added a small section for that. The one thing that really keeps coming up is “How do you apply this on a new product, or a new company that’s building a new thing?” Because all of the concepts kind of get introduced in the context of “We’ve got a product, we’ve got customers, and now we’re making calls about what to do next. We wanna continually ship improvements on time to that product.”

Yeah.

Right.

And then the question comes up – you know, HEY is about to come out, the new email app that we’ve been working on here at Basecamp… And people have been saying, “Did you use Shape Up for HEY?” and the answer is “Absolutely.” But the thing is that there’s some stages of work in a new product where the straight up Shape Up method doesn’t apply, actually… And I wrote a small appendix on this, but actually I’ve found that I need to expand on it when I talk to people. People need more detail on that. So we’re actually working on a print version now, and I think we’re very likely to have a new section in there, that really spells this out. Because I’ve talked through it enough now that I understand it, and I wanna be able to spell that out a little bit better for the next version that comes out.

Is what you brought in - I’m speculating here - is it kind of tying in Shape Up into, say, customer development and revenue growth? Or what is it missing in terms of like a new product, and what are the facets there that are different from an existing team? You kind of know your revenue stream, or your product actually makes money, or it has fit, and where are you–

That’s a good question.

…what facets are different with the new product?

Yeah. Shape Up is all about – when we already have a strategic idea of what we think we wanna do, how do we turn that into a project that people can actually execute on, where everybody’s clear on what we’re gonna do next, and the team is gonna be successful building it, and the team is gonna make more decisions about the details, and they’re gonna have those guard rails, and they’re gonna be successful getting the thing done on time. So shaping is really about “We know what we wanna do”, but we can’t just go tell a team “Hey, go figure it out.” We need to work out the outlines and the guard rails of what this thing is and what it isn’t in order to give it to a team, and kind of make that hand-off really successful.

So already even just kind of in the traditional doing shaping for a product that is already up and running, we aren’t really addressing those more open strategy questions about what to shape. That’s something that the book deliberately doesn’t get into, because that’s a whole other book… And it’s a fascinating subject, and it’s something I’ve been really thinking a lot about and working a lot with lately, because I’m working on a lot of new projects for BC4 right now; a very, very early version of the next version of Basecamp. So that’s been at the top of my mind.

[08:20] What’s different about working on a new product versus an existing product is that even if you take the strategy piece out of it, and you take all the questions about revenue, and business model, and the stuff that you raised - even if you take all of that out of it, until you have something that’s standing, where the key pieces of functionality are built and they’re running in code, and that architecture is there… Before you have that, it’s just way too open-ended. The first commits to a totally new piece of software - you know how you just end up throwing all that stuff away. You totally change the schema, you significantly change certain model relationships, even stupid stuff – stuff that you think is a one-to-one becomes a one-to-many… There’s fundamental things in the architecture that you have to figure out.

And what happens is when you’re doing a completely new product, there’s just so much scrap that if you try and delegate it away to a team, you’re going to find out in week one, like “Oh, wait a minute. That’s not the right way. That’s not what we want.” So there’s this phase that we call the R&D phase, that comes before the production phase. The production phase is where I’ve got the architecture there, the main pieces of how this thing hangs together in terms of the schema, the model, the key functions - those things are all there. It’s like the pillars are there, and now it’s more about “How do we fill in all the details and all the extra functionality that we want?” But those load-bearing pillars - they have to be there before you can delegate projects to other people… Or even to yourself if you’re a really small team, to make that promise to yourself of like “I’m gonna build this feature next, and I’m sure that I’m gonna be able to get to the end of it and it’s gonna be done the way that I think it’s gonna be from the beginning.” You can’t just do that if it’s totally open-ended.

So in the R&D phase, the first phase of a new product, we actually have to mix shaping and building together into a blurry mix. So we’re not gonna say upfront “This is what we’re gonna do”, and then give it to somebody else and they go do it, because we don’t know how it’s gonna pan out yet; it’s just too early. So what we usually do is we’ll have the more senior people – David will be hands-on. David is our co-founder and CTO - he’s gonna have his hands in the actual code for the first couple features, because those tent-pole things are gonna define the architecture for the whole product, where everything else is gonna fill in… And he’s gonna be doing – I think also this goes back to Pragmatic Programmers, the notion of a tracer bullet. It’s like, I’m firing to learn. I’m gonna fire and then aim, and then fire and then aim. It’s not just like aim and then fire.

So he’ll be really involved, and then Jason - or in the case of HEY we had another designer Jonas, who’s one of our more senior designers, who is working basically in tandem with Jason and David… And the three of them were building a little bit, and then throwing it out, and then building a little bit and then throwing it out, and trying this and trying that… And they did that for a few cycles. So there wasn’t any clear shaping other than “This is what we think we wanna pursue.” There was an appetite, in the sense of like “We’re gonna spend six weeks exploring this area, but we don’t really know what’s gonna come out of it.” And that’s very different than straight Shape Up.

[12:08] Well, especially R&D - it’s like, you’re almost exploring anyways with R&D. You’re kind of expecting to throw things away. You’re not expecting to have rigidity in your process; you’re expecting free-flow… You kind of want no boundaries, in a way…

Exactly.

Because that’s what enables the creativity.

But what happens is a lot of times people aren’t really conscious and deliberate about the fact that like “Wait a minute, I’m in a different mode here. I’m in an exploratory mode, so I have to use a different process, and I have to set different expectations”, and we actually have to work differently together to get through this phase… So that R&D mode, the design and the programming are happening together, intensely collaborative, and we’re not doing this upfront design where like “This is what it’s gonna be” and then delegating it out, because we just can’t see far enough. We just can’t see it yet.

But then what happens is after – I don’t know, maybe sometimes two, sometimes three cycles of that, the core pieces are gonna get figured out, and the couple tent-pole features and architectural decisions are gonna get laid down… And David likes to say “pouring concrete.” You know, there’s that part of the app that it’s like “We’re never gonna change this. This is the concrete. We’re not gonna bust this up and refactor this or change this, because this is the stuff that makes everything else hang together.” Once that stuff is figured out, now you’ve got the borders and the walls and the boundaries to fill in a million other features, because you know what they plug into. And that’s where you can flip into straight up Shape Up…

Straight up Shape Up…

Straight up Shape Up… [laughter] We’re gonna define upfront what this is gonna be, we’re gonna define it at the right level of abstraction; not too much detail, but also not too fuzzy… And then we’re gonna give this to a team, they’re gonna completely take responsibility for it, and they’re gonna figure out how to execute it within the boundaries of what we defined. You can get into that loop then, which is sort of the main subject of the book, after you have that basic architecture in place.

Yeah. I like the metaphors in there… Pouring concrete - that’s foundation, right? You’ve got some rebar in there, you’ve got the foundation… You don’t put a house on just gravel and sand, you put it on a foundation that’s locked, it’s spec-ed to the room sizes… If the foundation isn’t there, you’re not putting beams on it to start building a house. That’s what the product is, the house.

And think about remodeling. If you’re gonna remodel a house, you’re not just gonna move any wall, you know what I mean? There’s certain things about that house that are not gonna change.

Right. Load-bearing.

Exactly. And then there’s areas where you – and there’s a difference between adding an extension or moving a wall to create a different space, versus moving furniture around, versus painting. There’s all these different levels of change that can happen, but you’ve gotta be really deliberate and conscious of what are the load-bearing parts of the app that aren’t going to change, because you end up making a lot of trade-offs around those when it comes to even how you build different features in the future… Because it’s like “Look, we could do that if we wanted to bust the concrete, but we’re not gonna bust the concrete, so what are our other options?”

A related anecdote… So my brother and sister are building a house right now, and the – not the builder, but… What’s the name of the person that comes beforehand and lays it all out? There’s a company, like survey. I think it’s a survey company…

Oh yeah, yeah.

Anyways, whoever flags the actual location for the house, flagged it off by like 15 feet. And then the builder came and dug a hole, and then they poured the foundation, and then they realized. “We’ve put it in the wrong place.”

[16:02] Oh, man…

And at that point, it’s very expensive to fix that problem. So you’ve gotta get your foundation right. And side note - they came to my brother and sister and said “Hey, can we just give you a discount and leave the house there?” And they said “Nope. That’s not where the house was scoped to go, so you’re gonna need to tear out all the concrete, dig a new hole, and put the foundation in where it’s supposed to go.”

Which is painful.

So painful. And I think it was painful for the survey company, who has general liability for situations like these, but probably very painful for the fella or woman who did that, who may have lost their job… Huge cost. Anyways. I’ve been thinking about that as you described this, because you’ve gotta get your foundation right. But when you build a house or you build a building, you can see the concrete there, you can see the framework, you can see all that, and you can say “Okay, the foundation is poured. We have a cornerstone, it’s not in the wrong place, it’s looking good… Let’s build the rest of the house.” With software it’s not so obvious. Is there just like an intuition when – you know, does the CTO come and say “Okay, we’re done pouring concrete”? How do you know when it’s time to switch off from R&D/laying foundation to straight up Shape Up? Is it just intuition, or are there obvious moments when you can say “Yup, it’s time to go to the normal way”?

Oh, man. That’s a great question. As far as I can see, it’s a mix. There is art to it, but there is science to it as well, because at the end of the day it’s a question of interdependencies. If you look at the house story, it’s a question of dependencies. You have a point where all the dependencies point down to the same root, which is like “Where is that concrete foundation?”

“We all need this one thing.”

Yeah, everything else needs that thing. So if you think of it in terms of a dependency graph, you can see that structure.

That’s true.

And when we look at software - of course, if you look at it from far away, it’s just a hairball of dependencies all over the place…

Right.

But if you look at the software in terms of what does it do for users, and what does it do for customers? You can segment in terms of primary functions and secondary functions. For example, Basecamp has a feature to tweak whether or not you get your notifications via email or you just get them in-app. It’s not a primary feature of Basecamp. People don’t buy Basecamp because they’re gonna go change a notification setting, right? The primary features of Basecamp have to do with enabling people to know the same information that used to be scattered in different places. For example, the way that a group of people can all access the same to-do list and see the same thing is a primary function of Basecamp. Or the fact that you can post a message and a predefined group of people is all gonna get notified of that message, and that message is gonna be accessible within this sort of accessibility sphere that these people are all part of - that’s super-fundamental. And any feature we add to (let’s say) a Basecamp project is gonna depend on that mechanism of who can see what in a project, and what is a project, as a collection of data with access rules around it. That’s really the core.

[19:54] So David designed a model that’s part of Basecamp 3, which is what we call bucket access. Bucket is the abstraction of a project, and access is the way that we relate users to buckets. And there’s some serious concrete there, because we’ve made certain trade-offs early on in the design that simplify the design for the use cases we cared about, that as a consequence cut off all kinds of other options. For example, access in Basecamp is all based on the assumption that everybody sees the same thing. And anytime you want to make a custom rule that “This person on this project can see this, but this person can’t”, you completely run your face up against the – it’s like, you’re grinding your nose against the grain of the concrete. It does not want you to do that. [laughter]

That’s the kind of thing where if we wanted to have finer-grained permissions of who can see what within a project, we would have to significantly rethink that… And it’s not – it goes back to just the dependency analysis of if you look at the graph of what depends on what, what is a project and what is access, and how do we define that in terms of the model and the code, that’s really low in the system.

That’s a great way of looking at it.

And I don’t wanna put my face to the foundation either. That’s painful. Let’s not do that. [laughter]

That’s really gonna hurt.

But do you know that feeling?

Yeah, yeah.

It’s that feeling like – sometimes when you’re adding new functionality or doing a refactoring or changing the way something works, you’re just kind of like flying along, and everything is kind of coming for free, because you’re leveraging all those dependencies that are underneath you… And then all of a sudden you wanna change something and it’s like “Smack!” You just hit the wall, and you’re like “Oh, man… I would have to tear up so much stuff if I wanna change this.”

Let me throw something else at you then, if it’s a different angle… Maybe it’s not as painful as it should be. Maybe it’s a velvet rope. Did you ever hear this concept where you know the kind of customer you want, so this foundation is like “If you wanna use Basecamp, you have these kind of desires from the software you’re trying to use, for the purpose of Basecamp”? So rather than it being a painful thing – sure, you hit your face against the ground, trying to do things the app shouldn’t do, but maybe it’s a velvet rope in the fact that it defines your customers base.

Yeah, so these are very different types of risks, and I would frame this in terms of risk. So the thing is somebody comes up with an idea, and somebody wants to dedicate time and people to working on something, and “How is this gonna blow up on us?” The whole thing about the concrete is that if we send somebody down a road where the only way that they’re gonna succeed is if they have to rip up concrete, the scope is gonna blow up exponentially on them, just in terms of work…

Yeah.

Because if you pull on that string, you’re gonna pull the whole rest of the app with you, because of the dependency tree. So that’s the kind of risk of like “We want to do it, but if we try and pursue it, it’s gonna blow up in our faces because of the technical reasons.”

I think the velvet rope case that you’re pointing out is really important too, but it’s a very different type of risk. It’s not a risk that the team is going to run into a scope explosion. The risk is that they’re gonna successfully ship it, and then we’re gonna end up in a market position that we didn’t wanna be in, serving people that we didn’t intend to serve, or getting feedback that doesn’t relate to the core of how we make money, or that kind of a thing.

[23:53] Right. That foundation is the DNA of Basecamp, right?

Yeah.

If you go against that, you’re faced against the ground as a developer trying to change things. But as a product, it’s your velvet rope; it defines who you wanna let in, essentially… Because if you can’t agree that everybody should see the same thing, then you don’t use Basecamp.

Yeah. I would locate those kind of in different parts of the company then.

Yeah, marketing versus development.

The boundary of what you can and cannot change in terms of the code - that’s something that’s understood among the technical team. And the boundary of what we should and should not change on the – you know, we can talk about supply side and demand side; the thing about what code not to change is the supply side boundary of “Don’t touch that, and take that as a constraint on any projects you come up with.” And the thing about what projects to pursue, the velvet rope thing - that’s more of a demand-side thing that’s coming more from the design side, and it’s coming more from the shaping side of things. So I’m not a programmer, I’m working on what may become BC4 right now, and a lot of that is – I’m totally in velvet rope land right now… There’s things that we could do, that we might wanna do, and I always have to think about “Are those the right things for our customers, and are they relevant for customers?” and that kind of a thing… And do they keep us – are we gonna continue to serve the people that we wanna serve by doing this?

But then, if I pass the velvet rope check, I still have to do the concrete test afterward, because it might be something that’s totally kosher as far as the market position, but it may not be a feasible change in terms of the way that the code is structured, you know what I mean? So I’ve got that sort of second layer then of, okay, I’ve gotta do some due diligence and talk to David or talk to Jeff and say “Here’s this thing that I think we should do. Is this consistent with the architecture we have or not?” and “Can we do a little spike?”

There was a feature I came up with which was a pretty substantial, kind of new, weird thing that we’ve never done before… And I came to a point where I felt really confident from the demand side, but from the supply side I had just no idea if it was feasible or not. And I didn’t wanna take this thing all the way to the betting table, and then have this sort of rushed 11th hour conversation before a cycle starts and be like “Meh…” There’s too many unknowns in terms of building that, so it just sort of gets kicked off the table. I wanted to sort of play more defense than that, so I reached out to Jeff, who’s one of our most senior programmers here, and said “Hey man, this is what I’m thinking about. These are my assumptions about how the existing system works. Do you think this is consistent and conformable to the existing system?” And he said “I think it looks reasonable. Let me take a swing at it.” And he did a three-hour spike, just taking the existing model objects that we had and seeing if they would sort of twist and bend to do this thing… And he came out of it with a little bit of code and some little – what are they called, those things in Git that don’t belong to anything; they kind of just hang on their own… I don’t remember what they’re called, but they’re these little throw-away pieces of code that you can just…

A branch?

No, it’s not a branch; it’s not part of the Basecamp repo, it’s just kind of like… God, what are those things called? It’s like a free-floating piece of code that you can embed somewhere. Anyway…

A module.

No, it’s like a – oh, whatever… [laughter]

We’ll just keep guessing.

It’s not part of a software project, it’s not part of a repo, it’s like this stashy kind of a thing. Anyway, it doesn’t matter. It’s gonna drive me crazy; I’m gonna end up looking up, like ’What is this thing called?”

[28:07] We’ll put it in the show notes. You’ll figure it out.

[laughs] Anyway.

[unintelligible 00:28:09.24]

It’s like a little throw-away scrap of a thing that you can make in GitHub. Anyway, there’s just this little –

A gist?

A gist, that’s it.

There you go. Good job, Jerod.

Yesss!

We have a winner.

It’s like pin the tail on the donkey, just keep guessing jargon until I get one.

[laughs] Anyway, I’m sure we used your listeners’ time very well in the last ten minutes…

Yeah, thanks for hanging with us.

Anyway. Then he can just throw a little bit of code back together and say “Hey look, here’s a proof of concept. Yes, this is viable. We’ll use the bucket model like this, and actually we already delegate this over here, and it cracks like it should, so it’s gonna work.” Then I put that back into my pitch, and now I’ve passed the velvet rope test and I’ve passed the concrete test, and…

I like this velvet rope test being in there. Is it a real thing, or did we just make this up on the fly?

That’s how these things happen, man.

I love it.

Everything comes out of conversation.

That’s right.

The only reason actually that we even got to the word “shaping” was because I was giving a talk somewhere and I was with my friend and mentor Bob Mesta, and we were trying to talk about Hill Charts, and the group was just staring at us like we were just speaking Greek or something… And what we realized was that we couldn’t talk about Hill Charts because there was this other thing that they weren’t doing, which was they weren’t what we now call shaping… And we were struggling to reach for the word, standing in front of this group of 150 people in a room, and then Bob all of a sudden is like “No, but you have to shape the work first; you have to have a sense of what is this piece of work that I’m trying to do?” and that’s where we get language from… it’s from being in the moment, where we need it.

Yeah. So one last question here on this front - you talk about BC4, these major versions of Basecamp… In a technical sense, are these major versions an opportunity to add another wing to the mansion, pour some new concrete, or are they mostly remodels of the codebase? Are you pouring new things, are you remodeling, had to fit inside the current architecture?

So that’s case by case. So far, when we went from BC1 to BC2 and to BC3, every one of those involved new concrete, and we actually built those as completely new projects from scratch, and then ran them and sold them in parallel to the old version. So BC1 and BC2 right now are separate codebases, running on separate servers, with separate customers. That allowed us to make drastic changes to the underlying architecture, without disrupting anybody. But the only reason that we did that was because we had ideas that weren’t accessible in the space provided by the existing architecture. So if we could have just ran on the old architecture, we would have, for sure. But there were things that we wanted to do that we just couldn’t get there from here. I think at the time we were calling it the chassis, like “We need a different chassis for this”, kind of borrowing from the automobile industry on that one.

Yeah.

So that’s a huge part of it - what are we trying to do, and does the thing that we’re trying to do actually require a new chassis or not? And how valuable is it? Is it so valuable that we’re willing to do this crazy thing of pouring new concrete and building a new chassis? That was true for 2 and 3.

[31:57] Actually, we don’t believe that’s true for 4, as of where we are right now. David recently shared this new pattern called delagatable type, and it’s at the core of BC3. I mentioned that we’ve got this thing called a bucket, which is an abstraction of a thing that people have access to… And a bucket is a team, it’s a project, it’s the HQ, it’s a circle of people who are all on the same ping, which is like a direct message.

There’s a bunch of different things that are buckets because they have access, but the way that’s implemented is that you have a bucket, which actually is just basically an ID and a way to relate the users to this thing. It’s just kind of a nexus of relationships, but it has no content. And the actual content - the name of the project, and the description of the project, and stuff like that is actually on what’s called a bucketable. So a bucket has a bucketable. And the bucketable is actually an immutable thing that is kind of the value of the bucket.

Right, the object referenced.

And we use the same pattern for every piece of data that lives inside of a project. Everything, from a common, to a to-do - everything is what’s called a recording. And a recording is the association between a piece of data and a bucket. And the recording has a recordable, which is an immutable throw-away thing, which also by the way gives us stuff like versioning for free. Because if you make a new version of let’s say a document, the document is a recording, in the sense of it sits on a tree somewhere… But the document as a blob of stuff or of value – I mean, not a blob in the sense of a binary, but…

Right.

…that content to that event document is actually a recordable, not a recording. And if you make a new version of a document, we actually push down that old recordable and stick a new recordable in as the value of that thing… And it’s got all kinds of awesome properties. Anyway, this is the kind of stuff that David figured out for BC3, and the architecture has just been awesome. This has never happened before in our – what is it now, 17 years history…? Since we started working on Basecamp classic, the first one. There’s never been a time where we were like a few years into the future from a product, and looked back at the code and thought “This code is awesome. We love this.” [laughter] And that’s where we’re at.

We look at the code for BC3 and we’re like “This is awesome. We love this. This continues to work, and it’s beautiful, and it’s enabling, and it’s spacious”, and the right load-bearing structures are in the right points, and we still feel like we have all the degrees of freedom that we want… Which is just an awesome place to be.

And then we look at the things we wanna do, that seem hard or maybe divergent in BC4, and none of them are running in conflict with this architecture. So we’re heading down a path right now for BC4 where actually we think it’s gonna be the first major new version we’ve ever done, that completely stays on the same platform, and the existing customers will actually get all the changes.

I came across this word on your Twitter recently, “longitudinally”. You said good design requires thinking longitudinally. Now, it’s a hard word to even say it, let alone grok what it means, so where’s your headspace with this?

So this is something that I’m just starting to learn how to talk about. I mentioned when the mics were off earlier that a lot of the stuff that I’ve worked on has been something that I start thinking about and then ten years later I understand it, or five years later it finally clicks… And I’m in a phase kind of like that right now. There’s a huge difference between looking at a slice of data as a snapshot, as a space-like snapshot. I’m just saying “Look, we surveyed customers, and 20% say this and 30% say that” or something like that. And taking the N of 1, looking at one individual case, but playing it out through time and saying like “If I wanna understand what to design, I need tu understand actually cause and effect. What happened, and then why did something else need to happen, and then how do I cause that to happen by putting a mechanism in place?” The whole business of design and engineering is following one thread through time, for one person, and making that thing do what it’s supposed to do, functionally.

Is that where personas come from? Is that what you mean by one person, like persona?

Personas are a good example of a bad thing. I mean, they’re a bad–

A bad example of a good thing…

No, they’re bad and they’re bad. [laughter] You’re blurring together a whole bunch of – and like I said, I’m just learning how to talk about this, but it comes back to space versus time. A persona is space-like. It’s saying “These attributes are all sitting together in a clump.” You know, 30 years old professional. Likes to eat sushi. Or whatever. You know what I mean?

Long walks on the beach.

[39:38] It’s a snapshot, and it’s just a clump of attributes. There’s no time in there. There’s no dynamics in there. There’s no movement in there. So rather than knowing that 30% of customers like to eat pizza, what I wanna know is when one person is in the situation that I’m designing for, what needs to happen next? You feel that rotation in your mind, it’s like a 90-degrees turn from looking at a whole bunch of attributes that are frozen, to following a path forward down a vector. And that’s a huge shift. So when we talk about longitudinal, we talk about following individuals over time, and it’s a big mindset thing.

Now, of course, there is a place for saying “30% is like this, and 20% is like that”, but it’s not the place that tells you how to make the right thing and how to make it work. So if I identify that there’s a specific person that I can be when I’m designing, and say “When I’m in that situation, it’s not about their age or their preferences, it’s about when –” I always go back to the Snickers story; it’s the perfect example. When I miss a meal and my energy is getting low and I have to keep going, what’s a way that I can quickly replenish my energy? I grab a Snickers, I eat it, and I’m done, and I’m back to what I’m doing.

Yeah. Joe Pesci.

That is a thread through time to understand that. And if you take that thread through time, you get all kinds of design requirements out of that, of what should the melting point of the chocolate be. If you’re making something that you’re gonna sit back and enjoy as like an emotional recovery, that is more like an ice cream, then this thing can melt in your mouth and you can swirl it around with your tongue and it can take ten minutes to be finished. But that can’t happen if you’re supposed to just bite it and swallow it and move on. So there’s design requirements that affect the composition of the ingredients, and everything, from looking at it that way.

Or you’re in a situation where you’re with a buddy who also has the same issue and you just share one. That’s why they have the Snickers two-pack.

Totally. Yeah.

The design requirement was “This person has this situation in time, with other people sometimes. That person’s gotta share.”

That reminds me of a great Mitch Hedberg joke, which is “I like Twix, unless I’m with four or more people.” [laughter] Because who wants to share? Come on.

That’s right.

Yeah, yeah. It’s like, a friend of mine offered me a frozen banana, and I said no. But then I thought, I might like a regular banana later, so… Yeah.

Exactly, “So I said yes.” [laughter] We’ll just do Mitch Hedberg all day.

But anyway. But then the thing is that–

Well, I like the idea of time though affecting this, because that does… It’s situational. It’s not my age, my gender, my attributes…

You can use the attributes then to scale the situational thing that you’re designing for. So you can say “How often does that situation come up?” And it may be that there are some demographics that bound the scale of that. If it’s too specific of a situation and it’s only gonna happen to a certain number of people, then of course that’s relevant to know. So there is a place for that space-like snapshot of attributes… But the thing is that what we could call the ensemble view, or that averaging out view, just blurring everything together into 20% this and 30% that - that doesn’t help you make design decisions, and it doesn’t help you make engineering decisions, but it’s kind of the default place that our brains go too often. It’s like “How do I answer a question?” Well, what’s the majority?

It’s about making this mental flip of N of 1, and then following that functionality through time, and thinking of it more in terms of individual threads of cause and effect. That’s the kind of headspace that we need to be in to make a design decision.

[43:51] It seems like a design decision needs to be – I mean, you need to have a vision, and a vision that is an N of 1 is de facto short-sighted. There’s a myopic single point in time that you’re designing for, and it’s difficult to then take that perspective and design something that has historic implications, or long-lasting implications. I may be thinking about it slightly different than you are, because it seems like you’re talking about longitudinal in the small.

Yeah, longitudinal is necessarily in the small, because I can’t understand – I can’t blur ten people together and then understand anything in terms of cause and effect.

Right, but this is the same person over ten weeks.

There’s a really great piece of work by this fellow Ole Peters. He’s a friend of mine, and I started following his work… He’s kind of redoing economics on a new foundation, and he’s using a concept called ergodicity from physics. He actually wrote a paper on it, but it first got it kicked off with Murray Gell-Mann. This is the guy who discovered the quark, so he’s in good company…

Wow… Yeah.

And the whole notion is if you take a whole bunch of gamblers at a casino and you average out their winnings, a few huge winners are going to throw the average, and you’re going to get the mistaken impression that gambling has a certain – you’re gonna value the risk at a certain level, based on looking at that average. But if you follow an individual gambler, what you’ll see is that they keep going bust…

Destruction, mostly. Yes.

…over and over again. So the story of what you see when you average over a bunch of people is very different than the story that happens when you follow people one by one through time. So that’s when we talk about N of 1, and we say longitudinally - it means we pull apart every thread, every person we pull apart as an individual, and we follow them one by one through time, to see what happens through time for that one person. And that’s where the insight comes from.

I was scratching my head a few weeks ago, working on this new concept I have for how to do access in BC4, how to assign what role somebody is playing in terms of their responsibility on a project… Like, are they the person who’s supposed to be doing the project, or did they just have access to see it? …this kind of a thing. And I was kind of spinning my head, trying to think through all these different cases, and I looked at some data about what percentage of projects have what percentage of people from the company on them, and what percentage of those people are active on the project etc. I’m looking at all of that stuff and none of it is giving me any insight at all.

I’m looking at like 50,000 customers, overlaid onto some cool graph, that looks very impressive, and I’m learning nothing. And then I think to myself, okay, how do I look at this through time? And I pull up a single project from our account, and I just followed the history of events; because we drop events every time anything happens. And I looked at who created the project, when they first invited two other people, what they posted, when they invited a few other people, and then when they invited the whole rest of the company… And by looking at one project, created by one person, all of my questions went away and I had a whole design concept… Because I could see the cause and effect of like “Oh, you don’t invite everybody on the first day, because you don’t have anything that’s ready for everybody else to see.” First, you just invite the person that you’re collaborating with, but then there’s kind of a cover-your-ass factor, and you invite a superior who you want them to know that you’re doing this thing, but you’re not actually working with them…

[48:00] Yeah.

And then you reach a point where you get a few tasks done, you get a few other things done, and now you have something to announce. And now it’s like “Okay, I’ve gotta bring everybody else in, so they can see this thing that’s done, that’s ready for them to comment on.” So I’ve got all of these dynamics of how projects evolve, and who you invite, and why, and when, all from just looking at a single thread and a single project. So that maybe gives you a little bit of the intuition behind this way of thinking.

Could you then do multi-threaded like that, where you look at several threads in that way, and come up with a larger-scale – kind of go back to the whole percentage, to some degree?

Exactly?

So it’s a wiser, larger number.

Exactly. That’s what we do when we do “jobs to be done” research. We interview ten people, and each interview is like a 4K movie. It’s like gigs and gigs of data, one interview, because it’s the full story of what they were doing before, what started to go wrong, what made them think that maybe they should do something differently, how they ended up finding Basecamp, what they did to try it… That whole thread is a very detailed thing, but it’s an N of 1. And then we do that thread ten times. Then what we do is after we’ve done the individual threads longitudinally, now we can cluster to get to an aggregate.

But the thing is that we started longitudinally, we started with time, and then we aggregate into space. So we can say “Three out of these ten were all coming at it because of this reason, versus these other three were all coming because of this reason. So these three were all new managers, who were trying to lead their teams well, and they needed to know what was assigned to who, and whether they were following up on it in order to fulfill their new management responsibilities.”

Versus this other group of people felt like the wheels were kind of coming off, and they were starting to lose control, because they kind of didn’t know what new information was coming in from customers, or what requests were coming, or what needed to happen next… So it’s very different, to say “I know it needs to happen, but I need to lead these people well, so that they follow through” versus “I don’t even know what’s going on, and I need to put everybody in one place, so nothing gets slipped, and we all have the same information.”

So this is the kind of thing that these higher-level clusters come out… But the way that you go about this data collection and clustering process is very different if you start trying to collect static data as percentages of an ensemble, versus if you follow the time path and then cluster on what happens through time. Starting with the causality is very different, because your ground truth is all dynamics, instead of statics. So it’s a very different world.

That’s fascinating, and I love that example of you trying to decide… So in that case, when you went and looked at the single project, and how it grew from one person, inviting, inviting, inviting, what design shook out of that? If you can describe it in words, what was the insight that that information gave you, and why did it help you produce what you ended up producing? Do you remember?

Yeah, it gave me a few things… And this is still work in progress, so it’s a little bit muddy, but it gave me a few things.

Sure.

One thing it gave me was I had an assumption going in that I thought that this was about people who are directly doing the work hands-on, and people who are kind of neutral, who are sort of just given access for a purpose of inclusion and transparency.

Like, “I’m gonna give everybody else in the company–” Because we have this habit at Basecamp that we invite everybody in the company to all the projects… And the whole notion - it’s about inclusion; we want everyone to be able to know what’s going on. But the thing is when I looked at the actual thread, I saw a contradiction immediately, which was that the creator of the project - she invited someone who was working hands-on with her, and she invited two people who weren’t at all working hands-on, but who were impacted by it.

[52:25] So all of a sudden I had this real data point in my face of like oh, there’s a difference between including somebody because you want them to feel included, which is a kind of social thing, versus including somebody because they need to know, because this impacts a project that they’re doing; or you need to get cover from them because they’re superior to you, and they need to know that you want them to know that you’re working on the right thing… You know what I mean? There’s a huge difference there, and that difference is gonna manifest in – so let’s say I knew that one person is given access for purpose of inclusion, and another person was given access because they should actually know what’s going on here, right?

Right.

Both of those people should not get notified every time there’s a new line in the chat. Those people should not get notified every time there’s a new comment by default, but the person who’s impacted should maybe get a daily notice that’s like “Hey, here’s stuff that happened on projects that you’re not directly involved in, but impact you.” Super-valuable.

Is that like a role thing? You said it’s access; is it more of like a role? The role they play is different than just any other role. They need sort of a “Don’t bother me, but keep me informed” role.

Yeah, “Don’t bother me, but keep me informed.” Exactly. You see that as very different than “Allow me in if I’m ever curious, so that I don’t feel excluded.” Very different.

Absolutely, yeah.

Totally different dynamics, right? So already, that’s a first thing that popped out to me; it was like “Whoa… Okay, that’s a meaningful difference.” And then the other thing that popped out at me was every project that has 50 people on it, because the whole company is invited, didn’t have 50 people on it for its whole lifetime. So if we were to try and do some sort of analysis that says “What’s the number of people per project?” and then do a histogram, like “What percentage of accounts had this percentage of projects, with this percentage of people?” that’s a snapshot, and that doesn’t tell me about the fact that all those projects had a different number of people because they had a different stage in their unfolding. That’s huge. That’s huge, you know?

Right.

So that just threw a whole bunch of data out the window that we might have queried and interpreted in a certain way, just by looking at that one longitudinal N of 1.

So how do you take that kind of thing, that kind of learning, and apply it on all your problems? [laughter] If it’s that revealing, how can you do that at scale?

They’re still figuring it out.

That is how we solve problems. The reality is like – this is the thing, is it’s actually just how it works. If you wanna build anything, you have to boil it down to being one person, in one situation, and I say to myself “What needs to happen next?” Anytime you’ve ever designed a system, you always end up thinking about “What needs to happen next? What does this function have to return? What’s the consumer of this function? What arguments do I have to provide?” All of that is actually happening through a sequence of time, in order to get to the end of a chain, where some outcome happens. So it’s actually the normal way of thinking, it’s just that when we go into a kind of research mode, we somehow forget that and throw that out, and we start looking at like “20% of the people said this”, but that doesn’t help us.

I don’t know about that. I think you wanna get to your answers faster. I think you look at big data like that because you’re like “How can I TL;DR this data to get my a-ha moment, so I can design better?”

And it doesn’t work. It’s not the way.

It doesn’t. You don’t have enough information…

[56:08] No shortcuts.

So this is the highly-detailed path.

And you can cluster vast amounts of data this way, but no tooling is built to do it this way. None of the tooling is built around this, so it’s fascinating. For example, we did a “jobs to be done” interview once where we talked to ten customers - literally, only ten - and we got this massive amount of insight about what people were trying to get out of Basecamp, and why they were going to it, and what it should do for them, and what it doesn’t need to do, and all that.

Can you back up and tell us what this “jobs to be done” is, and then go back into that? Because I don’t understand that. What is that?

Yeah, so there’s a body of work that I learned from my mentor, Bob Mesta; he’s one of the top, main practitioners of this… And he worked on it in collaboration also with Clayton Christensen, who’s a well-known late business professor from Harvard that coined the term “disruption”, and stuff like that. And the “jobs to be done” - the whole notion of it is that people are buying things and using things because they have a job that they’re trying to accomplish. It’s like, I’m reaching for the hammer because I’m trying to drive the nail. And the thing is that if we understand what people are trying to do, and the context that they’re in, and the outcome that they seek, then we get this kind of time vector of “They’re trying to get from here to there, and these are the bumps along the way. This is where they’re struggling, and these are the things that are blocking them”, and then those become our design requirements.

So you’re giving them tools to solve their problems, essentially…

Yeah – I mean us, especially in the developer world, we’re toolmakers, so you can really think of every product and every service as a tool to accomplish something. It’s like giving people a method to get through something that they couldn’t do. And it’s true for everything. It’s true for moving to a different house, or buying a car… You don’t buy the car because it’s red, you don’t buy the car because it has all-wheel drive; you buy the car because something happened in your life and you needed to make a certain kind of progress. And then what happened and where you’re trying to get to is going to define all those requirements for you. And those requirements don’t come because you’re 60 years old or you’re 20 years old. There’s gonna be some correlation there because of the circumstances you find yourself in.

There’s a huge difference between “I bought the car because I just got a huge promotion and I wanted to show myself that I made it” versus “I bought the car because I’m about to drive cross-country to a wedding, and my old car, that’s been on its last leg for the last five years, is making this sound… And I’m not gonna get stuck on the side of the road. It’s time. I’ve gotta finally replace this thing.” Do you know what I mean?

Yeah, absolutely.

Very different requirements. If you talk to people with kids, they’ll tell you that nobody when they’re 15 says “I can’t wait until I get to buy a mini-van.”

[laughs] Jerod owns a mini-van. Do you still own a mini-van, Jerod?

Oh, yeah.

Oh, yeah. Of course.

It solves the problems that we have…

A lot of young couples who have the first kid will say “We’re never getting a mini-van. No way.” And then as soon as they get to the second kid - what happens?

Mini-van.

Mini-van.

It’s so convenient.

Because it’s getting them in and out of the doors, it’s those sliding doors… There are design requirements that until you’re in the job, that you don’t value.

You can’t appreciate, yeah.

[01:00:01.06] But then when you’re in the job, all of a sudden - boom. “I need this because of what I’m experiencing.” So that’s the general point of view of the thing. And then the way that we actually find jobs… So jobs are an empirical phenomenon. They exist out there in the wilderness. They’re wild, natural phenomena. It’s just stuff that happens to people, based on situations they bump into because of how things are.

So we don’t think of like “What’s the job to be done?” by sitting around a conference room. We actually interrogate people who did something to get the chain of cause and effect streaming backward from that thing that they did.

Somebody buys Basecamp, and then my basic assumption is they didn’t buy Basecamp because they rolled the dice today and said “What do I do today?” and the dice came up “Buy Basecamp.” They bought Basecamp because something else was going on, that needed to change. So then we say “Well, what happened?” And then you get “Oh, I just hired three more people, and we have more customers than before, and I couldn’t find the thing in the Excel sheet, and then we almost missed the deliverable, and I thought I’ve gotta find a better way”, or whatever it is. You get this unfolding through time of what actually happened to them as a series of cause and effect. That’s where you get your requirements from.

So when I talk about doing those ten interviews, that’s what these are - they are interrogations about the chain of cause and effect that led up to somebody making the purchase, or using a feature, or something like that. And to come back, the point was that if we do that analysis, we can talk to just ten customers, and we can get 3-4 jobs out of that. And then the question is “Well, how representative are they?” Then we can do “big data” in the sense of we can survey thousands and thousands of people, because we know the right questions to ask.

A lot of this big data stuff is incredibly powerful if you’re trying to automate a perceptual task. If you’re trying to recognize fire hydrants and sidewalk markings and stuff like that, then AI is gonna help you. But if you are trying to figure out who belongs in what bucket, based on what they’re trying to do, actually what you really want is to have – the big data you want is those gigabytes and gigabytes of a single interview of their story. So longitudinal big data is totally different than – what’s the opposite? Latitudinal, I guess? You never hear that.

Like aggregate maybe…?

I don’t know. It’s totally different type of data. It’s big and deep in a different direction. And then what you get by doing the clustering on “Where was the causality similar and where was the causality different? Where was the intent similar and the intent different?”, then you get these clusters out, and now you have a few very simple questions to ask people. And we did this, we’ve put a survey on our onboarding flow, and we asked people a few questions based on the job interviews to kind of bucket them… And then we got our percentages, of like “30% of customers are in this job, and 10% of customers are in that job”, and that allowed us to weight them in terms of our understanding of the market composition.

So you have big data in terms of scale, but the number of dimensions is very small. So I think you want really high dimensions when you’re doing this longitudinal stuff. When we do the analysis, we do ten interviews, and then when we do the clustering, we’re actually clustering on something like usually on the order of 25 dimensions. We’ve literally got vectors that have 25 different dimensions in them that we’re clustering on. But then, once you know the jobs, then you’re saying “Either you’re here for this, or you’re here for that, or you’re here for this.” You’re asking people like 3 or 4 questions. So you’re vastly shrinking the dimensionality of the data problem. And then you’re asking people simple questions, and then you’re getting relatively simple answers that size it.

[01:04:12.28] What’s interesting is this a-ha moment that surfaces from this interrogation, these jobs… And once you find the problem you’ve solved for one, now you can find probably more so in your dataset, but then be able to attract or know the people that have this same problem, or a similar problem. So it’s easy to 1) design better product tours because you’re improving, because you understand the problem better, but it’s also easier to scale those who have the same problem, and bring in more customers.

That’s the key insight… Look, everyone is so different; as individuals, people are totally different from each other. But if you look at the situations people find themselves in, we all live in the same world. And the world is structured the same way. And the things that we come into, like when we get hungry and need to eat and we run out of time, or when we’re trying to keep track of stuff, and then we lose it, and then we don’t know where we’ve put it - we all run into the same stuff all the time.

So people are very different, but there’s actually amazing overlap in the things that we struggle with and the things that we try to do and the hurdles that we try to get over.

Alright, before we go into this last segment, you know that we mention on the show, and have mentioned in past shows how much fun we have in the breaks. Well, this last segment ended up becoming just one gigantic break. We had a lot of tangent conversations, interesting tangents etc, and we just never got back to doing the show. And before we knew it, 45(ish) minutes had passed… And Ryan was talking, we were talking, we were riffing, and we’re like “Should we do the show?” and we were like “Well, we’ve kind of been talking. Let’s just cut up everything we’ve just been talking about these last 45 minutes, which should have been segment three of our show, into segment three. And just call it a day. It was awesome.” So that’s what this is. Here we go.

So one funny software situation that I was in one time, which I thought of when you were telling your story about how somebody goes about inviting someone to Basecamp, or kind of matriculating the project, was I had a client who built some software that was for financial advisors; it’s a way to let the financial advisors get to know their clients better etc. Basically, a survey-builder with an email tool. So there’s advisors and there’s clients. And an advisor would sign up, there’s a bunch of stock surveys, things that they recommend… And financial advisors love these questionnaires; they live on them. And their clients don’t love them, so it’s a weird dichotomy… But anyway, so there’s all these stock ones, and then you can send them to your clients. That’s the typical starting point.

Well, this thing gets out there in the wild, and he starts getting some users… You guys are better product people than me, so maybe you would have seen this coming a mile away, but an advisor signs up for this thing… What do you think is the first thing that they do? They sign up as an advisor, and then you sign in, there’s a bunch of surveys, there’s an empty list of clients, you can import your clients, or whatever… Any guesses on what an advisor might do at that point?

No, I’m curious to learn.

So what we thought they would do is either import their list of clients, or maybe type one in and send them a survey. Well, it turns out what all of them did - which we learned very quickly through bug reports and all sorts of stuff - is they actually just entered themselves as a client and send themself one… Because they don’t wanna be embarrassed by trying out this new – you’re not gonna try out a new tool on your actual client, you’re gonna try it out on yourself, right?

Totally.

Well, the system was set up with advisors and clients, and once you’re an advisor with an email address and you try to create a client with the same email address - it’s okay, you can do that, but then when you send that person one, it’s already signed in as the advisor… There’s all sorts of things that we had to iron out to make that thing work. But it’s just a fundamental misunderstanding of how somebody might try the product before – like, we jumped straight to the “You’re using it” step. You know, there’s a timeline there.

Totally.

People don’t just start using a thing. If they did, then they would just use it the way it was designed. It was designed to be used assuming you’ve already adopted it, but there’s this – which is obvious in retrospect… They just started sending it to themselves, and they’re like “It doesn’t work!” It’s like “No, it totally works. You’re using it wrong.” [laughs]

There’s a system of things that the user has to go through as a series of steps, that they have to get through to get to the other side of this thing. And there’s a bunch of functions that they actually have to perform.

[01:12:00.19] And those map back to the anxieties that they have. We call it an anxiety in the “job to be done” framework of these four different forces. One of them is anxieties. An anxiety is something that you’re asking yourself “What if this happens? What’s that gonna be?” And you need a mechanism to answer that question for yourself in order to move on to the next step.

Right.

And if you understand that as the person moves through time, this is the point where this anxiety comes up, then you can build a mechanism in response to that.

Exactly. Yeah, there was definitely a lack of just real-world thinking about how somebody might go through a process of adoption, and how answering that anxiety of “I don’t wanna embarrass myself with a tool I’m only testing out in the first place…”

Totally.

So we ended up building a thing where you could just send yourself a survey right away… You know, like “Log in. Hey, try it out on yourself.” It made more sense, but it was almost embarrassing launching… It was kind of a soft launch with these guys, but it was also embarrassing when we realized we didn’t understand how people were actually gonna use it when they were test-driving.

That really comes back to what’s exciting about this (to be named) mental shift… When we have that in our minds from the beginning, we find that the first time we start thinking about a problem, we’re gonna put ourselves into the driver’s seat of that person, in that situation; and we’re not gonna be asking ourselves about their demographics, we’re gonna be asking ourselves about “Why am I here and what am I trying to do next? What am I thinking about? What do I need to get through?” And then you’re asking the right questions much earlier. And if you don’t know what the questions are, which - like I mentioned, this stuff is empirical - then we do the research… Which doesn’t mean some big, gnarly research project, it just means that you talk to somebody who’s gone through the process before, and ask them what they did, step by step by step.

Yes, yes, yes.

I’m curious of Ryan’s curiosity to the psychology of the brain, cognitive load, stuff like that.

You’re curious about his curiosity?

Yeah, I’m just curious, because he’s talking about things that require empathy, and empathy leads you into psychology, to some degree, or at least understanding more aspects of compassion, and adding other things together. So to design is to think like some other human, so you have to have some basic form of empathy to do it well. Would you like to talk about that though, the brain science stuff, or any brain-related stuff that you’re really curious about?

Well, I don’t really see it as having much to do with – I mean, if you want, you can look to the brain to find some sort of neural correlates of this stuff, but I don’t really look to the brain as the seat of these things. I think it’s much more about the circumstance. You can black-box the brain, and look at the circumstance, and then you get the right variables out. It’s a question of what level of abstraction you wanna deal with the world on.

You raise a really good point about this thing, about compassion and empathy… I think we have different things which drive us, in terms of what we like to work with and where that moment is where we do the fist pump in our own work… Like what’s that moment for you where you’re like “Yeah! It all clicked together and I achieved my goal.” I kind of sit in-between a lot of roles, because I have programming in my background, but I also do product and user-facing stuff… So I feel like I have a little bit of both. But there’s a satisfaction as an engineer of flipping the switch and then watching the current run-through, and then the gizmo does what it does on the other end… You know what I mean?

Yeah.

…that moment of like “Oh, it did it! The test ran green. It did what it was supposed to do. That’s awesome!” That’s one orientation. And then there’s another orientation of like - there’s a struggle somewhere in a life situation of like “I keep losing this stuff, or we’re trying to accept donations at this non-profit, and every time we try and get people to sign up for a membership there’s too many steps, and then their eyes glaze over and I lose them, and they never follow through…” These sort of – I don’t know what you call them; they’re like the domain-specific problems that come up. I think you can get hooked on solving those kinds of things for people, and in essence it’s no different than getting the gizmo to work when you flip the switch… Because all of it is cause and effect, and all of it is interdependencies and dynamics. It’s just a question of sort of which domain you like to play in, where you get your kicks of what’s more fun to solve.

There is an aspect of psychology, but I think that, again, every time that we – what I find is that every time I try and dig into the psychology, I go down a rabbit hole that doesn’t help me help the person… Versus if I look at it situationally, then I can say – you can bracket the psychology and say “Look, regardless of who you are, if you were in that situation, what would you want to do, or what would you want to happen, or what would be helpful?” And that brings everything to a level of concreteness and objectivity where we can be way more productive, I think.

We’re seeing now - there’s a huge wave right now where all this behavioral economics stuff is getting thrown out.

Really?

[01:18:12.28] Oh, yeah. It’s just starting, but you’re gonna see it. All this stuff about like loss aversion, and all these biases that people have - it’s all BS. It’s all BS, because the thing was that the people who did this work, the behavioral economics people, they were starting with a very artificial, fabricated model of how they thought people made decisions… You know, these Bayesian probabilities, and stuff like that. And then when people didn’t behave the way their models behaved, they said that something was wrong with the people. That they had biases. And what it turns out is that if you come up with a better model, then you can actually say that the way people behave is completely rational. And again, Ole Peters has been doing some really fantastic work on this… There was a paper on–

Yeah, what was the name of that area of economics study that you mentioned that your friend is doing? What was it called?

The new field of work that he’s doing is called ergodicity economics. It’s a bit of a mouthful, but the thing is that it draws from, like I said, this piece of ergodic theory from physics. But anyway, his body of work is known as ergodicity economics… And a huge part of it is that he’s taken a great number of puzzles in economics or decision-making, and taken out the so-called psychological bias by using a different model. A much simpler assumption. You get perfectly consistent results with the data; it’s a question of using the right model, instead of saying that the people are wrong because they don’t match our model.

Irrational?

It’s a new area that’s really blooming right now, and it’s gonna take a while, because the behavioral stuff really penetrated the popular consciousness, so a lot of people now are aware of these things… But it was a big wave also because of this very popular book that Kahneman and Tversky wrote, this thinking fast/thinking slow, and so on… But now a lot of it is being discredited, so it’s actually a very exciting time in that field.

What they wrote in that book?

Yes.

Really?

Yeah.

So he is into it, but he’s not into it. He’s into it enough to know that he’s not into it. [laughs]

I like it. I don’t know the book or the authors’ names, but I do like listening to the EconTalk Podcast.

I love EconTalk. He’s so good. It’s one of my favorite podcasts.

Me too.

He’s such a fantastic interviewer… I was just listening to an episode yesterday, and I love how he’ll just say “Yeah, I don’t agree with you.”

Totally.

It’s so great to hear that on a podcast, instead of the echo chamber where everyone is vibing on each other’s opinions… You really hear a difference in view, but with a great degree of civility. It’s fantastic. It’s really great.

Yeah. I agree. Not to “just agree with you” degree, but I do agree. [laughter]

Well… I disagree. [laughter]

We could talk econ for the last segment, but I don’t know. I think Ryan might be in his own league over there… Because all I know is what EconTalk tells me.

[01:21:23.26] Yeah, actually I would love it if they would get Ole Peters onto EconTalk. That would be a great fit, but I don’t know…

That’s funny, because I was just gonna search their archives for ergodicity to see if I could listen to something about it, because I don’t – we don’t have time to read books, sadly…

I’ll give you a really good, short YouTube video that gives you a very good introduction to it.

Okay, cool.

There’s a talk that Ole gave that is a really great primer. You get it in the first ten minutes of the video, the basic idea…

Nice.

And it’s a really nice intro. So I’ll give you a link for that.

Okay, I appreciate it.

Yeah, I actually found out – Nassim Taleb was on EconTalk, and he was actually telling Russ on the air that he has to get Ole on. So hopefully–

Nice.

There’s some connection there. Hopefully it happens eventually.

Yeah.

And I’m by no means a well-informed economist or anything like that, but it turns out that there’s actually a lot of overlap in the theory aspect of this stuff with what I do… So I have a slightly deeper than an armchair relationship with it.

Yeah, especially if your designs are intended to make money, or solve people’s problems, or influence people. You at least want to study human behavior to some point, to have some basis…

It’s funny, I tried to look at economics through that lens early on, and there was nothing useful in it, because it’s all BS. The models of economics – have you ever known a single businessperson who drew a utility function to make a decision about how to run their business? There is just no relationship between standard economic theory and what actual people who create and act in the economy do.

Yeah, it’s the same reason they can’t predict how the economy is gonna recover…

Right.

Well, they can’t predict any of it.

Yeah. I mean, you can assume certain things, but causality, timelines, problems - all these things we’ve been talking about compound.

Exactly. But then the thing is you need a notion – you actually do run into the notion of utility, in the sense of “What is valuable? What is useful? How much do people care about this thing and need it when I set a price on it?” They’ve got their fingers on the right questions, but the models aren’t there. So in a way, this “job to be done” stuff is actually a redefinition of what utility is.

The utility of something has to do with the job I’m trying to do, and the context wrapped around that. So there’s just a lot of interesting stuff brewing, especially around Ole’s work. I definitely recommend checking that out if somebody has the right sort of nerd inclination for this kind of – it’s a little far afield, but it’s very eye-opening.

By the way, I’ll mention - on the other side, there’s a really accessible book, that’s fantastic, called “The End of Average” by Todd Rose. The End of Average actually touches on all this stuff, but totally from the other side, from a completely accessible angle. He really gets into detail about different cases where people averaged over the data of a bunch of people, versus following individual pathways… And he looks at it in medicine, and in schooling, and in a variety of different situations. It’s a very short and very pithy book that also is about this sort of mindset shift that we’ve been circling around for a while. That’s a really good one.

How involved are you on on HEY? Is that something you wanna talk about? Or are you off the HEY project? Is that a different team, or…?

Yeah, so I actually was never really involved with HEY very much, except for a few key points.

Okay.

HEY came up from Jason and David kind of feeling like they had an itch of their own that they wanted to scratch, which is the exact same way that Basecamp classic (the first version) happened. There was something that they were seeing where they wanted it for themselves. So I didn’t really have anything to contribute, because they were 100% driving based on what they already were seeing in their own use case of what they wanted.

It makes sense, yeah.

And then I did play a role – there were a couple points where it wasn’t really clear how to distill it… You know, when you’ve got a million ideas for a product, but you have to boil it down to like “These are the three main things that it does.” There was a point like that early on, where they pulled me in and we had a conversation that kind of helped frame what the main function of HEY is, versus the secondary functions, like what’s the core… And then there were a couple times where I got pulled in for review, because they needed outside perspective. But other than that, they’ve really driven the whole thing.

Right on.

I’m really digging this last segment… It’s different for us to just grab-bag it, but it’s been a lot of fun, Ryan. It’s been great to catch up. I know you’ve got a print edition coming out sometime soon - what’s the next step for that? Where can people get that? What’s next?

Yeah, so we’re working on the print edition now, and it’ll be soon(ish)… But we’ve got some unknowns we have to figure out with the formatting, and stuff like that. To find out when the print edition is out, you can go to Basecamp.com/shapeup, and right at the top, underneath the buttons to read the book, you’ll see a link that says “Join the newsletter.” If you join that, we won’t send you anything other than news about format. So when the print edition is available, then – we’re also gonna do an eBook version and you’ll get notified when those are out.

I’ve just subscribed, so I’ll be notified. I can’t wait.

Awesome.

Ryan, thank you so much for your time, man. It’s been great catching up.

Thanks a lot, guys. It’s been fun.

Hey, thanks guys. I appreciate how far out you’ve let me go… [laughs]

No, it’s fun.

We enjoyed that. We sometimes have a “no rule direction is direction.”

[laughs] That’s a good spin.

If you just know “I’m gonna go West. We’ll get somewhere.”

Totally.

Some of the best conversations aren’t on rails. That being said, some of our shows are specifically “We’re gonna do this, this and this”, and other shows we’re like “Hey, let’s let it be a conversation and really let it flow the way one would naturally flow.” I don’t know, I enjoyed listening to those podcasts. Again, it’s kind of like “What’s the job to be done here?” Sometimes it’s to educate, sometimes it’s to entertain, or just to hang out with people while you’re mowing the lawn, or whatever.

Totally.

If I’m trying [unintelligible 01:29:21.04]

By the way, that’s where Snickers got that campaign “You’re not you when you’re hungry.” It was from doing this research.

Is that right?!

This exact process is how – and before they did this research, they were actually in really bad shape in terms of sales, and they did a massive turnaround in the ’90s by doing this exact type of work.

Wow.

I don’t remember that one… But the one I do remember is “Gonna be here for a while? Grab a Snickers.” I liked that one. Because yeah, when you’re stuck somewhere and you’re like “Gosh, darn it…”

The advertising though for it – because you can sort of either put yourself in the picture of the Joe Pesci actor that is not supposed to be Joe Pesci, but acting Joe Pesci, with that sort of aggravated attitude… You can put yourself in that person’s shoes at a given moment in your own life…

Exactly. That’s the job.

…and you didn’t reach for Snickers, but you’re thinking “Well, the next time I now have a new tool to reach for.”

Yeah. Or the footballer player that becomes Betty White, right?

Yes.

It’s because they’re mirroring to you something that happens to you, and they’re wiring the light bulb before you…

Oh, yes…

…so you can say “Oh, okay. When that happens, I need this.” It’s the same thing that happens when you go to IKEA. IKEA has all kinds of things that objectively suck about the experience. Who wants to go and pack their own boxes and load their own car with a whole bunch of boxes, and stuff like that? Compared to like a premium furniture store, this idea that you would roll around a warehouse and fill your own cart - why would that be a good user experience? But when you look at the trade-offs that they’re making, the main job to be done of IKEA is “Get this new place furnished today. I’ve got this one weekend, and I’ve gotta get this place set up and I’ve gotta move on with my life. Today.”

So that means there’s no custom ordering, there’s no waiting for your fabric choice and then having it delivered… You’ve gotta get it all done today. And how is it all gonna fit in your car if it’s not flat-packed? And how are you gonna buy it all at once unless it’s cheap? It needs to all be really cheap, so there needs to be this cost factor of – you’re willing to make the trade-off of loading your own cart, because you get to get all the bookshelves, and the desk, and the kitchen, and everything all set up today, and you’re gonna be able to do it all in one shot. It all holds together.

And one more thing - you can take the whole family.

Yeah, and that’s the other thing, too…

And it’s somewhat even fun for them.

Well, and why is there a cafe? Because it takes all day to buy everything for a new apartment.

It sure can, yeah.

It literally takes all day to get all that stuff, and you can’t go away to eat, because you’re not done yet. So there’s a deep logic to the whole thing, based on the job.