0:00

Welcome to rework a podcast by 37 signals about

0:02

the better way to work and run your business

0:05

we recently recorded rework live where

0:07

we took our conversation to youtube

0:09

to share some current updates from

0:12

37 signals and answer some listener

0:14

questions live here's that recording enjoy

0:18

okay i think that we are live

0:20

in the youtube i'm kimberly the host

0:22

of the rework podcast i'm

0:24

joined by jason creed and david heinemann

0:26

hansen co-founder of 37 signals i think

0:28

that we're live on youtube if

0:30

we are and you can hear us and see

0:33

us let us know in the chat thanks for

0:35

being here we know we have lots of people

0:37

joining us live we're trying something new we've never

0:39

done this before we usually record the podcast and

0:41

then push it out later but we

0:43

thought why not just hop on live and answer

0:45

some live questions we know that you guys are

0:48

here to hear from jason david so i won't

0:50

spend a lot of time talking we'll get right

0:52

to them and i think first we'll start with

0:55

a question we already saw pop up on twitter which

0:57

is you guys just launched the hey calendar what about

1:00

once when are we gonna hear about

1:02

once jason do you want to take that one yeah

1:04

i'll start i mean we're late so uh

1:06

we made a we

1:08

made a public promise essentially that we

1:10

would have this done or have the first

1:12

version first product from the once family out

1:14

by the end of 2023 now this

1:18

is more of a patting us on the back but not

1:20

really true it's true but not completely

1:23

we did release it to some customers early

1:25

at the end of last year so some

1:28

people have it there's like i think six

1:30

or something like that or eight so it is

1:32

out but not really um it's

1:35

a good example frankly of of never you

1:37

know never making public promises because you

1:39

just shoot yourself in the foot more often than

1:41

not like with the hey calendar we launched january

1:43

2nd although with the apple thing we had to

1:46

push that off a little bit but like we

1:48

were ready to go on january 2nd as we

1:50

said we would be all the way back in

1:52

march of 2023 we predicted we'd

1:54

be ready and we were but we didn't promise

1:56

that uh to the public we just

1:58

said early to And it turned

2:02

out to be true. We didn't make a public promise. It was

2:04

specific with once we did and we didn't hit it. And so

2:06

it feels kind of bad. That said,

2:09

we are very close. In fact, today

2:12

or tomorrow actually gonna launch to a

2:14

significantly larger batch of people. It

2:17

will not be public for everybody, but

2:20

it'll be, let's say wider beta and people will be able

2:22

to pay for it. The

2:24

first part again is gonna be, it's

2:27

called Campfire. It's a group chat tool,

2:29

similar to Slack or Teams, but significantly

2:31

simpler. Kind of the

2:33

way these tools used to be before

2:35

they became bloated, complicated, convoluted, massive

2:38

messes in a lot of ways. So

2:41

I expect a week or two of that

2:43

beta stuff happening before it's probably out for

2:45

wider release. So anyway, just

2:47

always a reminder that, and by

2:50

the way, the reason why it's bad to announce

2:52

release dates publicly is because

2:54

they're always far in the future and they always

2:56

sound easy to do. It's

2:58

very easy to say yes about something later and

3:01

we have to continue to learn our lesson and we learned it again

3:03

here. So I don't know. David, you wanna add anything on that? Yeah,

3:06

I think we've made this mistake several times over

3:08

the last 20 years. And every single time we

3:10

make the mistake, we say never again, never again.

3:12

And then a couple of years pass by, I'm

3:14

like, this seems so easily doable to hit this

3:16

target. I think one of the

3:18

things that added some complication here was we were trying

3:20

to do two launches at once. We have never ever

3:23

attempted anything as foolish as that. You are

3:25

a small company. So we had Hey Calendar,

3:28

which is a major new product that we've

3:30

worked on for a whole year happening

3:33

at the same time because we're a bigger, more

3:35

capable company as we were developing once. And it

3:37

felt really exciting. Hey, we have two separate teams.

3:39

We can do both things at the same time.

3:42

But there's just a gravity

3:44

of attention that goes into any

3:46

major public launch. And like

3:48

Jason and I can't split ourselves. The rest of

3:50

the team can't split ourselves when it comes to

3:52

a launch. So when we pushed out Hey Calendar,

3:55

even though I've mostly been working on the once

3:58

side of the product fence for a while. I

4:00

couldn't just sit over there and wave, oh,

4:03

looks good, have fun. I mean, the Apple

4:05

thing added a fair amount of complication to

4:07

it, and I got drawn into that. But

4:09

even if that hadn't been the case, a

4:11

launch for a company

4:13

of our size is always going to be

4:16

an all-encompassing event. And we had

4:18

put both of these expectations a little bit on

4:20

top of each other. And then

4:22

the other part was that one actually influenced

4:24

the other. So already

4:27

towards the end of the year, we

4:29

were starting to get excited about this

4:31

PWA concept, Progressive Web Applications. We were

4:34

not going to build native applications for

4:36

once. First, that started out actually being,

4:38

do you know what, our native

4:41

teams are fully engaged with, hey, calendar, hey, calendar is

4:43

the most important thing we're working on right now. We

4:45

can't also do native app for once. Then it turned

4:47

into a little bit of like, do you know what,

4:49

this is actually a little bit of a feature. Once

4:52

it's an installable product, you install it by

4:54

yourself. If we have to have native applications,

4:56

we have to also run servers, which kind

4:58

of becomes a service then. The whole point

5:00

of once is that there's no service. This

5:03

is a set of products. You install them

5:05

yourself. You operate them yourself. This is why

5:07

I think people will be pleasantly surprised when

5:09

we announce pricing, that it's not

5:11

as high as I think most people think,

5:14

because we're conceiving of this as products. As

5:16

boxes on a shelf, you take it off

5:18

the shelf and it's mainly on

5:20

you. Like there'll be a 1-800 number. I

5:23

mean, not really, it's an email. But imagine

5:25

on 1-800 number at the back of some

5:27

envelope. Like how many times did you call

5:30

Sony when you bought a Walkman? I

5:32

don't know anyone who ever called Sony about buying a Walkman, because

5:34

that was a product. And you were just like, that's on

5:36

you and you got to do it. So all

5:39

of these things came together. And then

5:41

of course, the accelerant with Apple being

5:43

just absolutely vindictive SOBs

5:46

when it came to our own

5:48

native apps. And now this Epic

5:51

Games verdict just really lit

5:53

a fire under the intention

5:55

of pushing PWAs as far as we

5:58

could. So it kind of raised the question. We

6:00

were trying to hit a bit. Then we thought

6:02

at first, you know what, let's just push this out. It's going to

6:05

be fine. And now we're like, yeah, we'd like

6:07

it to be a little better than fine. We'd

6:09

like it to be quite good, the

6:11

PWA story, because

6:14

we have to shine a light

6:16

on an alternative path for all

6:18

this App Store gatekeeper nonsense. And

6:21

no, PWAs are not going to be as good

6:23

in all the ways, but I

6:25

also don't feel like they've fully gotten a shot,

6:28

right? PWA has a concept, this idea that we

6:30

could just use web apps, especially on mobile. That's

6:32

really where the whole question is. That

6:35

that feels unresolved, even though the term

6:37

has been around for five years, because

6:39

it wasn't mainstream viable before. Now we

6:41

have Apple actually supporting PWAs. I mean,

6:44

trying to deduce like why and how

6:46

much and what they'll change in the

6:48

future. You can go crazy, but you

6:50

can also just accept what's there right

6:52

now. You can do a web

6:54

app that you can install on your phone.

6:57

It gets push notifications and it's actually kind

6:59

of quite good. Perfect. No,

7:02

just as good as peak fidelity on a

7:04

native app. No, but for a lot of

7:06

apps, including this

7:09

campfire product, it's quite good. And

7:11

we'd like to put our best foot forward when it comes

7:13

to this. We're also trying to validate sort of

7:16

a category on two different levels, right? There's

7:18

the PWAs. Want

7:20

to validate that that's a viable path and

7:22

hopefully inspire others to invest in optimizing

7:25

that as much as we can. And

7:28

then we're also trying to validate this idea

7:30

of installable commercial software again.

7:33

That used to be a thing 20 years ago,

7:35

you'd buy a CD, whatever, you'd set it up

7:38

on your own machine, then it fell

7:40

out of favor because of SaaS. Although

7:43

it kind of continued all the long

7:45

alongside, like what does it have? The

7:47

internet runs on WordPress. Every

7:50

one of those installations was an installable app

7:52

kind of thing, but that's open source. We're

7:55

trying to do commercial software in this

7:57

form. So yeah, we just took a little.

8:00

longer to get it just right and I think we're

8:02

almost there. Okay, let me ask a quick

8:04

question and then also if you guys have questions put them in

8:06

the chat. I can see them. I will make sure that we

8:08

get Jason and David to answer them. David and Jason, tell

8:11

us with the ONCE products you said we're starting with Campfire.

8:13

Why do you guys pick that one as the first one

8:15

to start with? So one of

8:17

the premises behind ONCE is that besides

8:19

it being installable software and not subscription

8:21

based is to look at categories of

8:23

products that exist that are

8:26

widely adopted, that everybody already knows

8:28

how to use but are

8:30

still being priced like luxury items. And

8:33

group chat is something that has permeated

8:35

pretty much every business or every organization.

8:38

Yeah, some of these tools do some more things

8:41

but fundamentally the core of it is like I

8:43

need to talk to my co-workers in real time

8:45

by chatting, right? And

8:48

the thing is that this has been around now

8:50

for 15 years. It

8:52

will actually longer if you go back to IRC or whatever

8:54

but it's been around for a long time yet

8:57

it's still priced as if it's brand new. And

8:59

so we asked in fact on Twitter how much

9:01

do you pay for Slack and the bills

9:04

that we're coming back were like thousands of

9:06

months, some people tens of thousands a month,

9:08

even just hundreds a month, even

9:10

a hundred a month. And we're like that's

9:13

just obscene. It's obscene to spend that

9:15

kind of money on essentially a

9:18

tool to chat with your co-workers when

9:20

things like WhatsApp or Signal are free.

9:23

Like what is it about Slack

9:25

or Teams that makes it worth thousands a month? So we're

9:27

like, okay, we know how to build this. We actually built

9:29

this way back in 2006. It was

9:31

actually called Campfire originally. We know how to make

9:33

a simple thing. We haven't already in Basecamp. This

9:37

would be a perfect category where we don't have

9:39

to explain how to use it. It's a known

9:41

entity. You can actually build a

9:43

UI with almost no words in it. It's that

9:45

clear. It's like transcript box to bottom where

9:48

you type list of rooms or channels on

9:50

the side, very well known. And

9:52

we can price this and it can be hosted

9:54

on someone else's box. It

9:56

doesn't need to require email or any

9:59

complicated interactions. with outside systems

10:01

essentially. It's very self-contained and

10:04

it can be radically cheaper and

10:06

just as good at the 80% level.

10:09

So we're not going to have video conferencing in it.

10:11

It's not going to have audio conferencing in it for

10:13

V1 or any of that stuff. It's just basic simple

10:15

group chat. But it just felt

10:17

like the right thing to do, the right

10:19

category to start in and the right place

10:21

to prove this idea. And so that's essentially

10:24

why we chose that. There's

10:26

just so many angles of this too that are

10:29

exciting to me. Not only this idea that we're

10:31

taking something old that was good, like

10:34

the installable software and we're bringing it

10:36

into the present, I was going to

10:38

say the future, but it really is

10:40

the present. This fact that the fundamental

10:42

of change. There's a reason why everyone

10:44

moved to SaaS in the early mid

10:46

2000s. Because it was such a pain

10:48

in the ass to install and update

10:50

and keep in sync if you

10:53

were running your own servers. That was just

10:56

very poor ergonomics. Now the

10:58

fundamental underlying technologies have improved leaps and

11:00

bounds. This whole thing of containerization where

11:02

you can take an entire system, not

11:04

just a piece of software, but the

11:06

entire system, put it in a

11:08

box that is turnkey. You

11:11

just turn the thing on and then it

11:13

just runs as it was designed. It's very

11:15

different from how it used to be to

11:17

distribute server-based software. You'd have to worry about

11:19

what machine are you installing it on? Did

11:21

you have the right things? Can you get

11:23

it wet? Can you get it out of

11:25

shape? All of those questions have

11:28

largely been solved. It's

11:30

one of those things that the fundamental

11:32

improvement or advancement with containerization, I mean

11:34

at this point it's like whatever, 10

11:36

years old. We haven't

11:38

fully digested what the possibilities are.

11:40

I just find those things so

11:42

fascinating. Where you have a

11:45

fundamental technology that is

11:47

done, but people haven't still caught

11:49

up with what does that make

11:51

possible. This makes it possible to

11:54

distribute these installable apps without having

11:56

to have service calls, without having

11:59

to send someone out and look at

12:01

your server without having to get access to your

12:03

server. All these things that used to be true

12:05

if you wanted to distribute that kind of software,

12:07

boom, gone. The

12:10

complexity has just been compressed down to

12:13

a thin sliver. We just add our

12:15

little special sauce on top to make

12:17

it even easier. In fact, I'm about

12:19

to record an installed video. We just

12:21

went through on a walkthrough, Jason and

12:23

I and a couple of people from

12:25

the team yesterday, like what does

12:27

it take to set up this kind

12:29

of installable software on your own host? We just

12:31

used DigitalOcean. I've been testing with Hasner. If you

12:33

use any of those Cloud VMs, you can do

12:35

the same thing on your own server. If you

12:37

have an actual office,

12:39

I would totally recommend that someone just put

12:41

like a little box in the corner and

12:44

you can run chat on your internal network.

12:46

But it's so easy to set up. It's literally

12:49

you turn on a fresh box,

12:51

you paste in one command and

12:54

it's going to run through its thing. You're up

12:56

and running with auto update and all these other

12:58

things. Just a lot of

13:01

technology enabling things. It's not about the technology.

13:03

I don't think there's a lot of people

13:06

who will actually care. Oh,

13:08

it runs Docker underneath that. Whatever. Can I do the

13:11

chat thing? Can you save me like $10,000 a month

13:13

on this thing? Can

13:16

we own the data? This is something

13:18

that's also huge. I mean, I just spent three

13:20

years in Copenhagen living there. The

13:23

way the GDPR, this

13:25

privacy framework, has just

13:28

infiltrated in some senses good and

13:30

other senses. I don't know about

13:32

that, but infiltrated European business mentality.

13:34

Like how do you store data?

13:36

Where can you keep it? I

13:39

think these kinds of software is just like

13:41

tailor made for the moment. I

13:43

can imagine a Danish

13:46

public school installing this campfire

13:48

tool and running it like that. Inconceivable

13:50

that they would at this point in

13:53

the GDPR's advancement would use a tool

13:55

from us as a SaaS product as

13:57

an American company. I

14:00

just find that just really exciting. But I

14:03

think what's important to say here is all this is speculative. Jason

14:05

is so excited about a new product category. We

14:07

want to push it out there. We've thought a

14:10

lot about it. We put our hearts, sweat and

14:12

soul into it. But until

14:14

people actually buy, we don't know

14:16

what we got. Actually, I see

14:18

some things from, I want to respond to a couple of

14:20

quick things. We move on. So Justin

14:23

is asking, uh, will we eat our

14:25

own dog food with one chat? You already use

14:27

chat and basically, so we've converted the entire company

14:29

over to using campfire chat

14:31

for now. Um, and,

14:34

uh, so we're not really chatting in base camp or chatting

14:36

in this. We have, you have to dog food your own

14:38

product. You have to use your own thing as you're building

14:40

it to really start to understand what it's missing, what it's

14:43

good at, what it's not. So we've been doing that. Um,

14:45

and you're also, it says that you're surprised to see

14:48

that we're, we're doing chat considering we've been semi anti

14:50

chat for many years. We're not

14:52

against chat. We're against chat

14:54

as a primary method of communication.

14:57

It's a terrible default method

15:00

for all communication across the company. And so

15:02

most companies who've switched to something like Slack

15:04

all in or teams, like

15:06

it sucks, you're bombarded with, with,

15:08

with notifications all day. You're bouncing

15:10

between dozens of different channels. It's

15:13

chaotic. We don't support that at all,

15:15

but as a tool, it's a good thing to have

15:17

in the tool belt. We do go to chat when

15:19

we need to discuss something or hash something out real

15:21

time. It's very good for social interactions and just kind

15:23

of screwing around, shooting the shit kind of

15:25

thing. Um, and it's also really

15:27

nice for really small teams occasionally to make some

15:30

quick progress. So it's a

15:32

tool just like in base camp. It's one

15:34

of eight different tools we offer within a

15:36

project. It's not the primary method. So we

15:38

primarily talk long form, but we do go

15:41

to chat occasionally. So part of what's

15:43

interesting about this whole thing is that,

15:45

you know, while this is technically

15:47

could be a Slack replacement for many

15:49

companies, I actually see it as also

15:52

sort of Slack adjacent or teams adjacent.

15:55

You can imagine many of the people in the company

15:57

still using Slack, but you set up a separate corner

15:59

for just. executive team or just a

16:01

smaller team who wants to keep things completely

16:03

separate. Like a separate

16:05

space, a private meeting room that's really truly

16:07

private and that only six people have been

16:10

invited to this thing. It's

16:12

so low cost that it's like

16:14

a no brainer to have also.

16:17

So this idea of also software that

16:19

you already have something primarily for this,

16:21

but you want another similar version

16:23

also for a different use case. The other

16:25

thing is that we are giving

16:27

the code away. So not only

16:29

do you get this thing, but you get to see

16:32

how this product was built all the way through, which

16:34

is something you never ever get with commercial software. So

16:37

you might just buy it simply because you're curious about how

16:39

it was built, how a team like us put this product

16:41

together. And again, the price is going

16:43

to be, it's less than a conference ticket in most cases.

16:45

So like it becomes another

16:47

no brainer purchase to learn and to have

16:49

a team dissect this stuff and look through

16:52

it. So anyway, that's just a couple of quick

16:54

things I wanted to get to. On that note, Kevin

16:56

asked, who do you see as the target demo

16:58

initially for campfire? You've talked about that a little

17:00

bit, but maybe Jason, who isn't the target audience

17:02

for this new product? I would

17:05

say this is a really interesting open question,

17:07

to be honest. I'm not really entirely sure

17:09

who's going to, like, is

17:12

it a company size? Is

17:14

it a type of company? There

17:17

is some basic technical knowledge required, very

17:19

low, but some to kind of get

17:21

this going. If you're using Slack

17:23

and it's free, why would you pay for anything at

17:25

all? Like there's some of that. But

17:28

I think that there's a couple things. There's a privacy

17:30

aspect of it. There's a control on your own data aspect

17:32

of it. There's just the ability to

17:34

look at the product all the way through and

17:36

know exactly what it's doing, knowing that your data

17:39

is not being sent to someone else's servers and

17:41

someone else's location. There's the

17:43

ability to potentially customize this because you get the code and

17:45

you can mess around with it to some degree. There's

17:48

this idea of having a separate, segregated

17:50

place for certain discussions that are separate

17:52

from the rest. Companies do this all

17:54

the time. They have, like, file

17:57

system and there's only certain people who have certain

17:59

access to specific folder like that's

18:02

and you know, of course, you can do that

18:04

and other tools, but to actually thoroughly separate them

18:06

is even safer. But I think we're

18:08

gonna see a lot of mid-size companies jump into this.

18:10

I think we're gonna see a lot of small teams

18:12

who are product development teams who are curious about how

18:14

this works by this. I think we're gonna see a

18:17

lot of large companies like with do with Basecamp, the

18:19

whole company doesn't use it. But

18:21

a team within it uses it. They want their own

18:23

thing. They want their own place.

18:25

They want their own rules that they want to set

18:27

up. So I think we'll see it in

18:30

a lot of different places. And I think

18:32

ultimately, if we can get the pricing right in

18:34

other markets, we're gonna see this adopted all over the

18:36

world in markets where, you know,

18:38

typical SaaS software is way too expensive

18:41

to get going. So what we'll have to

18:43

see, I'm very curious. We typically, to be honest, we

18:46

don't think about markets so much ahead

18:49

of time for anything we build. We think

18:51

like, what do we want to make for ourselves? And

18:54

let's put it out there and then we'll find out what the market has

18:56

to say about it. So with

18:58

Campfire, everyone's loading it themselves using their

19:00

own servers. This kind of answers Chris's questions.

19:02

Maybe you guys can address that. Will

19:04

Campfire have a mechanism for preserving messages for

19:07

legal purposes? We don't have the data.

19:09

In the sense that you

19:12

have the data, you have the database,

19:14

the system is built for you to

19:16

be able to take backups of that

19:18

database. There are no sort of enterprise

19:21

retention controls in the traditional sense that

19:23

you would with a Slack or something.

19:26

But in some ways, it's not

19:28

needed in the same way because it's literally

19:30

your installation. Like it's literally running on your

19:32

stuff, either your physical server or

19:34

a cloud VM that you control. You have

19:37

direct access to the database. We've built a

19:39

really nice system in where you can take

19:41

backups of not just the database, but all

19:43

the files that's been uploaded. So say, for

19:45

example, you have a preservation request, you're in

19:47

a lawsuit and they say, hey, you can't

19:49

anything in the past three months, you got

19:51

to just store, right? You can do it

19:53

back up and take that back up

19:55

and put it somewhere safe. Just

19:57

that you are in compliance with that subpoena or whatever.

20:00

whatever it is. So,

20:02

yeah, I think in that sense, it's quite

20:04

well set up, but it's not the same

20:06

way. You really have to shift your mindset

20:09

a little bit when you go from multi-tenancy,

20:11

which is what systems like Slack and Basecamp

20:13

is when someone else runs on your behalf,

20:15

to single-tenancy where you own the whole thing.

20:18

Like you're not renting. You

20:20

are buying a product here, and

20:22

it's yours. This is the other

20:24

thing here. You're not making a license

20:26

agreement with you that we can revoke your

20:28

right to run the software. There's a license

20:30

agreement on what you can do with the

20:33

code. Like, it's still copyrighted. We trademark the

20:35

name. And so you can't just buy our

20:37

code and then give it away for free

20:39

or distribute it or whatever, but it is

20:42

yours to run the way you see fit.

20:45

You don't have to get any of our updates.

20:47

You can buy, can't file once, continue to run

20:49

it on your services, use please, and you can

20:51

run it in the next thousand years.

20:54

I mean, I'm making a sort of

20:56

broad proclamation here. But the software is

20:58

yours. The software is open source. I

21:00

guarantee, well, I shouldn't say guarantee, who

21:03

knows? Civilization is around in a few

21:05

hundred years. But if it is, if

21:07

civilization is still around, there will be

21:10

people who are capable of running this,

21:12

which is absolutely not true for commercial

21:14

SaaS companies like Slack or even

21:16

like Basecamp, right? Like you can't

21:19

make declarations about whether this is

21:21

going to be around in a hundred years or

21:23

two hundred years. Now, is this actually a practical

21:25

concern? I don't know. Not so

21:27

much, but there's a philosophical attraction to this

21:29

that really appeals to me. One of the

21:31

reasons it does is because I've gotten really

21:33

into retro gaming. There's these

21:35

emulators that allow me to

21:37

play the video games I first played

21:39

when I was like five years old.

21:41

It's incredible. You can emulate a Commodore

21:43

64, which was the

21:46

first computer I really had exposure to.

21:48

All those games on a modern sort

21:50

of handheld gaming device, were you actually

21:52

playing that real software? That

21:56

to me is magic. We have a

21:58

history here of computers. and software

22:00

that we should be cherishing. I do

22:02

worry a little bit that the

22:05

sassification of everything destroys that. This

22:07

is one of the other reasons

22:09

I'm so thrilled that we still

22:11

run silly things like Tadao is,

22:13

this free service we made like 18

22:15

years ago. Because it's trying to give

22:18

friends to this idea that software should have

22:20

a legacy and a history. All the major

22:23

material things that I truly enjoy,

22:25

whether it's watches or cars or

22:27

cameras, they all have these long

22:29

legacies and you can take

22:32

a watch. Actually, I mean, this

22:34

is a watch from I think 1968. It

22:37

is from before I was born. I can

22:39

wear it on my wrist and it tells

22:41

time. Like that's amazing. Software

22:44

should be more like that. I think

22:46

with this kind of software, we're trying to put our

22:49

chips in and say like, all right, it's going to

22:51

be that. I think that's just

22:53

fun. Okay. I want to

22:55

go- You're addressed. I'm sorry, Kimberly. Go ahead. No, no. I

22:58

was going to go to SHAPE UP. So if you want to stay on

23:00

the- One more thing about- Let's do one more thing about

23:02

once. First, let's come to SHAPE UP. I saw, David, this

23:04

is really more of a question for you. It says like,

23:06

if you're giving the code away, does that make it open

23:08

source? Can people modify it? How are

23:10

we thinking about allowing people to mess with the

23:12

code and see the code? Yeah, this is

23:15

where I think the parallels are so great too,

23:17

to physical stuff. This watch or

23:19

you take a Leica camera M3, or

23:22

you take a Corvette from 1968. Those

23:25

are your things. Like, I

23:28

didn't sign a end user agreement

23:30

with Rolex, or General

23:33

Motors, or Leica, to be able to

23:35

own those things and do whatever the

23:37

hell I please with those things. Now,

23:39

the question is whether you can. If

23:42

you buy a mechanical watch from

23:45

the sixties, do you know what?

23:47

You can take it to any independent service provider.

23:49

They may be good, they may be bad, but they

23:51

can work on it. They can open the case and

23:53

they can rinse it out and clean it out, whatever.

23:55

You can take your Leica M3 to an independent shop

23:57

and they can fix it. You can take your car.

24:00

If you're good enough, interested enough in this stuff, you

24:02

can learn it yourself. You can change the, I

24:04

don't know, corporate or battery,

24:06

whatever. Do you know what

24:08

you can't do if you buy a goddamn Tesla? Do anything.

24:12

Now, I love Tesla. So, I'm

24:14

not taking a dig at them

24:16

here. I'm saying there's been a shift here

24:18

where everything has become software and all software

24:20

has become closed when it comes to commercial

24:22

systems. So, this is

24:25

not that. This is a Mustang 68 that

24:27

you can buy. And if you can teach yourself

24:30

how to operate it and maintain it and change

24:32

it, you can. You can install a different stock

24:34

and do all those things. That's

24:36

not the same as open source as people

24:38

traditionally understand it. People understand open source in

24:40

the same way. We give away Ruby on

24:43

Rails, right? You can distribute it. You

24:45

can build it into something else. You can build a product

24:47

with it. You can sell that product. There's a lot of

24:49

rights that come with that kind of open source. We're

24:52

keeping some of those rights. So, this

24:54

is somewhere in the in-between land. This

24:56

is commercial software. The source

24:58

code is trademarked. Sorry,

25:02

copyrighted. You can't just take it and

25:04

distribute it. Just like you can't just buy a book, take

25:06

photocopies of all the pages, and then hand

25:09

that book to someone else. Now, you know

25:11

what? We have some limitations here to ensure

25:13

that commerce endures. But

25:15

you can still get into the machine room.

25:18

You can change it. You can adapt it,

25:20

modify it, do whatever the hell you want.

25:24

And I think that's what... It's really an

25:26

intersection of two things I care about. I

25:28

care about commercially viable software where companies can

25:30

actually make profits and pay employees and all

25:32

those other things. And then I also care

25:34

about open source. And this exists somewhere, I

25:37

don't know, in the middle. Sorry,

25:39

Jumba. No, no, no. There's a couple of... Since

25:41

people are asking about one stuff since we're on

25:43

the topic, let me just knock out a couple

25:45

of quick ones. Nick, how do you order the

25:48

economics? How are you going to charge for it

25:50

again if you're going to update it? So

25:53

basically, it would seem to work like traditional software has

25:55

always worked. Every major version. So if you have 1.0

25:57

and 1.1 and 1.2... and

26:00

1.3. These are all included for free,

26:02

free updates. If we ever launch a

26:04

2.0 or like a massive redo or

26:06

a massive upgrade, we will sell that

26:08

again as an optional upgrade. That's

26:11

how that'll work. Also, we're going to do

26:13

what I think we're going to guarantee three years of

26:15

security updates regardless of what version you're on. So we

26:17

will do that. Which let me just

26:19

take one point in that because I've gotten some feedback

26:21

on that too. Oh, okay. So if I install my

26:23

own software, like, how am I even going to get

26:25

updates? We built all that in.

26:28

So actually, this is something we did recently. When

26:30

we started out, it was like a manual process. If

26:32

you wanted to get an update, you'd go in and

26:34

update yourself. Now we build an auto updater, which is

26:36

not like something new. Your

26:39

Mac has an auto updater. It's not SaaS.

26:41

Your Mac is not SaaS. It'll pull an

26:43

update from Apple, or your computer will ask

26:45

like once a day, oh, Apple, is there

26:47

any new updates here? We've done the same

26:49

thing. So when you install this campfire through

26:51

the once command, it'll set up an auto

26:53

updater. Every night, I think it's at

26:56

2am in the morning, the system will ask our servers,

26:58

hey, is there any update? And it will auto apply.

27:00

You can turn that off. Not everyone wants auto updates.

27:02

But if you want the auto updates, it's going to

27:04

be on by default, and it's going to be super

27:06

duper easy. Okay, another one

27:09

question. Will you try to have

27:11

similar products of once products play

27:13

together? Are they completely separate? Are they going to?

27:15

Don't know, don't care. Not thinking about that

27:17

right now. Yeah, there's a lot of, I

27:19

saw some other questions about it. It will

27:21

not do so many things. It will not

27:23

do almost everything. Let's do a

27:25

few things. Each one of these tools will do

27:28

a few things really well. What

27:30

we're really aiming for here are

27:32

high quality generics. If

27:35

you think about like what is the canonical

27:37

version of a group chat? It's

27:39

a transcript, it's a place to talk.

27:41

It's a list of rooms, maybe some

27:44

direct messages. It's like that. That is

27:46

what this is. It is not more

27:48

than that. It's not more sophisticated than

27:50

that intentionally. This is like the core

27:53

nugget, the 80 or maybe 90% of

27:56

what these tools really stand for.

27:59

And then all the others. stuff around it is not

28:01

part of it. So these are

28:03

radically simplified, straightforward versions of

28:07

popular product categories that

28:09

we've just stripped down. And

28:11

that's why they're just, you know, let's call it a few

28:13

hundred bucks once. I

28:15

think this is one of the things Jason and

28:17

I were talking about yesterday. Like, I've been so

28:20

excited about like the prospect, the new distribution forms,

28:22

everything we're bringing back and I mean, I think

28:24

it's fair to say we've been hyping that. I

28:26

mean, I've certainly been hyping that and we need

28:29

to sort of take down the expectations like two

28:31

levels from like what is the actual software underneath?

28:33

Because if you have the expectation that this is

28:35

like exactly the same as Slack with all the

28:37

features, bells and whistles that Slack does just massively

28:40

cheaper and you get to own it and we

28:42

build it all in like the amount of time

28:44

we did. I mean, I'm sorry, but

28:46

that's delusional. Like, that's just not

28:48

how things work. You can't

28:51

get all of it plus like 500 times

28:53

extra. So this is how it

28:55

always is when we make new products when

28:57

hey, email launched, right? It included a ton

28:59

of really novel, interesting things. And then there

29:01

was a bunch of baseline stuff that like

29:03

wasn't there on day one. Now,

29:05

some of that baseline stuff still isn't there.

29:08

We've covered the majority of it, but some

29:10

of it isn't there. We're not trying to

29:12

replicate everything that single thing that Gmail does.

29:14

I think there's like 500 different items or

29:17

configuration points and Slack has grown into like

29:19

a Gmail like monster in that regard to

29:21

Jason and I a few weeks back went

29:23

through like the sign up process for Slack

29:25

and was like, holy shit, like I don't remember

29:27

it just being this

29:30

much stuff. And you can tell me, I mean,

29:32

that's not a critique per se, like every

29:35

single little checkbox that it has in

29:37

its 500 million configuration screens like is

29:40

there because it helped make a sale

29:42

to some enterprise the organization somewhere. That's

29:44

their business model. Totally fine. Great. Actually,

29:46

that should exist. It should be good.

29:49

We're making something else. And I think it

29:51

connects to this idea of like, that

29:53

watch I held up 1968 to

29:56

have something endure for like

29:58

not just two years. for 10

30:00

years, for 50 years. You

30:03

actually kind of want it simple. I think

30:05

that's the recipe behind the

30:08

magic of a Leica camera from 1954 that still

30:10

works. Like a

30:12

Corvette from 1968, you

30:14

can still make run because they're actually quite

30:16

simple products. I

30:19

do not think that my Tesla Model S is

30:21

going to run in 50 years. That's

30:24

just unlikely. There

30:26

are so highly complicated systems built with

30:28

computers and software that it just seems

30:30

like, you know what, this is a

30:32

more of a disposable item. Again,

30:35

that doesn't mean it's bad. It means it's

30:37

actually good for a lot of things. We get a lot of progress out

30:39

of that. But it also means there

30:41

should exist a category of software that's not

30:43

that. That is more like trying

30:45

to be a Leica M3, more like trying to be a

30:47

68 Corvette, more like a Rolex

30:50

GMT from 1972. We're

30:53

trying to make that. Okay, last one's

30:55

question before we go to shape up. I doubt it.

30:58

This one is, how do you distinguish products

31:00

suitable and not suitable for the ONCE model?

31:02

That's from Nick who's live with us. The

31:05

way I think about it is, can you boil

31:07

this down to a few things and be done?

31:11

For example, people have been asking for, like,

31:13

can we do a CRM, a

31:15

ONCE CRM? Like, I'm

31:17

not so sure because CRM requires a

31:19

lot of integrations with email and some

31:22

other sophisticated external systems. There's

31:25

a lot to that that is not as

31:27

simple as, like, literally group

31:30

chat. It's obscene that anyone pays

31:32

more than 50 bucks

31:34

a month for group. It's just obscene. Like,

31:37

it's a transcript in a box where you type.

31:40

That is all it is. That

31:43

is it. I know there's other things

31:45

it does like threading. You

31:47

don't need any of that. You don't. It's

31:49

just like, can we find ideas when we have a

31:52

handful of them that are

31:54

so simple in their concept, conceptually

31:56

simple, that we can deliver a

31:58

very high quality, simple version. Another

32:00

example of this, which we might do next,

32:02

I don't know, is Kanban. The

32:04

concept of Kanban, columns and tickets

32:07

and moving call tickets between columns,

32:09

that is 99% of what Kanban

32:11

is. Simple,

32:14

conceptually simple. You

32:17

can squint and draw it

32:20

and cover all the bases. I think this is another

32:22

way I've thought about it. It's like, if I could

32:24

sketch the UI and cover 95% of the whole product

32:27

with a single sketch with eight

32:30

lines, that's the one's product.

32:33

Kanban is like that, chat is like that, there's a

32:35

number of other things like that. Things

32:37

that people already know how to use, already understand that

32:40

are simple concepts that you can do on paper. You

32:43

can make a Kanban board for your office by

32:46

using this tape on your wall

32:48

and post it notes. That's Kanban, right?

32:52

You can do that digitally, of course. It does need

32:54

to do all the things that something like Trello does

32:56

and all the other things that other

32:58

Kanban systems do. What's the simplest version?

33:00

Is there one that's attainable very quickly that we

33:02

could build in a few months? Absolutely. That's sort

33:05

of the bar for us. I

33:07

think it's good to contrast this with

33:09

what doesn't fall in that category, for

33:11

example. Hey is a perfect

33:13

example. Hey is an email

33:16

service, not an

33:18

email client. Running an email service

33:20

today is actually kind

33:22

of jokingly, depressingly

33:24

difficult. Ensuring deliverability

33:26

of email has turned into

33:28

a freaking PhD project.

33:33

I'm trying to remember all the standards that you

33:35

have to keep in your head, DKIM, DISS and

33:38

SC. I can't

33:40

even keep it in my head on an

33:42

operating basis. That's how complicated

33:44

it is. It's not a good system to try

33:46

to run yourself. It used to be, I used

33:49

to run my own mail server, back in the

33:51

late 90s, I think it was. I'd run my

33:53

own mail server. Lots of people did. But today,

33:56

you really have to be a

33:58

very dedicated hobbyist to attempt to running

34:00

your own email service, if you care whether

34:02

your emails reach the recipients. So that's the

34:04

kind of service that I think, in

34:07

the word actually, service. Anything

34:09

that's a service where someone has to

34:12

tend to the operations of this thing

34:14

on a running, ongoing basis, otherwise it

34:16

falls apart, it's a poor fit

34:18

for this. Now, there are people who tried. I actually

34:20

bought like a physical product. I forget what it was

34:22

called, but someone did a physical product that was a

34:25

mail server in a box. And

34:27

it was just, it was complicated. It was not

34:29

a single sketch. It was not actually set up,

34:31

even though it actually came as a physical thing.

34:33

I'm like, I don't think this

34:35

is a good fit for it. And that's the other

34:37

important part of this. When we talk about ones, we're

34:39

not saying all SaaS needs to

34:41

go away. Every SaaS product needs to

34:43

be a installable product. That

34:46

is unrealistic. And in fact, bad.

34:48

There are lots of services that are best

34:50

of services. Email is a great example of

34:52

that. Anything that requires a bunch of integrations

34:56

or updates or continuous

34:58

refinement doesn't really fit this

35:01

model all that well. I

35:03

love that we're recording this live. You guys

35:05

can actually see what happens. It's me just

35:07

trying to not interrupt them, basically. It's how

35:09

it goes. Oh, here comes it. No, quick.

35:11

Here's a question that I actually a little

35:13

off, I thought was a great one. Jason,

35:15

you used to do lots of customer support

35:17

work, which would have helped you stay in

35:19

the loop with existing and new customers. Now

35:21

that you delegate the work, how do you

35:23

maintain your customer muscles? I'm

35:26

a little bit more involved in new

35:28

product development than maintaining existing products these

35:30

days. So because

35:33

there are no new customers for new products that

35:35

we don't have yet, it's a little bit different.

35:37

It's more about gut intuition, what do we want

35:39

to build for ourselves? But

35:41

we have someone named Brian, for example, Brian's our head

35:43

of strategy. He's keeping track of

35:45

all the things that are on customers' minds. He's

35:48

doing a lot of the shaping work for Basecamp

35:50

and continuing to improve Basecamp. So he's very much

35:53

in touch and

35:56

in the weeds there. And if I was doing that, then

35:58

I'd be in the weeds there as well. since

36:00

I'm more on the leading edge of things that

36:02

we're doing right now, like the Hey! Calendar, of

36:04

course, we had to request for Calendar in Hey!,

36:06

but like the thing we built was not what

36:08

people told us to build. That's sort of

36:10

my focus. So it's a little bit different these days. Although

36:13

I will say that when we do launch a new product,

36:15

as we just did, we step into the

36:19

river of customer feedback. I

36:21

mean, both Jason and I have fielded

36:24

absolutely hundreds of emails from customers giving

36:26

us feedback on Hey! Calendar and

36:28

whether that feature requests, bug reports, or

36:30

what they'd like to see, or just

36:32

appreciation for the fact that they found the

36:34

product so likable, all that

36:37

stuff. Like we get the firehose

36:39

sort of occasionally, but yeah,

36:41

I think at some point, I

36:43

think we get, I mean, many hundreds of emails a

36:45

day on customer support. Gone are

36:47

the day where Jason could just answer them all

36:50

by himself, which he did. And I think the

36:52

first three years, I think, I think Jason was

36:54

doing 160 emails. A

36:57

day on customer support while also running

36:59

everything else. And just for sense of

37:01

scale, what we asked or

37:03

what we benchmarked our customer support team

37:06

is 50 to 60 tickets a day.

37:08

So Jason was working three customer support

37:10

jobs while also being CEO and running

37:12

things in the early days. Like, yeah,

37:15

good times. And we walked by the way,

37:17

uphill, uphill, both directions. And it was always

37:19

snowing and we were bare feet. And I

37:22

had a snow machine indoors just to make

37:24

sure of the, but the thing is, is

37:26

like, and I would recommend every founder or

37:28

whatever, anyone making something new for the first

37:30

time does that. You must do that. You

37:33

want to step into the firehose. You,

37:36

but after you launch the

37:38

thing. So I would not go ask people what they

37:40

want. I would, I would build something, then you put

37:43

it out there, then you step into the firehose and

37:45

you learn. There's no better way to learn than that.

37:47

So all right. Okay.

37:50

I've been saying shape ups for a while now because

37:52

some people mentioned it on Twitter. And

37:54

then Parker, I do see you. I haven't

37:56

forgotten about you. The question is, can you

37:58

explain use of shape up? when building

38:01

new product lines? Yes, so

38:03

I was just on a podcast, Hackers

38:06

Incorporated with Adam Wotham yesterday,

38:08

two years ago, when that launched. And

38:11

he asked me about how we built Hey Calendar, and I

38:13

talked all about it. And then there was this one part

38:16

in there where I'm like, well, we don't really follow all

38:18

the traditional shape-up methodologies when

38:20

building a new product. And

38:22

that caught a few people's eyes or attention. They're like,

38:24

gotcha, gotcha. I knew you guys didn't use shape-up. I

38:27

know you invented it, but you don't use it. We

38:30

do use it. What

38:32

we've discovered, though, and this is a constant

38:35

process discovery and evolution. This whole system

38:37

evolved over 20 years. Which

38:40

are now six weeks, used to be three months. And

38:42

before that, we didn't have cycles. So this is an

38:44

evolution. Any

38:47

process that's stuck is dead. Like

38:50

Latin as a language is dead because it doesn't

38:52

change. Things that don't change are

38:54

dead. This process continues to change. What

38:56

we've discovered is that for new product

38:58

development, while we stack up

39:01

work back to back to back to back like

39:03

you would in a cycle, the cycles

39:05

are a little bit more fluid to some degree.

39:08

We don't shape everything ahead of time. Some

39:10

stuff that's especially small is just sort of

39:12

done on the fly. But

39:14

what we don't do is we don't let things take

39:16

as long as they want. So that's like also

39:20

consistently shape-up. Shape-up has an appetite, maximum

39:22

six weeks. We're not working on one

39:24

feature for eight months this way either.

39:26

There are limits. We

39:29

don't have cool downs typically during the new

39:31

product development process where we do with existing

39:33

product development. So typically we do

39:35

six weeks and then a two-week cool

39:37

down and then six weeks. That's what we do on

39:40

existing products. For this we go back to back

39:42

to back to back to back. It's a little bit more of a

39:44

constant jog without

39:46

rest. We're not sprinting because you can't do that for

39:48

months and months and months. But we do that maybe

39:50

a little bit more towards the end. But

39:52

it's a little bit more chaotic, a little bit

39:54

more on the fly, a little bit more feeling

39:56

things out because we're going to be using this thing as

39:58

we're building it. We don't... really know what

40:00

we're making yet. And you can't

40:02

be so rigid ahead of time to know what

40:04

you're going to do over the next year when

40:07

you're exploring something new. But

40:09

there are time boxes, there are limits.

40:11

There is this urgency not to spend too

40:13

much time on something. We want to make

40:15

the thing that we're using. And

40:17

we want to move on for things. We want to finish things

40:19

up and move on. Sometimes you leave something sort of half done,

40:22

you know, you're gonna get back to it, but you also know

40:24

you got to move things on. So

40:26

it's an evolution. It's a different context. It's

40:28

a slightly different variation. And we should update

40:30

the book and update the website and talk

40:32

more about our latest discoveries and how

40:34

to pull this off for new product development. I

40:37

think one thing I've realized is that where

40:40

Shapr3D really helps us at this stage of

40:42

the company is it allows a delegation

40:46

of decision making power on

40:48

an interval where Jason and I don't have to be

40:50

involved on like a day to day or weekly basis.

40:53

So with Brian, for example, shaping

40:56

most of the pitches, taking a lot of

40:58

input from customers and feedback, what we otherwise

41:00

want to do, he can like go off

41:02

and do that work for several weeks, maybe

41:04

he'll sort of bob with Jason a couple

41:07

of times. And then like every cycle, we

41:09

can look at what's on the menu.

41:12

And when you look at it in that

41:14

way, you end up with a certain course

41:16

decision, your decision making power, we cannot make

41:18

decisions in that forum, unlike an hour by

41:20

hour basis, or even a day by day

41:23

basis, the minimum block we can actually operate

41:25

with is a week, and more

41:27

likely it's two weeks than most projects that get

41:29

shaped, they have like a two week block. That's

41:32

fine. When you're evolving an existing product,

41:34

and you can set a couple things

41:37

to go when you're doing R&D, that's

41:39

inherently explorative, you don't

41:41

even know what you want to build, right? Because

41:43

you don't know exactly the shape of

41:45

the product itself, you have to be

41:47

working on a day to day basis. And

41:49

the decision making power to

41:51

change direction should be embedded in

41:53

the team. So you don't have

41:55

this delegation in the same way

41:57

with both hey calendar and with

42:00

with once, Jason and I have

42:02

been in it, him

42:04

on the calendar side, at least on the design part

42:06

of it, and I've been on

42:08

the technical side with once, like really in it

42:10

all the time to constantly like, all right, we

42:13

hit a dead wall here, let's change direction, let's

42:15

go over here. So you're operating almost like a

42:17

different scale, like if you think frog view versus

42:19

bird side view, that the

42:21

more you get up into the level of, I

42:24

hate the fucking word, but stakeholders,

42:26

like people who want to see an outcome

42:28

of something, but they're not involved in the

42:30

day to day of it, shape up becomes

42:33

more and more important, more and more critical

42:35

that you have the shaping and you have

42:37

the repeating ways of doing

42:39

it. But I'll be perfectly honest, like

42:41

if I was starting a new company tomorrow, and we

42:44

were four people, we would

42:46

not use any process, barely.

42:49

I mean, we wouldn't even have we wouldn't have kickoffs,

42:51

we wouldn't have heartbeats, because it would be no one

42:53

to communicate with. The smaller

42:55

you are, and the more isolated that

42:57

group is from the rest of an

42:59

organization, the less methodology, the less

43:01

process you need, and the more

43:04

liberating that is, this is why I think a

43:06

lot of people, a lot of entrepreneurs look back

43:08

wistfully on the early days, oh, remember when we

43:10

were just five people, like, there wasn't

43:12

any of the complexity? Yeah, because the scale

43:14

was so small. It's just, it isn't hard

43:17

to organize more people, it just isn't. Organizing

43:20

a company of like, whatever, 72,

43:23

75, that's a more difficult problem, let

43:25

alone organizing company of a few hundred

43:27

or a few thousand or 10s of

43:29

thousands, right? They're just different scales. And

43:31

if there's one thing I think we've

43:33

been consistent in saying is you have

43:35

to pick tools that are appropriate for

43:37

the scale you're at. This is

43:40

why I'm so adamant that microservices

43:42

is a terrible idea for most

43:44

small teams because these are techniques

43:47

built by and formed

43:49

in huge organizations. What works

43:51

for Amazon at that level?

43:53

It's not what's going to work for you. So I

43:56

think ShapeUp has a little bit of the same thing. I don't actually

43:58

think most people go to the same level. looking for

44:00

shape up until they run into

44:02

process pains. You're not going to

44:05

have process pains with four people. You're going to have

44:07

process pains maybe 10, 12. Now you're going

44:09

to have to have multiple people and they have to have

44:11

an eye on five different things. They can't be involved in

44:13

everything all the time. Shape ups makes

44:15

a ton of sense. Do you know how

44:18

big the ones team was? We had, yeah,

44:20

how big was the ones team? For the

44:22

longest time, two developers, one designer, Jason, me.

44:25

That's five. You don't need any process with

44:27

five people. Okay, here's another

44:29

shape up question before we move on to just

44:31

the random questions. How do you handle betting on

44:33

smaller projects like say three weeks?

44:35

During the six weeks, the engineers focus on

44:37

two shorter projects rather than a big one.

44:39

Just a general shape up question for us

44:41

here. Yeah, so before a cycle starts,

44:44

we set up the work that we're going to do

44:46

and not the tasks, but

44:48

the big ideas. And

44:50

we say, we're going to pick, for

44:52

this example, I'm going to say we're going to

44:54

pick five things to do. Two

44:56

of these things are going to be full cycle

44:58

projects. They're going to take the whole time. They're

45:01

bigger things. I'll give you

45:03

an example from Hey Calendar, if

45:05

we're doing this in shape up. Habit

45:08

tracking and time tracking are both full cycle

45:10

projects. They're going to take the full six

45:12

weeks. But there's a bunch of smaller

45:14

things that are going to take a week or two

45:16

to do. And so we set the appetites

45:18

for each one of these projects. And

45:21

usually, we have a team work on a

45:25

big thing, a teamwork and a big thing. And then

45:27

one team might work on four smaller things in a

45:29

given cycle. So there's like the small

45:31

batch team, which will do a bunch of

45:33

things, and the big batch teams, which will

45:35

do one thing. And that's kind of how

45:37

that comes together. And like, the

45:40

other important thing here is that this isn't really,

45:42

we're not aiming

45:44

for rigidity here. There is a framework

45:46

and a concept that's supposed to help

45:48

guide things and prevent the worst

45:50

parts of human nature from taking hold, like

45:53

just giving things an unlimited amount of time

45:55

and perfectionism and all that stuff. So there's

45:57

discipline here that's built into the system, but

45:59

there's all also flexibility. So

46:02

if someone needs to jump over from one project to another,

46:04

they need help, it's of course, the answer is of course.

46:07

It's all within reason. But

46:09

that's typically how we would assign the work

46:11

out. And then again, once the work is

46:13

assigned, the work that's assigned is the big

46:15

idea. The actual bits that need to get

46:18

done are defined by the team doing the

46:20

work. There's no architect or taskmaster

46:22

or scrum master or whatever making

46:24

all the individual tasks and tickets

46:27

for each person. The people

46:29

doing the work make their own work. That's how that

46:31

whole thing works. And

46:33

I think it's key here to contrast

46:35

that with, in my

46:37

opinion, the ways agile, big A

46:40

agile, mythologies went astray, because they

46:43

absolutely did try to codify way

46:45

too many things in too

46:47

high a level of rigidity, ironically,

46:49

given the fact that it's called agile, but everything's

46:52

called agile this day. No one is gonna say,

46:54

I'm not agile, right? Everyone say they're agile about

46:56

something. And then they present

46:58

a very rigid definition of what

47:01

that agility actually looks like. And

47:04

it's far away from the agile manifesto, which

47:06

was this idea of

47:08

it's still online, if you Google agile

47:11

manifesto, you can see these

47:13

ideas of people or processes, for example,

47:15

like if something's gonna bend or give, we're

47:17

gonna give it to people, we're not going

47:19

to stay rigid in the process. And this

47:21

is where the context setting is so important

47:23

that you can't just take even shape

47:26

up. I don't think you can't

47:28

just apply shape up as a whole to an

47:30

entire organization of 100,000 people without making

47:33

serious modifications. I also

47:35

don't think you can apply it as we wrote the

47:37

original book to a team of four people. It

47:40

fits somewhere within the processes starting to hurt.

47:42

And we're not a mega company yet. So I

47:44

don't know if I was going to say something,

47:46

I'd say from 10 people to maybe 500. Something

47:51

in there is the sweet spot for

47:53

it. The further you get away from

47:55

that, either on the small side or

47:57

on the big side, you're gonna have

47:59

to make modifications, you're gonna have to

48:01

make a change. changes to it. And

48:03

that should not be seen as a

48:05

refutation of the ideas that are in

48:07

there. You can totally take a concept

48:09

of, for example, budgets over estimates, right?

48:11

I think that is a universally applicable

48:13

concept that goes directly to Jason says,

48:15

like the worst parts of human nature.

48:17

If you go with estimates, humans suck

48:19

at estimation. Even if they're foreign people, they will still suck

48:21

at estimation. So you can take that idea and go like,

48:23

yeah, you know what, we're going to apply that here. We're

48:26

going to set up some appetites. We're going to do that.

48:28

We're not going to have the whole thing. We're not going

48:30

to do the formal pitches and

48:32

they're not going to be at that level. But we're going to

48:34

think about estimates. Okay, I'm

48:36

going to move on to this question about

48:38

new products from Julian. When you start something

48:41

new, how much time do you spend on

48:43

it before saying it's a good idea or

48:45

not? So if we're talking about a

48:47

brand new product, it's typically, it depends.

48:49

I guess like, if we're, for example, this once

48:51

campfire, like we've already built chat a few times.

48:53

So we kind of knew what this was going

48:55

to be. But let's say that the hey calendar,

48:58

let's take that as a, I always want

49:00

to get practical. So by the way, if

49:02

we're talking too high level,

49:05

tell us in the chat, I want

49:07

to get practical and real. Okay. So

49:11

hey, calendar, we spent a few months, typically

49:14

no more than a couple months max

49:17

exploring in the early days, like is there something

49:19

here, we knew we were going to build a

49:21

calendar, we decided we were going to do

49:23

that. But what was it going to

49:25

look like? Well, it wasn't gonna look like

49:28

a traditional calendar. But what does that mean? So there

49:30

could be a million other ways to do it. So we spent

49:32

a couple months playing, it's

49:34

really play. And then at

49:37

some point, like I think it was early March, basically,

49:39

we started this, I think in January, I don't know,

49:41

something like that early March, we're like,

49:43

okay, we kind of have

49:45

a direction here. This doesn't mean

49:47

everything's finalized, basically, nothing's finalized. But

49:49

we've landed on a few interesting

49:52

ideas that form enough of a foundation

49:54

from which we can then build the walls and build

49:56

the roof and build another layer and all the whole

49:58

thing. I'd say

50:00

a couple months of exploration and play

50:02

before settling in. If you're spending more

50:05

time than that, I'm granted,

50:07

look, there's always exceptions. If

50:09

you're building an electric car from scratch and

50:11

you've never done that before, for example, you spend more

50:13

than a few months. Software,

50:16

conceptually, a couple months should get you far enough to

50:18

go, if there's something here or there's something not. That's

50:21

kind of how we basically do it because otherwise, you

50:24

will keep going. And if you feel like

50:26

you need to explore every possible avenue before you

50:28

decide to commit to something, you're

50:30

never going to get this thing done. So you've

50:32

got to go on faith at some point after you've

50:34

determined that there's enough of foundation here on which to

50:36

build future this. Okay,

50:39

I'm going to go to a question that

50:41

came earlier from Victor, which is, would your

50:43

business structure be any different if you guys

50:45

made products that you didn't use internally? We've

50:47

talked about it all the time. We are

50:49

our customers. We use Basecamp. We

50:51

use Hayes. Would the business look different if that works in the

50:53

case? I wouldn't be here. I

50:57

don't know. I'm not

50:59

interested in building products for imaginary

51:02

people. And to be honest, I know it

51:04

sounds really... I don't know

51:06

what it sounds like, but I don't mean

51:08

it in a negative way, really. It just means I

51:10

don't want to imagine someone else's problems. I've got my

51:13

own problems. It's hard enough for me to understand my

51:15

own problems. I'd rather solve my own

51:17

problems that I'm close to, that I can really understand

51:19

if this is a solution or not. I know what

51:21

my own struggles truly are. I can

51:23

just decide to build something. If the struggle

51:26

goes away, we've nailed it. At

51:28

some level, once you've got something out there

51:30

in the world, you do build for other people. But

51:33

initially, we build for us. For example,

51:36

there is no amount of money someone could pay us right now

51:38

to build a patient

51:40

scheduling software for a dental practice. It's

51:43

just not going to happen. We don't care.

51:46

You can pay us a billion dollars. I just don't

51:48

care. Not going to do it. It's not worth

51:50

doing. So, we're going to find things that

51:52

we know how to do that we struggle with, that

51:54

we want. And that's the kind

51:56

of business we build. I think if you build another kind of

51:59

business where you're doing things... things, you're imagining other

52:01

people's struggles and doing it for other people, you don't

52:03

really know where to stop. You're probably gonna have a

52:05

lot of sales people because you're gonna

52:07

need to sell this thing. You

52:09

can't just make something that's gonna be really good on

52:12

its own. And

52:14

it just doesn't sound interesting to me. I'm not really interested in

52:16

spending my time. I like to make tools

52:19

that I'm gonna use. So that's my missive

52:21

on that. I'm completely on board

52:24

with that too. You could not motivate me. It's

52:26

not even that you couldn't pay me. Yeah, of

52:28

course. It makes me to do that. And

52:31

I just know this is one of the reasons I was

52:33

such a terrible employee. Because whenever I

52:35

had to work on something for other people that

52:37

I didn't care about, I literally could not make

52:39

myself do it. So there's

52:41

that. And then the other part is,

52:43

holy shit, I'm glad not everyone feels this way. We

52:46

need someone to make the dental

52:48

practice booking software. And

52:51

this is where Jason and I are

52:53

these oddities. And we're all odd and

52:55

weird in our own different ways. We

52:57

just have accepted our own oddities and

52:59

built a business to facilitate those oddities

53:01

not getting terribly in the way. But

53:03

we need other people to do this.

53:06

Jason and I, terrible folks to ask for

53:08

advice on that because we literally could not even

53:10

motivate ourselves to barely think about it. You need

53:13

to talk to someone who's done that, who builds

53:15

software for other people. And there are lots of

53:17

people who do this. And many

53:19

of them do it well. And I have

53:21

tremendous respect for the fact that they are

53:23

able to do this. And I think the world is a better

53:25

place because they do it, not

53:28

Jason and I. Can I

53:30

take Eric and Ilan, both have a

53:32

similar question. That was what I was going to cue

53:34

up for you. So you're good. It's a pricing

53:36

question. So it's about pricing because we've

53:38

long had a policy that we don't increase

53:41

prices on existing customers. And in fact, for

53:43

the past 10 plus

53:45

years, we've changed prices a bunch

53:48

only on new customers. So we have a new pricing

53:50

model we experiment with. We put that on the website.

53:52

Anyone signing up will pay the new price existing customers

53:54

continue to pay their old price. And

53:57

we've done this for basically the tires distance

53:59

of the company. early on, we had a

54:01

little bit of price changes with a

54:03

couple of different products. But it's been a

54:05

long time. In fact, some customers that we still have,

54:07

we've had for 20 years, they're still paying

54:10

the exact same price they paid 20 years

54:12

ago. However, just

54:14

recently, we decided that

54:16

it's finally time, our

54:18

costs have gone up, as everyone's costs have gone up.

54:22

And we've instituted a price

54:24

increase on some

54:26

legacy products, some existing products. It's

54:30

about 20%, roughly, give or take

54:33

on existing customers, we've given them about 90 days notice.

54:38

And the existing prices on the current site

54:40

will not change moving forward. But we are

54:42

bringing people a bit more up to date.

54:45

Basically, our cost structure has just changed. We have a lot more

54:47

employees than we used to have. We've

54:49

saved a lot of money in the cloud, but our

54:51

payroll has gone up significantly. As everyone knows, payrolls have

54:53

gone up significantly for a variety of reasons. There's inflation,

54:55

there's a whole bunch of other things. Costs

54:58

are up. And at some

55:00

point, in order to maintain the

55:02

kind of business we want to run, we have to pass some of that

55:05

on. So we

55:07

decided, again, after a long, long period

55:09

of time, that over 10 to 20 years,

55:11

only to raise prices once,

55:13

about 20% seemed very fair,

55:16

very reasonable, and necessary for

55:18

us to continue the business the way we want

55:20

to run it. So that's how

55:22

we did that. What to me is kind

55:24

of fun to look back upon is we launched Space Camp 2004. We

55:27

still had some customers paying essentially those

55:29

2004 prices. In

55:33

2004, we were paying developers, including myself and

55:35

I think Jason as well. I think it was $42,000

55:37

or $45,000 a year. That

55:41

was the salaries. Do you know how much

55:43

programmer you get these days for $42,000?

55:47

You don't get a whole person. You

55:49

get some slice of a person somewhere. I don't know if

55:51

you want a leg or you want a head or an

55:53

arm. You're not going to get a whole programmer, at

55:56

least not at the cost basis that we're looking

55:58

at in our jurisdiction. if you want to call it that.

56:01

So if you compare that, like

56:03

what is the average salary for Silicon

56:07

Valley type levels?

56:10

It's not 20% that's gone up in 2004. It is many

56:12

times that. So

56:16

at some point, it just seems like out of sync.

56:19

Because to maintain those legacy products,

56:22

actually, sorry, let me restate. To

56:24

maintain those legacy services, that's the

56:26

key point here. We

56:29

need to continue to pay talented people

56:31

to work on it. That's

56:33

to make sure that those things are updated, is that

56:35

they're still running, or everything that goes into

56:37

offering a service sort of

56:40

requires human input. And

56:42

that is the biggest cost that we have

56:44

in our company. So even for example, as

56:46

Jason said, we've saved some money on the

56:49

cloud, very happy about that. In the grand

56:51

scheme of like payroll, it's substantial, but payroll

56:53

is so much larger than whatever those statements were.

56:55

So I also think it's just one of those

56:57

things where I

57:00

hate getting the drip drip. So

57:03

I use ADT for my security

57:05

system, whatever, they freaking send me

57:07

a well, our prices have gone

57:09

up like two, three times

57:12

a year. And it's always like, oh,

57:14

we're raising our prices 3.7 to 4%.

57:16

And I always go like, that

57:19

sounds bullshit. Like if you have that many different

57:21

models, like something is just fishy here, I'd

57:23

rather just go like, you know what, we're going to do

57:25

it rarely. But then we're going to do like a chunk.

57:27

20% first time in 20 years.

57:31

Do you know what, I don't find that

57:33

a reasonably. And that's so funny. Like what

57:35

is reasonable? It is such an individual conception.

57:39

And I've had the same thing.

57:41

I just had this thing with Disney+. So I

57:44

was on a Disney Plus plan that was $99 a year. I don't know,

57:46

maybe that was an introductory

57:48

pricing or whatever. And then I

57:50

get this email saying, hey, cool,

57:53

it's going to be 139 now. So

57:56

a 40% increase. And I just went no, can

57:59

I afford? $140 for Disney Push. Yes,

58:02

I can afford that, but I don't want to.

58:05

And I was trying to look at myself

58:07

in third person, like, why am I being

58:09

petty about that increase? It just felt

58:11

like it didn't feel fair. And I

58:13

think this is the key aspect of pricing

58:16

that you should internalize is this sense of

58:18

fairness. Now, you're not going to make anything

58:20

fair for everyone. We got some pointed

58:23

feedback on the 20% people saying that's not

58:25

fair. But broadly, the feedback

58:27

was, you know what, sounds about right.

58:30

And I think that you've got to know

58:32

that you're dealing with human emotions, you're

58:35

dealing with a sense of fairness or unfairness.

58:37

How often can you do this? How much

58:39

can you do this? And

58:41

you really have to respect those things

58:43

or otherwise you you could get yourself

58:45

in trouble. I mean, we

58:49

we root over this for some time. It wasn't just like,

58:51

all right, that's what it is. Exactly. Because we hadn't done

58:53

it for a long time. But I think I mean, given

58:55

the feedback, it seems like it was sort

58:58

of well received. But proof is always in the

59:00

pudding. And the pudding is

59:02

that the price increase will hit the first

59:04

invoices, I think, February 1st. So

59:06

that's when we'll see the moment of truth. Are people going to

59:08

pay? OK, last question that we're going

59:11

to take before we wrap it up, we've been with you

59:13

almost an hour is about A.I. What

59:16

are your thoughts on generative A.I. any plans for

59:18

doing something? And this is a scam for any

59:20

of our products. I

59:22

think A.I. is the most exciting,

59:24

interesting development in technology

59:27

that I've probably ever seen. And I

59:29

include the Internet in that, which is

59:31

saying something. So I'm hugely bullish on the

59:34

future of A.I. I think it's amazing. At

59:37

the same time, I don't feel like I

59:39

have to be the first in the pool

59:41

swimming the hardest, because

59:43

if you've paid any attention to startups

59:45

doing A.I. Stuff

59:47

over the last 18 months,

59:50

you've seen that like two or

59:52

three generations have already been steamrolled. You

59:55

think, oh, I came up with this new

59:57

idea and then the open A.I. steamroller just.

1:00:00

rolls right over you, you're no longer a thing,

1:00:02

you're a feature in their setup. Most

1:00:04

everyone right now, at least, they're

1:00:07

not doing AI. They're doing

1:00:09

API AI. That's different. You're not

1:00:11

doing fundamental research that's giving you

1:00:14

a lasting advantage here. You're

1:00:17

using the API of OpenAI or some of

1:00:19

the other tools, which, great. I'm not saying

1:00:21

that's bad. I'm just saying that, to

1:00:23

me, it seems too early. I'm

1:00:26

not actually an early adopter. Or

1:00:29

maybe I'm an early adopter. I forget how the chart

1:00:31

goes. There's a segment of people who jump in on

1:00:33

something as soon as it comes out. I

1:00:35

don't like to do that. I like to give it five minutes.

1:00:38

Can the landscape settle just

1:00:40

somewhat? So instead, we don't spend a bunch

1:00:42

of time looking into something and then it just goes and

1:00:45

then it eats all that work and swallows

1:00:48

it up inside the OpenAI machine. I don't

1:00:50

want to waste time doing that. I

1:00:53

don't think it's clear at all where AI

1:00:55

is going to land. Even a year from now,

1:00:58

is AI going to end up in a

1:01:00

place where we're even using graphical interfaces? Is

1:01:03

everything just going to be spoken? Where is

1:01:05

this actually going to be? I

1:01:09

sit with this paradox in my head.

1:01:11

I think this is the most exciting

1:01:13

thing that's happening in tech. Also, I

1:01:15

don't mind being a spectator right now.

1:01:17

Eventually, it will settle to whatever degree

1:01:20

it settles and we will go

1:01:22

right in on it. We've done a handful of

1:01:24

experiments internally. Like the one

1:01:26

everyone was excited about for a hot minute

1:01:28

was like, oh, it can summarize your boring

1:01:30

emails. So we tried

1:01:33

that. I was like, yeah, okay, cool-ish.

1:01:36

That's not the part of the Institute of AI that

1:01:38

actually gets me excited is that we take shitty writing

1:01:40

and turn it into another shitty version of the writing.

1:01:44

That doesn't get me fired up. A lot of

1:01:46

the other things do, especially around media. I'm

1:01:48

not sure it's clear where

1:01:50

we land yet, but it hopefully

1:01:53

will be in like whatever a year. Hopefully

1:01:55

not. Maybe this says it's exciting for

1:01:57

another year or two or three and we just go like.

1:02:00

I don't know what's happening. Is anyone even going

1:02:02

to work tomorrow? Or software developers

1:02:04

are all out of a job. I think

1:02:06

we've never had that amount of uncertainty in

1:02:08

plain sight. There's always been uncertainty about

1:02:11

what's new technology going to do, but it

1:02:13

always felt like something you had to dig

1:02:15

for, even the internet. I mean,

1:02:17

both Jason and I were there, like

1:02:19

95, when the internet started

1:02:21

taking off. And you have to kind of dig. Not

1:02:24

everyone understood that the internet was going to be what

1:02:26

it is. I

1:02:28

think everyone understands today that AI is

1:02:30

going to be a major shift, but

1:02:33

we don't know exactly what. Okay,

1:02:37

well, I think that is the perfect way to

1:02:39

end. Before we wrap it up, I have two

1:02:42

requests. One, if you were just coming to our

1:02:44

YouTube channel for the first time ever, please follow

1:02:46

us. That's 37signals. I know we

1:02:48

are putting this live on YouTube, but we have

1:02:50

a channel that we have videos that come out

1:02:52

all the time. So make sure to give us

1:02:54

a like and follow there. And

1:02:56

let us know in the chat my second request. What

1:02:59

was that, David? Smash the like

1:03:01

button, ring the bell. Do

1:03:04

it on YouTube and then like get all the way up on

1:03:06

the camera. You

1:03:09

guys know what to do. My other request in

1:03:11

the chat, let us know what you thought of this live.

1:03:13

This is the first time we've done it. We've never done

1:03:15

this kind of live situation with

1:03:18

Jason and David, kind of branding it as rework. So

1:03:20

let us know if it's something that you like

1:03:22

and we should do it again. But I didn't

1:03:24

get to your question. I'm sorry. There was a

1:03:27

lot going on. We will get to your question

1:03:29

hopefully the next time if we do a live

1:03:31

session again. You also can email us at rework

1:03:33

at 37signals.com or you can leave us a voicemail.

1:03:35

And that's 708-628-7850. Do you want to leave

1:03:37

us a voicemail message? We

1:03:43

often replay those in the podcast. We

1:03:45

get those from listeners. Jason, David, anything

1:03:47

else to add before we close it up

1:03:49

and get back to work? No,

1:03:52

I mean, we'd like to do these again. This is fun.

1:03:54

So yeah, I'm curious to see what people want to know. Thumbs

1:03:57

up. Yeah. Enjoy the energy of

1:03:59

live. questions that's great.

1:04:03

Okay thanks guys thanks for joining us and we will

1:04:05

see you soon. Thank you.