The Changelog: Software Development, Open Source - Shipping work that matters (Interview)

Episode Date: June 25, 2020

We're revisiting Shape Up and product development thoughts with Ryan Singer, Head of Product Strategy at Basecamp. Last August we talked with Ryan when he first launched his book Shape Up and now we're back to see how Shape Up is shaping up — "How are teams using the wisdom in this book to actually ship work that matters? How does Shape Up work in new versus existing products?" We also talk about the concept of longitudinal thinking and the way it's impacting Ryan's designs, plus a grab bag of topics in the last segment.

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 quacks like it should. So it's going to work. And then I put that back into my pitch. And now like I've passed the velvet rope test

and I've passed the concrete test. And I like this velvet rope test being in there. Yeah. So that's a real thing. I thought we just made this up on the fly. That's how these things happen, man. You know, like everything comes out of conversation. I love it.

You know? That's right. Bandwidth for Changelog is provided by Fastly. Learn more at Fastly.com. We move fast and fix things here at Changelog because of Rollbar. Check them out at Rollbar.com. And we're hosted on Linode cloud servers. Head to Linode.com slash Changelog.

Linode makes cloud computing simple, affordable, and accessible. Whether you're working on a personal project or managing your enterprise's infrastructure, Linode has the pricing, support, and scale you need to take your ideas to the next level. We trust Linode because they keep it fast, and they keep it simple. Check them out at linode.com

slash changelog. What's up? Welcome back, everyone. This is the ChangeLoggle podcast featuring the hackers, the leaders, and the innovators in the world of software. I'm Adam Stachowiak, Editor-in-Chief here at ChangeLog. On today's show, we're revisiting ShapeUp and product development thoughts with Ryan Singer, head of product strategy at Basecamp. Last August, we talked with Ryan when he first launched the book ShapeUp, and now we're back to see how ShapeUp is shaping up. How are teams using the wisdom in this book to actually shift work that matters?

How does ShapeUp work in new versus existing products? And we also talk about the concept of longitudinal thinking and the way it's impacting what Ryan designs. And we also cover a the concept of longitudinal thinking and the way it's impacting what Ryan designs. And we also cover a grab bag of topics in the last segment. So make sure you stick around. Not even a year later, but ShapeUp is out there. So how is ShapeUp shaping up, Ryan? I've been pretty blown away by the results actually i keep hearing emails

dripping in from folks uh talking about hey we just finished our third cycle or we just finished our fourth cycle you know these are six-week cycles so this is like it's a it means they've they've done some reps they've really learned some stuff and we're seeing some amazing results i was i was on a phone call uh 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 like, I don't know what to call it. Emotional energy is very surprising. I mean, you know, you talk about something like product development and it can be very functional, you know, like, did we get the stuff done on time and 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 you know product and design and and the development teams are like working together and they feel way more kind of plugged in and included in the process. And morale is up. Stuff like that has been really awesome to hear. Have you had any teams give it a shot and say, eh, it's just not for us? I haven't heard about it, if they have.

They probably wouldn't tell you, right? 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, other teams that have said, you know, we sort of unlocked the potential of our programmers now and everyone's killing it, you know, in a way they weren't before other people. Um, it, it starts to reveal issues on the leadership side where it's like, oh, we, we tried shape up, but we were having a hard time getting everybody on the sort of at the betting table to, 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 who's missing from the table so to speak even yeah and because shape up kind of integrates in so many ways you know it integrates design and development inside the cycle it integrates like the leadership at the betting table so that they're actually paying attention to to like how are we going to spend our time next? You know, it creates all those opportunities for people to look around and say, okay, how are we actually working together? And 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, like the same questions kept coming up. Like in the very first version, people kept writing and saying, well, what about bugs? And what about like 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 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. And we want to continually ship improvements on time to that product.

And then the question comes up, you know, like Hay is about to come out, right? The new email app that we've been working on here at Basecamp. And that people have been saying, like, did you use ShapeUp for Hay? And the answer is absolutely. But the thing is that there's some there's some sort of stages of work in a new product where the the the straight up kind of shape up method doesn't apply actually and i wrote like a small appendix on this but actually i found that i needed to expand on it when i talked to people people need more detail on that and 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 want to 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 ShapeUp into, say, customer development and revenue growth? Or what is it sort of missing in terms of a new product? Yeah. 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.

Oh, that's a good question. You know what I mean? What facets are different with a new product. Yeah. ShapeUp is all about when we already have a strategic idea of what we think we want to do, how do we turn that into a project that people can actually execute on where everybody's clear on what we're going to do next and the team is going to be successful building it and the team is going to make more decisions about the details and they're going to have those guardra, and they're going to, they're going to have those guardrails and they're going to, they're going to be successful getting the thing done on time.

So it's, it's shaping is really about like, we know what we want to do, but we can't just go tell a team, Hey, go figure it out. We need to work out the outlines and the guardrails of what this thing is and what it isn't in order to give it to a team and kind of make that handoff really successful. So already, even just kind of in the traditional sort of doing shaping for a product that is already up and running, we aren't really addressing those kind of more open strategy questions, you know, about what to shape. That's something that the book deliberately doesn't get into because that's a whole nother 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 like, 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. 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 some things that's standing you know where like the the key pieces of functionality are built and they're running in code and and that that architecture is there like before you have that it's just way too open-ended you're you're you know like the first commits to a totally new piece of software you know how you just end up throwing all that

stuff away like yeah you you you totally change the schema you you you significantly change certain model relationships things that you even stupid like stuff that you think is a one-to-one becomes a one-to-many like there's fundamental things in the architecture that you have to figure out and what happens is when you're doing completely new product, there's just so much scrap that if you try and delegate it away to a team, you know what I mean? Like 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 like, 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,

you know, or, or kind of even to yourself, if you're a really small team to make that promise to yourself of like, I'm going to build this feature next. And I'm sure that I'm going to be able to get to the end of it. And it's going to be done the way that I think it'm going to build this feature next and i'm sure that i'm going to be able to get to the end of it and it's going to be done the way that i think it's going to be from the beginning like 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 going to say upfront, this is what we're going to do and then give it to somebody else and they go do it because we don't know how it's going to hang. We don't know how it's going to pan out yet. It's just too early. So what we usually do is we'll have the more senior people,

you know, like David will often have his, he'll be hands-on, you know, David's our, you know, co-founder and CTO. He's going to have his hands in the actual code for the first couple features because those tentpole things are going to define the architecture for the whole product where everything else is going to fill in and he's going to be doing he calls them i think also this goes back to pragmatic programmers the notion of a tracer bullet you know it's like i'm firing it's like i'm firing to learn you know 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 and then jason or it's like in the case of hey we had another designer jonas who's one of our more senior designers who was 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 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 like this is kind of what we think we want to pursue there was an appetite in the sense of like we're going to spend six weeks exploring this area but we don't really know what's going to come out of it and that's very different than straight shape

up right but then what happens is 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 want you kind of want no boundaries in exactly because that's what enables the creativity but what happens is uh 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 we're like, this is what it's going to be and then delegating it out because we we just we just can't see far enough we just can't see it yet but then what happens is after like i don't know maybe sometimes two sometimes three cycles of that the core pieces are going to get figured out and the the the couple tentpole features and architectural decisions are going to get laid down and and david likes to say pouring concrete you know there's that part of the app right it's like we're never going to change this this is the concrete like we're not going to bust this up and like refactor this or 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 you know because you know kind of what they plug into and that's where you can flip into straight up shape up we're like we're going to shape straight up we're going to look at straight up shape up we're going to we're going to define up front like what this is going to be we're going to define it at the right level of abstraction, not too much detail, but also not too fuzzy. And then we're going to give this to a team. They're going to completely take responsibility for it, and they're going to 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 here you know pouring concrete that's foundation right you got some rebar in there you

get the foundation you don't put a house on what just gravel and sand you put on a foundation that's locked it's it's specced to the room sizes if the foundation isn't there you're not putting beams on it to start building a house. Yeah, and think about remodeling a house. If you're going to remodel a house, you're not just going to move any wall. You know what I mean? There's certain things about that house

that are not going to change, right? Load bearing. Exactly. And then there's areas where, and there's a difference between adding an extension or moving a wall you know to create different space versus moving furniture around versus painting there's all these sort of different different levels of change that can happen but you've got to be really deliberate

and conscious of what are the load-bearing parts of the app that aren't going to change and then 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 going to bust the concrete so what are our other options yeah related anecdotes 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 what a survey i think the survey company yeah anyways whoever flagged 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 a foundation and they realized, we put it in the wrong place.

Oh, man. And at that point, it's very expensive to fix that problem. So you got to 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 going to need to tear out all the concrete, dig a new hole, and put the foundation in where it's supposed to go. It's just painful.

So painful. And I think it was painful for the survey company who has general liability for a situation 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 describe this because you got to get your foundation right when you build a house you

build a building you can see the concrete there you can see the you can see the framework right you can see all that and you can say okay the foundation's poor we have a cornerstone it's not in the wrong place it's looking. 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 slash laying foundation to straight up shape up? Is it just intuition?

Or are there like obvious moments when you can say, yep, it's time to go to the normal way oh man that's a great question um as far as i can see it's a mix there is some there is art to it um but there is science to it as well because at the end of the day it's a question of interdependencies you know um if you look at the house story 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's 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 thing. So if you think of it in terms of a dependency graph, you can see that structure. 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. if you look at the software in terms of what is it do for users and what does it do for customers there are you can segment in terms of primary functions and secondary functions

so for example base camp has a feature to um to to tweak whether or not you get your notifications via email or you just get them in-app, right? It's not a primary feature of Basecamp. People don't buy Basecamp because they're going to 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

so for example the way that that a group of people can all access the same to-do list and see the same thing uh is is is is a primary function of base camp or or the fact that you can post a message and a pre-defined group of people is all going to get notified of that message and that message is going to be accessible within this sort of accessibility sphere that these people are all part of, that's super fundamental, right? And any feature we add to, let's say, a Basecamp project is going to 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. 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 simplified the design for the use cases we cared about that as a consequence cut off all kinds of other options so for example access in base camp is all based on the assumption that everybody sees the same thing and anytime you want to make a custom rule that like this person on this project can see this, but this person can't, you completely like run your face up against the, it's like you're grinding your nose against the grain of the concrete. Like it does not want you to do that, you know? And that's the kind of thing where if we wanted to have finer grain permissions of who can see what within a project, we would have to significantly rethink that. And it goes back to just a dependency analysis.

Do you know what I mean? look at the graph of what depends on what like project 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 i don't want to put my face to the foundation either but you know that's really gonna hurt there's a feeling like when you're when sometimes when you're adding new functionality or or doing a refactoring or changing the way something works, you're just kind of like flying along, you know? And it's like everything kind of is coming for free because you're leveraging all those dependencies that are underneath you. And then all of a sudden you want to 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 want to change this.

Let me throw something out to that too then, if it's a different angle. Maybe it's not as painful as it should be. Maybe it's a velvet rope. Ever hear this concept where you know the kind of customer you want? So this foundation is like, if you want to use Basecamp, you have these kind of desires from the software you're trying to use for the purpose of Basecamp, right? So rather than that being a painful thing, sure, you're hitting 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 customer 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 going to succeed is if they have to rip up concrete the scope is going to blow up exponentially on them yeah just in terms of work because if you start to if you pull on that string you're going to pull the whole rest of the app with you because of the dependency tree right so that that's the kind of risk of like we want to do it but if we try and pursue it it's going to blow up in our faces because of the technical reasons the i think the velvet rope case that

you're pointing out is really important too but it's a very different type of risk yeah it's not a risk that that the team is going to run into a scope explosion the risk is that they're going to successfully ship it and then we're going to end up in a in a market position that we didn't that we didn't want to be in right serving people that we didn't intend to serve or getting feedback that doesn't relate to the sort of core of how we make money or or that kind of a thing right you know that kind of that foundation is sort of the dna of of base camp right yeah yeah so I would say... 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 want to 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 in different parts of the company then the boundary development the boundary of what you can and cannot change uh in terms of the the code you know 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 sort of can talk about supply side and demand side right the thing about like 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 the thing about sort of what projects to pursue the sort of velvet rope thing that's more of a demand side thing that's coming at a different that's coming more from the design side and it's coming more from the from the shaping side of things so i i'm not a programmer um i'm working on what may become bc4 right now and uh a lot of that is i'm i'm totally in velvet rope land right now you know like there's things that i

where we could do that we might want to do um 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 and do they keep us you know do are we going to continue to serve the people that we want to serve by by doing this um 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 got to do some due diligence and talk to talk to david or talk to jeff and say like here's this thing that i think i think we should do is this consistent with the architecture we

have or not and um and can we do like a little spike so there was a 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 want to 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, eh, there's sort of too many unknowns in terms of building that. So it just sort of gets kicked off the table. You know, 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, like, this is what I'm thinking about doing. These are my assumptions about how the existing system works. Do you think this is consistent and conform thinking about doing. 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, you know, 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 like a little, you know, a little bit of code in some uh in a in some little uh what are they called like those things in git that like don't belong to anything they kind of just hang on their own um anyway i don't remember what they're called but they're like these little sort of throwaway pieces of code that you can just uh a branch uh no it's not a branch it's like it's like not part of the base camp repo it's just kind of like uh uh what are those things called um it's like a free floating piece of code that you can embed somewhere um module anyway no it's like a whatever it's not part of it's not part of a software

project it's not part of a repo it's like this uh free it's like this like 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 we'll put it in the show notes you'll figure it out anyway what's called it's like a little throwaway like scrap of a thing that you can that you can that you can make in github anyway um anyway there's just this little a gist that's it it's there you go good job we have a winner so satisfying the donkey just keep guessing jargon until i get one anyway i'm sure we we used your listeners time very valuable you know very well in the last whatever 10 minutes that was okay anyway um no but he he then he he can just throw a little bit of code back

together and say hey look like 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 quacks like it should so it's going to work and and then and then i put that back into my pitch and now like i've passed the velvet rope test and i've passed the concrete test. And I like this rope test being in there. Yeah. So that's a real thing that we just make this up on the fly. That's how these things happen, man.

You know, like everything comes out of conversation. I love it. You know, 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 gotta you have to shape the work first you have to have a sense of like what is this piece of work that i'm trying to do you know and that's actually that's where we get language from i think is from being in the moment where we where we need it you know yeah yeah so one last question here on this front you talk about bc4 these major versions of base camp and i just on a technical sense are

these major versions an opportunity to you know add another wing to the mansion pour some new concrete or are they mostly remodels of the code base like are you pouring new things are you remodeling how to fit inside of the current architecture so that's case by case so far when we when we went from bc1 to bc2 and to bc3 every one of those involved a new concrete and we actually built those as completely new projects from scratch and then and then ran them and sold them in parallel to the old version. So BC, BC one and two, um,

right now are separate code bases running on separate servers with separate customers. And, um, that allowed us to make, uh, 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 uh but there were things that we wanted to do that we just couldn't get there from here and it's like man like look we've got a new i think at the time we were using the we were calling it like the chassis you know like we need a different chassis for this um kind of borrowing from i think automobile industry on that one yeah and um so that's a big that's a huge part of it is what are we trying to do? And does the thing that we're trying to do actually require a new chassis or not? Right. 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 two and three. Actually, we don't believe that that's true for four as of where we are right now. David recently shared this new pattern called delegatable type, and it's at the core of BC3. So 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, like the name of the project and the description

of the project and stuff like that, that actually is on what's called a bucketable. So a bucket has a bucketable. And the bucket is is actually an immutable thing um that uh that is kind of the value of the bucket and uh and we use the the same pattern for every piece of data that that lives inside of a project i mean everything from a comment to a to-do to uh to uh everything is a is what's called a recording and a recording is the association between a piece of data and a bucket and that a recording has a recordable which is an immutable throwaway thing so which also by the way gives us like stuff like versioning for free because if you make a new version of let's say a document the document is a recording in its sense of it has a it sits on a tree somewhere um but the document as a sort of

blob of of of of stuff or a value i mean not a blob in the sense of a binary but you know like a right that content of that of that document is actually a recordable not a recording and then if you if you make a new version of a document we actually uh 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. And anyway, this is the kind of stuff that David figured out for BC3. And the architecture has just been awesome. This has never before in our what is it now 17 year history since since we started working on bc on on base camp classic the first one there's never been a time where we were like a few years into the future from one of from a from a product and looked back at the code and thought this code is awesome we

love this you know what i mean and that's that's what that's where we're at like we look at the code for bc3 and we're like this is awesome like we love this this this continues to work and we and it's it's it's beautiful and it's enabling and it's spacious and it's just the right 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 you know which is just an awesome place to. And then we look at the things that we want to do that seem hard or maybe divergent in BC4, and none of them are running into conflict with this architecture. before, where it actually, we think it's going to 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. How much time does your team spend building and maintaining internal tooling?

I'm talking about those behind-the-scenes apps, the ones no one else sees. The S3 uploader you built last year for the marketing team. That quick Firebase admin panel that lets you monitor key KPIs. Maybe even the tool your data science team hacked together so they could provide custom ad spend analytics. Now, these are tools you need, so you build them. And that makes sense. But the question is, could you have built them in less time, with less effort, and less overhead and maintenance required? And the answer to that question is, yes. That's where Retool comes in. Rohan Chopra, engineering director at DoorDash, has this to say about Retool. Quote, the tools we've been able to quickly build with Retool have allowed us to empower and scale our local operators, all while reducing the dependency on engineering.

End quote. Now, the internal tooling process at DoorDash was bogged down with manual data entry, missed handoffs and long turnaround times. And after integrating Retool, DoorDash was able to cut the engineering time required to build tools by a factor of 10x and eliminate the error-prone manual processes that plague their workflows. They were able to empower backend engineers who wouldn't otherwise be able to build frontends from scratch. And these engineers were able to build fully functional apps in Retool in hours, not days or weeks. Your next step is to try it free at retool.com slash changelog. Again, retool.com slash changelog Twitter recently, longitudinally. You said good design requires thinking longitudinally.

Now, that's a hard word to even say, 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. And I mentioned when we were off, 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 10 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, and just saying, look, we surveyed customers and 20% say this and 30% say that, or something like that. And taking the N of one, looking at one individual case, but playing it out through time and say like if i want to understand what to design i need to understand actually cause and effect like 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 you know so it's really the whole business of 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 and is that where personas come from like is that what you mean by one person, like persona? Personas are a good example of a bad thing. I mean, they're bad- A bad example of a good thing. No, they're bad and they're bad. You're saying you're blurring together a whole bunch of, this comes back to, 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? It's just-

Long walks on the beach. 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 I've got like 30% of customers like to eat pizza, you know, or whatever, uh, what I want to know is, uh, when one person is in the situation that I'm designing for, what needs to happen next? You feel that rotation in your mind of like, it's like a 90 degree 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 uh it's a 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 you know so if if i identify that there's a specific person that i can i can kind of be when i'm designing you know and say when i'm in that situation it's not about it's not about their age or their preferences it's about like when like i always use go back to the snicker story it's the perfect example like when when i when i miss a meal and my energy is getting low and i have to get going i have to keep going what's a way that i can quickly refill

my replenish my energy grab a snickers and eat it and i'm done and i'm and i'm and i'm back to what i'm doing that is that that is a that is a that is a thread through time to understand that, right? 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, right? If you're making something that you're going to 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 be and and and you can swirl it around with your tongue and it can take 10 minutes to be finished but that can't happen if you're supposed to just bite it and swallow it and move on right so there's there's design requirements that affect the composition of the ingredients and and and everything from from looking at it that way and or you're in a situation where you're with a buddy who also has the same issue and you need to share one that's why they have this knicker two-pack totally right you know what i mean like the design requirement was this person has this situation in time with other people sometimes and and then he's got that person's gonna share reminds me of a great mitch hedberg joke which is

i like twix unless i'm with four or more people. Because who wants to share? Come on. That's right. Yeah, yeah. Yeah, it was 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. Exactly. So I said yes.

But anyway. Just do my head work all day. No, but then the thing is that- I like the idea of time, though, affecting this, because that does. It's situational. Yeah. It's not my age you can age my gender my attributes it's 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 right yeah and it may be that there are some demographics

that bound this sort of scale of that you know like if if it's if it's too specific of a situation and it's only going to happen to a certain number of people then of course that's relevant to know so there is a place for that for that sort of space-like snapshot of attributes but the thing is that that that what we could call the ensemble view or that sort of like 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 you know it's like how do i answer a question well what what's what's what's the

majority you know and and and it's about making this mental flip of N of one 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. Seems like a design decision needs to be, I mean, you need to have a vision.

And a vision that is an N of one is de facto short-sighted right like there's a myopic like single point in time that you're designing for and it's difficult to then take that perspective and design something that has long you know 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 10 people together and then understand anything in terms of the cause and effect. Right, but the same person over 10 weeks. There's a really great piece of work by this fellow, Ole Peters. He's a there's a really great um piece of of of work by this uh this fellow ole peters he's a friend of mine and uh i i started following his work and he's he's kind of redoing uh economics kind of on a new foundation and he's using a concept called ergodicity from physics

and uh he actually wrote a a paper on it but at first got it kicked off with murray galman who was like he mean he's the guy who discovered the quark so i mean like he's he's in good company you know and uh and the whole notion is that if you if you 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. Sure. And you're going to get the mistaken impression that gambling has a certain, you're going to value the risk at a certain level

based on looking at that average, right? But if you follow an individual gambler what you'll see is that they keep they keep getting they keep going mostly they keep going bust over and over and over again so the story of of what you see when you look 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 So that's when we talk about N of one 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 sort of 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 do they just have access to see it or this kind of a thing. And I was kind of spinning my head, like trying to think through all these different cases and i looked at some data about you know how 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 and blah blah blah look at all this stuff and none of it is giving me any insight at all okay and i'm looking at like 50,000 you know customers all overlaid onto some cool graph right that looks very impressive and i'm

learning nothing and then i think to myself okay what's what's the 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 this the cause and effect of like oh you don't invite everybody on the first day because you don't have anything for like 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 like a superior who you kind of want them to know that you're doing this thing but you're not actually working with them you know what i mean and and then you you you reach a point where you 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 got to bring everybody else in so they can see this thing that's like done that's ready for them to comment on right so i've got like 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's that's maybe gives you a little bit of kind of the intuition behind this this 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 back to the whole percentage to some degree? So it's a wiser, larger number. Exactly. So that's what we do when we do jobs to be done research. We interview 10 people, and each interview is like a 4K movie. You know what I mean? 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. You know what I mean? That whole thread is like a very detailed thing, but it's an N of one. and then we do that thread 10 times and then what we do is after we've done

the individual threads longitudinally now we can cluster to take to to get to an aggregate but the thing is that we we we started longitudinally we started with time and then we aggregate into space so we can say three out of these 10 were all coming at it because of this reason versus these other three were all coming because of this reason so like these three were all new managers who were trying to lead their teams well and they needed to know uh who what was assigned to who and whether they were following up on it in order to fulfill their new management responsibilities right versus this other group of people um felt like they were the 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 what needed to happen next so it's very different you know to say like i know what 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 like put everybody in one place so nothing gets slipped and we all have the same information right so this is the kind of thing that these these higher level clusters come out but the way that you go about this data collection and clustering process, it's 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. I love how 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, like 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. So this is still work in progress, so it's a little bit muddy, but it gave me a few things.

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 purpose of inclusion and transparency. You know what I mean? Like I'm going to give everybody else in the company, because we have this habit at Basecamp that we invite kind of everybody in the company to all the projects. And the whole notion is like, it it's about inclusion it's like we want everyone to be able to know what's going on right but the thing is that um when i look when i looked at the actual thread and i i saw a

contradiction immediately which was that um uh the creator of the, 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. including somebody because you you want them to to feel included which is the kind of social thing you know versus including somebody because like you need 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 you know 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 and that difference is going to manifest in like so let's say i knew that um that one person is is is given access for purpose of inclusion and another person 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 the person who's impacted should maybe get like a daily notice that's like hey here's stuff that happened on projects that you're not directly involved in but impact you like super valuable do you know what i mean like a role thing you said it's access is it is it more like a role like the role they play is different than just any other role they 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 as as very different than than than um allow me in if i'm ever curious so that i don't feel excluded. Very different. Totally different dynamics, right?

So already, that's the first thing that popped out at 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's 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 like a histogram of, you know what I mean? Like what percentage of accounts have this percentage of projects, which 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 their unfolding that's huge right that's huge you know so that that that just threw a whole bunch of data out the window that we might have queried and and interpreted in a certain way just by looking at that one that that that one uh longitudinal n of one so how do you take that kind of thing that kind of learning then and apply it on all your problems? I mean, if it's that revealing, how can you do that in scale?

You still figure 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 want to understand, if you want to build anything, you have to think in terms of,

you have to boil it down to being one person in one situation. You say to myself, what needs to happen next? Right? Anytime you've ever designed a system, you always end up thinking about like, what needs to happen next? What does this function have to return? What's the consumer of this function? Do you know what I mean? Like 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 want to get to your answers faster i think you look at big data like that because you're like how can i tldr this data to get my aha moment and it doesn't work better it's not the way it doesn't you don't have enough information so this is shortcuts this is the highly detailed path and you can you can cluster vast amounts of data this, but no tooling is built to do it this way. None of the tooling is built around this. So it's fascinating. So for example, we did a jobs to be done interview once where we talked to 10 customers and literally only 10,

and we got this massive amount of insight about what people were trying to get out of base camp 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 right and then back up and tell us what this job to be done is and then go back into that because i'm i don't understand that uh yeah yeah so there's um there's a uh there's a a body of work that traces, that I learned from my mentor, Bob Mesta, and 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 Jobs to be Done, the whole notion of it is that um people are are 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 do you know what I mean and 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 and this is where they're struggling and then these are the things that are sort of blocking them and then those become our design requirements so So it's a way of- You're giving them tools to solve their problems, essentially. Yeah, I mean, like us, especially like in the developer world, like we're tool makers. 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 that you needed to make a certain kind of progress. And then what happened and where you're trying to get to is going to to define all those requirements for you and those requirements don't come because you're you're 60 years old or you're 20 years old you know there's going to be some correlation there because of the circumstances you find yourself in but um 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 it's like, I'm not going to get stuck on the side of the road. It's time. I got to finally replace this thing. Do you know what I mean? Like very different. Yeah, different absolutely very different requirements and uh uh everybody who's ever you hear if you talk to people with kids they'll tell you that nobody nobody's nobody when they're

15 says i can't wait until i get to buy a minivan and uh and a lot of a lot of just on the minivan jared oh yeah oh yeah a lot of a lot of people a lot of young couples that we have a lot of you still in the minivan Jared? oh yeah a lot of people a lot of young couples it solves the problems that we have a lot of young couples who have the first kid will say like look we're never getting a minivan

no way right and then as soon as they get the second kid what happens? minivan minivan it's so convenient

because it's getting them in and out of the doors it's those sliding doors it's you know what I mean like there are design requirements that until you're in the job that you don't value yeah right but then when you're in the job all of

a sudden boom like i i need this because of what i'm experiencing so that's um that's the sort of general point of view of the thing and then the way that we actually find jobs so jobs are a um they're an empirical phenomenon they exist out there in 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 and so the way that we we don't like 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 so somebody buys base camp and then my basic assumption is they didn't buy base camp because they rolled the dice today and said what do i do today and the dice came up by base camp

they they bought base camp because something else was going on that needed to change right and and so uh so then we say well what happened right and then you get oh well i i just hired three more people and we had 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 got to find a better way or whatever it is, you know what I mean? And you get this unfolding through time

of like what actually happened to them as a series of cause and effect. And then that's where you get your requirements from. So when I talk about doing those 10 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 then the point was that, to come back, was that if we do that analysis, we can talk to just 10 customers and we can get three or four jobs out of that.

And then the question is, well, how representative are they and then we can do then we can do sort of quote-unquote big data in the sense of uh we can we can we can survey thousands and thousands of people because we know the right questions to ask right so it's it's um a lot of this big data stuff is incredibly powerful if you're trying to do to automate a perceptual task if you're trying to recognize fire hydrants and and and and and sidewalk markings and stuff like that you know what i mean like then ai is going to help you right but if you are trying to figure out kind of 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 right so longitudinal big data is totally different than than what's what's the what's the opposite latitude i guess i don't know i mean you never hear that but you know this uh it's totally different type of data it's deep and big 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 and where was the causality different and 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 you you can you can like we did this we 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 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 sort of weight them in terms of our understanding of the market composition. So that's where you get, you have big data in terms of scale, but the number of dimensions is very, very small. So I think you want really high dimensions

when you're doing this longitudinal stuff. When we do the analysis, we do 10 interviews. And then when we do the clustering, we're actually clustering on something like, usually on the order of like 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, you're here for this. You're asking people like three or four 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. What's interesting, I think, is this aha moment that sort of 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 data set,

but then be able to attract or know the people that have the problem, this same problem or a similar problem. So it's easy to, one, design better product towards 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 is that,

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 we 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 put it, we all run into the same stuff all the time. You know what I mean?

So the people are very different, but the jobs are actually, there's actually an 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. All right, I got a question for you. Are you curious? Because if you're curious, I have a podcast recommendation for you. As you may know, that's one of the best ways to learn about new podcasts is by recommendation. And I might be biased towards this show because I'm a host of this show.

But we produce a show called Brain Science. It's for the curious. It's exploring the human brain to better understand behavior change have a formation mental health and what it means to be human here's a preview of episode 20 titled navigating perfectionism it's not advocating don't seek perfectionism don't seek being perfect it's the opposite of that which is you know where do you find your worth? Maybe even beyond that, how can you be more secure in who you are? You said predominant. What if you can flip that and say, well, the majority of my self-worth is derived from what I perceive as my self-worth versus allowing others to speak into that and change it?

Yeah, look, everybody is wholly entitled to their own opinion of what they like and what they think is good enough or acceptable. But, you know, we're all different. Nobody starts really in the same place. I mean, genes play a role, environment plays a role, opportunities, like there's so many things that each individual, you know, comes to the plate with. So it is a decoupling of saying I can't solely base my self-perception on the feedback from one, just anyone. And two, how do I to some degree create a filter around the feedback I do get from other people? I always give the analogy, not that I can relate with this in any way, but if I were in the grocery store checkout line and the cashier told me about how I was doing as a mom because my kids were losing their cool as toddlers for whatever reason, it's not to say, you know, she couldn't give me feedback. He or she give me feedback about how i'm doing as a mom because my kids are melting down and maybe you know it's irritating or whatever or i'm not being

the sort of meeting the expectation of parenting at that moment but does this person know me all right to keep listening head to changelog.com slash brain science slash 20 that will take you to the episode titled navigating perfectionism where we dig deep into different aspects of perfectionism, how it's adaptive, how it works, and how it just doesn't work at all. Again, ChangeLog.com slash brain science slash 20, or search for brain science in your favorite podcast app and subscribe. We'd love to have you as a listener all right before we go into this last segment you know that we mentioned 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 a show and we're like well we kind of been show? And we were like, well, we kind of been talking. Let's just cut up everything we've just been talking about this 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 one uh 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 base camp or you know kind of matriculating a project was i had a client who built some software that was for financial advisors and it's a way to let financial advisors get to know their clients better and blah, blah, blah. It's basically a survey builder with an email tool. So there's advisors and there's clients. And the advisor would sign up. There's a bunch of stock surveys, things that they recommend. Financial advisors love these questionnaires. They live on them. And their clients don't love them, so it's a weird of stock surveys, things that they recommend. Financial advisors love these questionnaires.

They live on them. And their clients don't love them, so it's a weird dichotomy. But anyways, 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. Maybe 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? Like they sign up as an advisor, and then they have, you sign in, there's a bunch of surveys, there's like an empty list of clients, you know, you can import your clients or whatever. Any guesses on what an advisor might do at that point? No, I'm curious to learn. Curious.

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 like 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 sent themselves one.

Yep. Because they don't want to be embarrassed by trying out this new, you're not going to try out a new tool on your actual client, you're going to try it out on yourself. 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. It's just, 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 like the there's a timeline there totally like people don't just start using a thing if they did then they would just have used it the way it was designed it was designed to be used assuming you've already adopted but there's like this which is obvious in retrospect but like they just started

setting up for themselves and they're like it doesn't work it's like no it totally works you're using it wrong there's a system of of things that the user has to go through as a series of like steps that they have to get through to get to the other side of this thing and there's a it's it's and there's a bunch of functions that they actually have to perform and those map back to the anxieties that they have yes so they're we call it an anxiety in the in the job to be done framework of these four different forces one of them is anxieties and an anxiety is something that you're asking yourself well well, what if this happens? Or what's that going to be?

And you need a mechanism to answer that question for yourself in order to move on to the next step. 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 we there was a there was definitely a lack of uh just real world thinking about how somebody might go through a process of adoption and how answering that anxiety of i don't want to embarrass myself with a tool i'm only testing out in the first place totally so we end up

building a thing where you can just send yourself a survey right away, you know, like log in, hey, try it out on yourself. I mean, it made more sense, but it was almost embarrassing launching. It was kind of a soft launch with these guys, but it was almost embarrassing when we realized we didn't understand how people were actually going to use it when they were test driving. That really comes back to what's exciting about this, be named mental shift, right? Is that when we have that in our minds from the beginning, we find that the first time we start thinking about a problem, we're going to put ourselves into the driver's seat of that person in that situation. And we're not going

to be asking ourselves about their demographics. We not going to be asking ourselves about their demographics. We're going to be asking themselves about what, why am I here and what am I trying to do next? And what am I thinking about? And what, what do I need to get through? And then you're just asking the right questions much earlier. And if you don't know what the questions are, which like I mentioned,

this stuff is empirical. So then we, we do the research and we, which doesn't mean some big gnarly research project which 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 psychology, the brain, cognitive load, stuff like that. You're curious about his curiosity? Yeah, I'm just curious because, I mean, 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. 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 the i mean if you want you can look to the brain to find some some sort of neural correlates of this stuff but but i i don't i don't really look to the brain as the seat of these things um uh i think i think it's much more about the um the the circumstance you know you can you can black box the brain and look at the circumstance and then you get the right variables out.

I mean, because it's a question of what level of abstraction you want to deal with the world on. I think you raise a really good point about this thing about sort of the compassion and empathy. I think we have different things that sort of the compassion and empathy i think we have you know um different uh things that sort of drive us in terms of like what we like to work with you know and like where that

kind of where that moment is where we do the fist pump in our own work you know like what's what's that moment for you where you're like yeah like i i it all clicked together and i like achieved my goal you know and i think that there's a... 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? That moment of like, that moment of like, ah, it did,

it did it. It like the test ran green and it did what it was supposed to do. And like, ah, that's awesome. You know? And that's, that's one orientation.

And then there's another orientation of like, there's, there's a struggle somewhere in a, in a life situation of like, I keep losing this stuff or I, I, I, we're trying to accept donations at our,

at our, at this nonprofit. And like the, every time we try and get people to sign up for a membership, there's like too many steps. And then they kind of like their eyes glaze over and I lose them. And then like, they never follow through.

And you know what I mean? Like these, these sort of, I don't know what you call them they're like the domain specific problems that come up you know I think you can get kind of hooked on solving those kind of things for people um and it's in essence it's not different than getting the gizmo to work when you flip the switch you know 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, you know what I mean? And like where you kind of 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 kind of, but I think that, again, 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, look, regardless, 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. And we're seeing now, there's a huge wave right now where all this behavioral economic stuff is getting thrown out. All this stuff about like, oh yeah, it's just starting, but you're going to see it. all this stuff about like oh yeah it's it's just starting but you're gonna see it all this stuff about like loss aversion and and all these like biases that people have it's all bs it's all bs because the thing was that um these the people

who did this work the behavioral economics people they were starting with with a very artificial fabricated model of how they thought people made decisions you know like 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 you can actually say though the way that people behave is completely rational and and again ola peters has been doing some really fantastic work on this um there's a paper on the name of that area of economic study that you mentioned that your friend is doing um so

the the new field of work that he's doing is called ergodicity economics and it's 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 the so the so-called psychological bias by using a different model a much simpler assumption um and then and actually you get the you get the perfectly consistent results with with the data um using it's a question of using the right model instead of saying that the people are are wrong because they don't they don't they don't match our model it's it's a new area using the right model instead of saying that the people are wrong because they don't match our model. It's a new area that's really blooming right now. And it's going to take a while because the behavioral stuff really penetrated the popular consciousness. So a lot of people now are aware of these things.

But that's just, it was a big wave with also because of this very popular book that Kahneman and Tversky wrote, you know, 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. See, he is into it, but he's not into it.

He's into it enough to know he's not into it. I like it. I don't know the book or the author's names, but I do like listening to the Econ Talk podcast. I love Econ Talk talk man right he's so good that's just what it's like one of my favorite podcasts he's such a fantastic interviewer oh and he's so um i love like i was just listening to an episode a day like yesterday and he i love how he'll just say yeah i don't agree with you totally and it's so great to hear that on a

podcast instead of the echo chamber where everyone is is you know what i mean like vibing on each other's opinions like right you really hear a difference in view but with a great degree of civility and and and it's just it's fantastic i really that's really great yeah i agree not to disagree with you to agree but i do agree i disagree 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 uh econ talk tells me and i don't even listen yeah actually i i would love it if if they would get if they would get ollie peters onto econ talk that would be a great fit um but i don't know that's funny because i was just gonna go search their archives for ergodicity to see if i could listen to something about it because i

don't when i don't have time to read books when when no i'll give you a i'll give you a really good uh short youtube video that gives you a very good introduction to it there's a there's a talk that that ola gave that is like a really great primer and it's only you get it in the first 10 minutes of the video the basic idea and uh it's it's a really nice intro so i'll give you a link for that okay i appreciate it yeah i actually found out um you know uh nassim taleb was on uh was on econ talk and he was he was actually telling russ on the air to that he he has to get ole on so it's like nice yeah hopefully there's some 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 just actually a lot of overlap in the theory aspect of this stuff with what I do. So I have a slightly deeper than armchair relationship with it. Well, yeah. I mean, especially if your designs are intended to make money or solve people's problems or influence people. You know what I mean? Like you at least want to study

human behavior at some point to have some basis. It's funny. You know, I tried to look at economics through that lens early on and there was nothing useful in it because it's all BS. Like the models of economics,

have you ever known a single business person who drew a utility function to make a decision about how to run their business? There's just no relationship between standard economic theory and what actual people who create and act in the economy do. Right. You know? But. Yeah, it's the same reason they can't predict how the economy's going to recover. Right. Because all. Well, they can't predict any of it. Right.

Yeah, I mean, it's, 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 like what how much do people care about this thing and need it when i set a

price on it like there is there is some they've got their fingers on some on the right questions but the models aren't there so so you know like in a way this job to be done stuff is actually a redefinition of what utility is um you know, the utility of something has to do with the job I'm trying to do and the context wrapped around that. So there's, you know, there's a lot of, there's just a lot of interesting stuff brewing, you know, 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. Another, by the way, I'll mention, if on the other side, there's a really accessible book that's fantastic

called The End of Average by Todd Rose. And The End of Average actually touches on all this stuff, but from totally from the other side, from a completely accessible angle. And 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 bunch of people versus following individual pathways and he looks at it in um in medicine and in schooling and in a variety of different situations and it's a it's a very short and very pithy book that also is is about this this sort of mindset shift that we've that we've been circling around for a while that's a really good one how involved are you on Hay?

Is that something you want to talk about? Are you off the Hay project? Is that a different team? Yeah, so I actually was never really involved with Hay very much, except for a few sort of key points. Hay 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. And so I didn't really have anything to contribute because they were a hundred percent driving based on what they already were seeing in their own use case of what they wanted, you know? Makes sense. And then I did play a role where there were a couple points where um it wasn't really clear how to distill it like you know like when you've got a million ideas for a product and then but you have to boil it down to like these are the three main things that it does right um there was a point like that kind of early on where where they pulled me in and we had a conversation that kind of helped frame what the main function of Hay 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 sort of 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, right? It's been great to catch up. So I know you 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 kind of 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 slash shape up and right at the top underneath the buttons to read the book, you'll see a link that says, join the newsletter. And if you join that, we won't send you anything other than news about, about formats. So when the print edition is available, then we're also going to do an ebook version and you'll get, you'll get notified when those are out.

I just subscribed, so I will be notified and I can't wait. Awesome. Ryan, thank you so much for your time. It's been great catching up. Hey, thanks a lot guys. It's been fun. Wow, what a marathon of a show. Ryan is awesome. Thank you, Ryan, for sharing all your wisdom and thank you to you listening to this.

If you're listening to this right now, if you've stuck around this long, you're a diehard right now, if you've stuck around this long, you're a diehard fan. You're a true fan. We thank you. And a fan like you might want to help us out by sharing this show with a friend or by giving us a rating or review in Apple Podcasts.

That's such a huge help, believe it or not. The best way for podcasts to get discovered is by telling your friends and doing ratings and reviews. That's the best way to do it. And of course, we always invite you to comment on this show. pop up in your show notes and click discuss on change law news. We'd love to hear from you. Huge thanks to our partners who get it fastly Linode and roll bar. And as always, we love these beats from break master cylinder. So give it up for break master cylinder. And we have a master feed of all of our podcasts, all of our podcasts in one single feed.

It couldn't be easier. Head to changelog.com slash master or search for ChangeLog Master in your favorite podcast app. You'll find us. Thanks again for tuning in. We'll see you next week. hey thanks guys it's uh it's i i appreciate how like you how far out you let me go you know yeah dude oh that's fun we enjoy that i mean we sometimes having no real direction is direction you know i mean like if you just know i'm gonna go west we'll get somewhere totally the best conversations aren't you know on rails that being said some of our shows are like specifically like you're gonna do this this is this and other shows were like hey let's let's let it be a conversation and really let it flow the way one would naturally flow and i don't know i enjoy listening to those kind of 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 yeah while you're mowing the lawn or whatever you know totally if i'm trying to sell more snickers man i'm gonna hang out where they are all hungry okay because hungry and need to do something else and they got no energy so i'm gonna find out that's by the way that's that's where snickers got that campaign you're not you when you're hungry it was from doing this research this exact this exact process is how and before they did this research they were actually um in really bad shape in terms of sales and uh they did a massive turnaround in the 90s um by doing this when i was thinking about wow i remember that one but the one i do remember is gonna be

here for a while grab a snickers i like that one. But the one I do remember is, gonna be here for a while? Grab a Snickers. I like that one. Because yeah, like when you're stuck somewhere and you're like, gosh, darn it. Wow. The advertising though for it is like, because you can sort of like 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. And you didn't reach for stickers, but you're thinking, well, the next time I now have a new tool to reach for. Yeah. Or the football 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 for you. Oh, yes. So you 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 you know like who wants to go and pack their own boxes and and and fill load their own car with a whole bunch of boxes and stuff like that like uh compared to like a premium furniture store this idea that you would like roll around a warehouse and like fill your

own cart like why would that be a good user experience you know but when you look at the trade-offs that they're making ikea the the main job to be done of Ikea is get this new place furnished today. I've got this one weekend, and I've got to get this place set up, and I've got to 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 got to get it all done today. And how is it all going to fit in your car if it's not flat packed? You know? And how are you going to buy it all at once unless it's cheap? So like it needs to all be really cheap. So there needs to be like this cost factor of you're willing to

make the trade-off of loading your own cart because you get to get the whole, you get to get all the bookshelves and the desk and the kitchen and everything all set up like today and you're going to be able to do it all in one shot you know it all it all holds together and one more thing and you can take the whole family well yeah that's the other thing somebody from fun for them there's well and and why is there why is there a cafe because it takes all day to buy everything for a new apartment yeah it literally 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 everything, there's a deep logic to the whole thing based on the job.