Build Your SaaS

Also: it's our 1-year launchiversary!

Show Notes

Justin and Jon are joined by Jason Fried to talk about:
  • The philosophy behind their new book Shape Up.
  • Does Basecamp's approach to 6-week cycles differ for smaller teams?
  • "Long projects destroy morale. When things don't ship, you get frustrated." – Jason Fried
  • Why projects ship late (it's human nature).
  • Why work is like a hill.
  • How they make product decisions at Basecamp.
  • How do you know what you should work on next?
  • Why they don't believe in backlogs.
  • "That feeling of 'there's nothing to do, but there's everything to do' shouldn't be happening." – Jason Fried
  • "You need a system at some point. When you have two people, you can hack your way to anything. But as soon as you grow, you'll need a system." – Jason Fried
  • "What we have is not a perfect system. And even if it was, we don't execute these things perfectly." – Jason Fried

★ Thanks to our sponsors:

Show notes:

You can reply to this podcast here:

Thanks to our monthly supporters:

Thanks to our monthly supporters
  • Pascal from sharpen.page
  • Rewardful.com
  • Greg Park
  • Mitchell Davis from RecruitKit.com.au
  • Marcel Fahle, wearebold.af
  • Bill Condo (@mavrck)
  • Ward from MemberSpace.com
  • Evandro Sasse
  • Austin Loveless
  • Michael Sitver
  • Dan Buda
  • Colin Gray
  • Dave Giunta

Want to start a podcast on Transistor? Justin has a special coupon for you: get 15% off your first year of hosting: transistor.fm/justin
★ Support this podcast on Patreon ★

Creators & Guests

Host
Jon Buda
Co-founder of Transistor.fm
Host
Justin Jackson
Co-founder of Transistor.fm
Editor
Chris Enns
Owner of Lemon Productions
Guest
Jason Fried
Co-founder of 37signals

What is Build Your SaaS?

Interested in building your own SaaS company? Follow the journey of Transistor.fm as they bootstrap a podcast hosting startup.

Justin:

This episode is brought to you by ActiveCampaign. ActiveCampaign makes a customer experience automation platform. What is that? Well, it's a complete set of tools for marketing teams and entrepreneurs that want to engage their customers and stay engaged with them long after their first sale. So with their platform, you can create more than just a funnel.

Justin:

You can send each lead the right message, turn them into a customer, and then educate them so that they adopt your platform. Stick around and ultimately become advocates. If you think this is right for you, you can start a free trial at active campaign dot com slash build your SaaS. With that URL, you get a second month free and 2 free one on ones. We highly recommend them.

Justin:

Go check them out.

Jon:

Hey, everyone. Welcome to build your SaaS. This is the behind the scenes story of building a web app in 2019. I'm John Buda, a software engineer.

Justin:

And I'm Justin Jackson. I do product and marketing. Follow along as we build transistor.fm.

Jon:

This is a big big episode today.

Justin:

Yeah. It's a big day. We just got off the phone with Jason Fried, and we're gonna be playing that interview in a little bit. But today is also August 2nd.

Jon:

It is.

Justin:

And what does that mean?

Jon:

We launched 1 year ago today to the public.

Justin:

That's right. Officially launched on, August 2, 2018. So this is our 1 year launchiversary.

Jon:

Happy launchiversary.

Justin:

Happy launchiversary, man.

Jon:

Does it feel like a year?

Justin:

In some ways in some ways, it feels like I've been working on this for 15 years.

Jason:

And in other ways, in

Justin:

other ways, that feels about right. Doesn't it?

Jon:

Yeah. It does. Yeah.

Justin:

You you've you know, you're just recently, quit your full time job, and now you're full time on Transistor. I'm essentially the same. I've been basically spending most of my time on transistor for the last, well, at least 6 months. I I do like the idea of, commemorating milestones.

Jon:

Cheersing over Skype with our waters.

Justin:

Yeah. Cheersing over Skype with our waters. Do you wanna set up this conversation we just had with Jason?

Jon:

Yeah. So, Basecamp just released a new book couple weeks ago online called Shape Up, and it's all about sort of what they've learned over the last 15 years of building software. Mhmm. Though it's it's the process that they've sort of evolved into, to build software and to sort of shape their software as they as they call it. This call came out of something you posted on LinkedIn.

Gavin:

Mhmm.

Justin:

Yeah. I it was just a video clip of you and I talking. And, in some ways, me struggling or us struggling in public with, how are we gonna how could we do something like that as 2 people?

Jon:

Right.

Justin:

And he just commented and said, hey. I'd be happy to chat with you about this on your podcast. So

Jon:

Yeah. Yeah. So, I mean, I yeah. After reading it, like, it it definitely resonates, but you read it as knowing that it's a company of, you know, quite a few people, although as as he talked about, like, the the product team itself is is still fairly small. Yeah.

Jon:

But, you know, the first thing that I think came to mind for both of us is, like, how how would we adapt some of this to a 2 person team where both of us are, like, wearing all the hats at different times? Like, how do we how do we build a process? I mean, we're a year end, but how do we build a process? How do we build these these, like, habits early on to where we can then, you know, bring in other people or, I don't know, just get a better a better cadence and a better sense of are we building quality software without getting kind of overrun with too many ideas or spending too much time on one thing?

Justin:

Yeah. It was a great conversation. Let's just play that right now. So this all started because John and I were talking about Shape Up, which is the the new book that Basecamp just put out, written by Ryan Singer. Right?

Speaker 5:

Yes. Ryan wrote the book.

Justin:

And it's all about how you folks work there. Specifically, I think well, to be honest, the the part I'm at in the book is when when you're talking about 6 week cycles. And in our conversation, we were like, I wonder if that could work for what John and I are doing with Transistor. And you commented on LinkedIn, well, let's record a podcast and talk about it. So here we are.

Jon:

Here we are.

Justin:

John, you had a specific question about, you know, what was it if when they were starting?

Jon:

Yeah. So, I mean, obviously, the the book came out of, what, 15 years of experience building software as a team and a and a growing team and the lessons that you've all learned from that. But I think, like, a lot of our audience is small teams and, you know, single person or a couple people trying to start a company. And I think one of the challenges that that we've noticed with transistor is sort of how do you structure, How do you build a product with 2 people? And after reading shape up, I think the first question that came to my mind was, like, how would we apply this to a 2 person team where there's not there's not a leadership team that is their sole purpose is to, you know, plan the product and shape the product, and there's not other teams that are building the product.

Speaker 5:

You wouldn't have all the same roles, but you'd have all the same hats, essentially, where multiple people would be wear or someone would be wearing multiple hats, which is how it was. Like, when we first built Basecamp, we had basically 3 people working on Basecamp, maybe 4. So bigger than you guys, certainly, but, like, still much, much smaller than we are today. Although we didn't follow all the same ideas back then because we didn't have them yet. But the fundamentals were there, which is that long projects destroy morale.

Speaker 5:

When things don't ship, you get frustrated, and then you also begin to second guess, And then you redo again and again and again and second guess, and like you start getting in this cycle of like, is this thing any good? It's like sometimes you just need to kind of keep moving forward on things. So so the time horizon, I think, is important. And, like, while we didn't do 6 week projects back when we were starting, because we hadn't come up with a 6 week idea, we've always tried to, like, get through things quickly and move on to the next stage. Otherwise, you get stuck in this circle of just working on the same thing and trying to perfect it without actually making any progress.

Speaker 5:

One way to think about it is, like, we're we're working on a new product right now, something we said we wouldn't we wouldn't do, but we are, we are doing now.

Justin:

Liars.

Speaker 5:

Not a new version of Basecamp, but, actually, I mean, we we'll be working a new version of Basecamp soon too, but a whole new product. And, the way it started was just a few of us exploring some ideas, and that's, like, r and d mode before actually setting in to build. That is not something we scope with time necessarily. That's just, like, we're exploring an idea. It's r and d.

Speaker 5:

It's just pure exploration. But when it comes to the point where it's time to actually be in to build things and, like, make the thing, then we shift into the 6 week cycle thing. And, it's important because, if you wanna get something out the door, you're gonna be working on parts of it that you don't like, and the worst thing is to be working on something you don't like for a period of time that you can't see. So at the very worst, any project you're working on under this method is 6 weeks, which means you can see the end of it right before you begin. So I think some of those fundamental truths apply even on very, very, very, very small teams.

Speaker 5:

And if it's just you 2, then, like, you're both gonna have to shape work together, or one of you shapes work or whatever, and then you get into doing the work. And then at the end of the the cycle, however long it is for you, you take a couple weeks off or a week off, and you shape up the next project versus planning the entire product ahead of time. It doesn't matter how many people you have. I think those ideas still apply that you wanna kind of move intentionally in relatively short periods of time, but not too short and not too long. Kind of for us, it's been 6 weeks is where we settled in, and then reconsider where you're gonna go next after that.

Gavin:

Mhmm. So

Speaker 5:

it's a series of short planning moments being in the weeds on the ground to decide what to do next versus stepping so far back and deciding the whole thing ahead of time. So that those principles, I think, apply to any size.

Justin:

Yeah. Was this something you all always had an intuitive sense about, or was this something that was forged through, like, client work? By the time you and David were working together, did you already have some of these ideas?

Speaker 5:

Some of them, but but a lot of it has changed over the years. So, when we for for a long period of time, we were doing, like, 3 month cycles, essentially.

Justin:

Okay.

Speaker 5:

Because we had a different attitude at certain periods of our existence towards like, well, we gotta get everything just perfect and like pixel perfect in this whole thing. It's like whatever it takes is what we do. It's like what ends up happening is you end up spending a lot of time, a lot of the time, a large percentage of the time making very, very marginal gains.

Gavin:

Mhmm.

Speaker 5:

And at some point, we we realized that we think it's more important to cover more surface area, at a high standard of quality, but not the highest standard of quality rather than going extremely deep at the highest level of quality and having it take way too long. So, like, for example, this new product we're building, we are covering a lot of we wanna get a lot of surface areas, a lot of new ideas in this thing. We wanna get cover a lot of surface area initially, and then we're gonna go back and tighten things up versus spending a lot of time in one area and making no progress on all the other ideas because you can pretty much guarantee you're gonna find yourself running up into a deadline and not having the product, like, addressing enough of the issues you wanna you wanna address if you just get too deep on one thing. But we've we've run with different different lengths of cycles. We've had no cycles in the past.

Speaker 5:

Like, all what we're putting out today is what we've learned. Mhmm.

Gavin:

So

Speaker 5:

it's not what we've always done, but it's what we've learned and now what we always do. But a lot of these ideas point back to fundamental principles. So how we've sort of executed them over the years is what's changed, but a lot of the principles are the same.

Justin:

Where where do those principles come from?

Speaker 5:

Seeing I've been involved in a lot of projects when we're doing client work To to your point, Justin, like, you you would just see things going on and on and on and the circular nature of work, like people being unable to make decisions, people giving things too much time, people not getting things done and giving it more time and more time. And then you get into this situation where, like, we've already invested 7 months. How could we ever just kill it now? We gotta keep going. And, like, you you just see the human human nature takes over where it's like, we've invested so much in this one thing.

Speaker 5:

We we can't possibly stop it, so we gotta get another month and another month before you know it. It's a year and a half late in the whole thing. And, like, I've seen this happen over and over and over and over.

Justin:

Yeah.

Speaker 5:

And so we basically have what we call circuit breakers in the process, which are basically 6 week cycles. It's like things have to speak for themselves after 6 weeks. Mhmm. We this prevents us from getting into the human nature side of things, which is like, we've already invested all this time. Like, let's just give another 2 weeks.

Speaker 5:

Mhmm. And it's never another 2 weeks. It's never another 2. It's like another 2 until you get to the end. It's like, we need another 10 days.

Gavin:

Yeah.

Speaker 5:

And before you know it, you've just doubled the length of the amount of time you spent on something, and maybe it's worth it. But this is where the whole Hillcharts idea comes into play, which is that if you're gonna give something more time, and we have occasionally given things more time, you have to understand where you're at in the process. Mhmm.

Jon:

So let

Speaker 5:

me I'll step back for a second. The hill chart concept which we write about in shape up which is built into base camp 3 was something we invented a year ago or so. We realized that work feels like a hill. It's not linear. It feels like a hill.

Speaker 5:

Some things you gotta push uphill and it's hard, and you don't really know where you're going. You don't know how how high the hill is. But once you get to the top, you're like, it's all downhill from here. Like, we know where to go with this now. Mhmm.

Speaker 5:

So if you're at, like, close to 6 weeks at the end of of a cycle and you're, like, realize that you're running out of time and you're not gonna get it done, the right question is not how much do we have left, it's how much is known versus unknown. And the hill chart tells you how much is known versus unknown. If you have a lot of unknowns left with a week to go, giving another 2 weeks is not gonna get you there because you don't know how long it's gonna take. Mhmm. If you have only knowns left and you're like, we actually really need 1 more week.

Speaker 5:

We we know what we need to do. We are absolutely certain of it. Like, one more week, okay, then you can make the argument and make the bet that it's worth it. Mhmm. The problem is is when you're almost done and you've got a pile of unknowns left.

Speaker 5:

Mhmm. And and you're like you just then you just start guessing, and you're gonna guess wrong. And then before you know it, this thing could take Yeah. 2 cycles or 3 cycles or more. And the more you get into it, the harder it is to say no because you piled up all the work behind it and the momentum's there.

Speaker 5:

Mhmm. It's this this stuff is like it's just human nature, and you just gotta guard against it because we're all human, and we're gonna make these mistakes unless we put these circuit breakers in place and keep ourselves honest.

Jon:

Yeah. I've I've definitely been in in situations in the in the recent past like that where you actually think you're done with something and then someone else comes in and is like, what about oh, wait. I forgot about this. Right. And then it's unable to be released because it's a huge important thing for somebody on the team.

Speaker 5:

I'm gonna put a plug in for Basecamp for a second because I think the tools you use matter. Mhmm. And the reason why I think this matters is because the tools you use and how they present the information help you ask different kinds of questions. And if you're just looking at task if you're if you're using something that's just all about tasks and you're looking at the tasks that are left, like, you get the sense that, like, well, we're 95% done because we have 5% of the tasks left.

Gavin:

Mhmm.

Speaker 5:

Like, we're almost done. That says nothing about what those 5% are. Are they knowns? Are they unknowns? Are they the hard stuff?

Gavin:

Did you

Speaker 5:

leave the hard stuff for the end? Like, this is another thing that happens all the time. What we try to do with projects is we try to attack the hard stuff first. I'm not sure if actually Ryan wrote about this. And if not, I'm gonna talk to him about it because we're making a second revision on the book right now.

Speaker 5:

We should talk because there's been a lot of questions coming in. People are like, how do you do QA and how do you do bug tracking and all that stuff. So Yeah. Kinda adding that stuff in. But we try to make sure we attack the unknowns first because the hard stuff has to come first.

Speaker 5:

If you leave that to the end, you're you're in trouble. You're just flat out in trouble. You cannot have unknowns piling up at the end. So the problem with just like tracking tasks or on a linear line or like a progress meter or that kind of straight line stuff is that you're not asking the right questions. You're asking what's left to do.

Speaker 5:

You're not asking of the stuff that's left to do, what do we know how to do? What do we not know how to do? Where are we at? Are we pushing this uphill or is it going downhill? Like, those questions matter a ton, and they change the conversation, and they help you get things in order early

Gavin:

Mhmm.

Speaker 5:

Because you're talking about knowns and unknowns versus just stuff on a list. Stuff on a list can be prioritized. We'll prioritize by what? Like, by how easy it is to do, by how how much we wanna do it. It's like the how you know?

Speaker 5:

Versus, like, are these knowns or unknowns? Are these hard? Is this not gonna be hard? What do we know? Where are we at?

Speaker 5:

It helps you address these things. So, anyway, different point of view, different different way to look at projects.

Justin:

Yeah. And it for you folks, is an unknown everything? Is it, like, for example, John was just working on a multi episode player. And to do that, he had to learn a new JavaScript framework thing. So that was an unknown.

Justin:

But there's also unknowns like, who is this for and what is it for, Like, much more like baseline philosophical. And at the beginning, you might think something's a good idea. But once you start to work on it, you go, well, we actually don't know who this is for or what they're gonna use it for. There's also unknowns like, you know, what will it look like, how will it function. So are are you talking about all of that, or is the philosophical stuff figured out before all of this?

Speaker 5:

Yeah. The philosophical stuff, why are we building this? Who is it for? Not necessarily what's it visually going to look like, although although there's like we we come up with just a general sense, but it's up to the design team to figure out that. And it's not about like how we can implement that, that's up to the development team to think about.

Speaker 5:

But the shaping process is about and I'm gonna use the word the word confidence which is like statistically inaccurate in a sense because it's all just a bet. Yeah. This is part of why we call them bets because it's like there's risk involved here. Yeah. But, like, by the time we decide to take on a project, we have to know why we're doing it.

Speaker 5:

We have to be clear about what it's for, roughly how it's going to work, like, at a at a big picture point of view. Mhmm. Not like code picture, but, like, at a big picture point of view. And not exactly exactly how the UI is gonna look, but roughly, like, how could it look. Mhmm.

Speaker 5:

This is what shaping is about. And a project is not we don't take a project on and don't we don't slot it for a 6 week cycle until all that's out of the way. Yeah. There should be no philosophical questions in the middle of the project. Like, if you're doing that, you haven't done the shaping upfront enough.

Speaker 5:

Mhmm. Because then if you get to these existential philosophical questions 4 weeks in, it's like everything grinds to a halt and then like no one knows what they're doing or why and then you're like stuck. So you've gotta before you pick a project, you gotta make sure you understand why you're doing that project. So for example, the JavaScript stuff, that's part of like the unknowns of executing the project. And you know it's it's possible.

Speaker 5:

It's It's just like, we've got to learn that. We don't know how to do that. That's an unknown, but we know we need it. So, like, we can we can do that. But it's like mall I don't even know what this feature is, but like this multi would you call it multiplayer?

Justin:

It's a multi episode player, like a playlist player, like SoundCloud would have.

Speaker 5:

Yeah. So, for example, before you decide to build that, you're like, why are we building this? Like, that's part of the shaping thing.

Jon:

Mhmm.

Speaker 5:

And part of our our our pitches or our shaped up work basically explains, like, here's the problems we're addressing. Here's why we're addressing them. Maybe it's something we've experienced. Maybe it's something that's frustrating to us. Maybe we've heard customers complain about it for years.

Speaker 5:

Maybe it's a it's a it's a hunch, but, like, here's why. It's gotta be part of that, and you gotta be very confident about that. Again, it's a bet Yeah. Meaning there's risk. Because the only the only way you know a 100% is, like, by releasing the thing.

Speaker 5:

That's only moment that there's a 100%. Like, not it's not even a 100%, but, like, that's the moment of truth. Yeah. Until then, you don't know. But but, yeah, I would incur just to be really clear if I if I haven't been, like, philosophical reasons, use cases, whatever those things are, that's gotta be clear upfront before you choose to take that work on.

Speaker 5:

Otherwise, you'll never get it done in 6 weeks.

Justin:

Maybe it'd be interesting to explore how you and David did that early on and maybe even how you might do it today if you could start again, Because, like, were you initially doing that shaping work and then handing it off to David? How did that relationship work, and how would you change that today if you could go back in time?

Speaker 5:

I think the way we work is we we we would never say we hand anything off to anybody. Mhmm. There's no handing off. It's very much we work very closely together. In the early days when we didn't have the term shaping, we that's like a term we kind of have come up with over the last, you know, couple years or year and a half or whatever it's been since we've been talking about that word.

Speaker 5:

First of all, when we built Basecamp, we built it for ourselves. And so, we were not building it for anybody else. So our philosophical point of view was simply like, what do we want? What do we need? Mhmm.

Speaker 5:

So it was actually very simple in that regard. We weren't imagining what other people would want or how they would use it or any of those, like, use cases that you have to imagine. We just did it for ourselves. So that was actually quite a bit easier.

Justin:

But even there, if we just pause there

Speaker 5:

Yeah.

Justin:

You've got a team of 5 people, and everybody's got ideas about what this thing needs to be. Everybody has ideas of what this should look like.

Speaker 5:

Yes.

Justin:

Everybody has their own sensibility. Even if you're building something for yourselves, it's like trying to take your family on vacation. Like, you know, the kids wanna go to Disneyland, mom and dad. So how did you figure that stuff out? How did you shape it when you even when you were a small team?

Speaker 5:

For 1, it it helps to have a shared point of view on, like, what you're building. Mhmm. 2nd, there's a number of things. 2nd, like, we we took very small steps. So, like, it'd be unlikely to have radically different points of view on, like, what it looks like to post a message to Basecamp.

Speaker 5:

It's it's not what you know, it's like we need to make an announcement that we need to see and our clients need to see, like, we need a big text area to do that. Mhmm. People should get a a notification of some sort. Like, we're not creating controversial stuff in that regard, and most products are not controversial either. Yeah.

Speaker 5:

Problem is is when people imagine, like, all the things it could possibly do versus, like, we're very good at figuring out what does it need to do. Mhmm. There's always disagreement and there still is today on on everything that we do, of course. But, like, at the end of the day, like, you you argue it out, you debate it out. And on every project, we have this idea called point where there's always a point person on every project

Gavin:

Mhmm.

Speaker 5:

And that hat rotates. It's primarily the the designer on the project, but it could rotate. And it's that person's call at the end of the day. So their their job is to hear everyone out and then make decision. Mhmm.

Speaker 5:

And then people fall in behind the decision. And, like, that's what we have to do because you can't be arguing the forever. Yeah. So I think we argue about some big picture stuff initially, and then we don't try to argue too much about the finer points, unless, like, something's really just feeling wrong for some some reason or some feature like you said, like, sometimes you do build something and on paper it looks great or the idea is great and then you build it and you're like, shit. I don't know.

Speaker 5:

And that's happened recently. We've been working on some stuff where everything, like, I made the argument. It seemed great. I thought I was gonna use it. Mhmm.

Speaker 5:

And we built it, and I haven't used it yet. Just one feature. Just one specific feature, and I'm like, shit. And so I'm like, but here's the beauty here's the beauty. 6 weeks is the and by the way, this wasn't 6 weeks.

Speaker 5:

This was a 2 weaker. Mhmm. So it's like, worst comes worst, we've lost 2 weeks. Yeah. Like, we have not lost 7 months.

Jon:

Right.

Speaker 5:

We've not lost like, that is the worst when you just go this is the thing, it's like these are all bets, so you don't wanna, like, go all in

Justin:

Yeah.

Gavin:

On a

Speaker 5:

lot of things. Alright? Because some of them are gonna be wrong. And so that's why it's really nice to have things maximum 6 weeks, takes take maximum 6 weeks.

Jon:

Yeah. That is good. It really it really

Speaker 5:

does take the morale

Jon:

the morale busting, aspect out of it. It's really hard. I think it's hard to be have your morale totally broken after 2 weeks rather than 7 months, and you release something or maybe you don't ever release it and never sees the light of day, and then that whole team is just wasted for a while.

Speaker 5:

Yeah. And, look, I mean, it sucks to do 2 weeks of work and have it thrown out too, but, like, it sucks a lot less. This is all about, like, proportion, probability Mhmm. You know, I mean, not like in a mathematical way, but, like, essentially, it's like, hey, if you have to throw away work and it's it's maximum 6 weeks and more likely just a few weeks, like, probability that people are gonna be able to get over that is quite high compared to like 8 8 months. It could just destroy somebody.

Speaker 5:

Like, it could. Mhmm. And if they were disgruntled for any reason before that, like, that's their way out. Like, they're out of here, basically. Like, I don't wanna create situations like that.

Speaker 5:

Yeah. But people also understand, like, that occasionally, like, minds change, things don't quite work out as expected, and we have to kill a feature or something, like or or modify it in some way. Like that, then it's reasonable

Gavin:

Mhmm.

Speaker 5:

Versus it being, like, a horrible decision.

Justin:

Just want to take a quick break right now and thank our sponsor profitwell.com. They have a brand new season of protect the hustle.com out. You can search for it in your podcast player right now. Really well produced podcast. And if you are an entrepreneur, if you are someone on a software team, these are incredible interviews with some of the leading people in startups, people who have built companies.

Justin:

I think you're really going to like it. Go check out Protect the Hustle. And also, if you haven't signed up for ProfitWell yet and you want to get SaaS metrics for your business, go to profitwell.com. Alright. Back to the conversation with Jason.

Justin:

And so going back to you and David initially, how did you work as a 2 person team? I mean, I might be wrong. Was it just you 2 working on it, or were there other people working on it?

Speaker 5:

Me, Ryan, and David Okay. Primarily. We had another guy named Matt who was on board, but he wasn't working on the product as much. So it's basically 3 of us. But we always lead with, design, and we always lead with with, either a really quick paper sketch, fat marker paper sketch or we just jump right into HTML.

Gavin:

Mhmm.

Speaker 5:

And this is true today as well. Of course, not on iOS and Android, but, for for the web for for desktop.

Justin:

Yeah. We we we

Speaker 5:

leave with HTML. So, like, the work is, like, within a day, there's something up and it's basic and it's something, but now David can go and we can discuss it and we can like, this is how it's supposed to work. We talk about it and he can start to plug some stuff in then we can trade back and forth. He can go, hey. You know, I can do it like you guys designed it.

Speaker 5:

Could take 6 days to build it out like that. Mhmm. Or you know what? There's a 2 day version of this. If we change this from this to that, like, what do you guys think?

Speaker 5:

It's like, I think that's worth it. Let's do that. Let's do the 2 day version. Like, that change is fine. Or some things like, no.

Speaker 5:

No. This is really it's gotta be like this. Here's why. And, like, you can't always tell someone it's gotta be like this. So you gotta kind of you know, you you gotta keep some in your pocket and and and give some away and, like, sometimes you decide, like, this isn't worth fighting for or whatever, but, we're we're always trading concessions and discussing points of view and but but we're always looking at something that's real Mhmm.

Speaker 5:

Which is fundamental because if we're talking abstractly, it's very difficult to get there. So that's why design leads. We put something out there. It's an HTML. We can begin hooking it up, Dave.

Speaker 5:

We can go, hey. How about this? How about that? Would you trade this for that? Yeah.

Speaker 5:

Yeah. Okay. Let's do it. And, and some things are are worth fighting for and some things are not. Mhmm.

Speaker 5:

And you just kind of do that. It's more of a negotiation and a conversation. That's a product development really is versus like a dictatorial situation where like, it must be this way no matter what. I will not accept anything less than this. It's like, you can do that on one feature or 2 features, but, like, you're gonna everyone's gonna hate you.

Speaker 5:

And then what's the point of that?

Gavin:

So

Justin:

So that example that you just gave, is that an example of shaping, or is that an example of a 6 week cycle? Once you're into HTML and design and that kind of debate back and forth, is that kind of like, we've already decided what we're gonna build, and now we're working on it?

Speaker 5:

Yes. That's within the 6 week cycle. Okay. We don't talk HTML design. We we have a sense, like, before we take on a project, we'd, like, run it by David

Gavin:

Mhmm.

Speaker 5:

Or or Jeff here and say, like, is this reasonable? Like, do you see a path here that we this can be done, basically? And if the answer is yes, then, like, that's the extent of it. We don't go deep into, like, making technical decisions at that point. That's for the team.

Speaker 5:

This is something we talk about in the book, which is we don't assign tasks.

Jon:

Mhmm.

Speaker 5:

We assign projects. Yeah. And the team decides they they have full autonomy to decide like technically how they're gonna implement this, design wise how they're gonna implement this. So if we're if we're even talking HTML and deciding about, there's a 6 day version of this or 2 day version of that, whatever, that's our this product's already been shaped up and we've already begun working on that. Mhmm.

Speaker 5:

So within that period of time, that's when those sort of, trades happen.

Justin:

Yeah. Okay.

Speaker 5:

Yeah. So so so yeah. Don't don't think of, shaping is not technical work. There's no HTML yet. There's no, like, there's nothing that could ship at all.

Speaker 5:

It's, like, it's the concept. The concept is being hashed out, and it's being presented in a way where it can be explained to others. Mhmm. And then basically clock starts on the Monday where we decide to begin the work and like, now it's the team can decide what's how how they wanna approach doing it. And then amongst themselves they decide like what features are worth it or what not features, what version of execution is worth it, which things are worth doing spending 6 days on versus 4 days on versus 2 days on and, like, you sort of start to trade we call trading concessions.

Speaker 5:

You begin trading concessions while you're working, but not before.

Gavin:

I mean,

Justin:

I like this idea a lot. I'm now trying to picture how John and I would do this because the the idea of, like, even okay. We're gonna take, I think you said roughly 2 you spent 2 weeks on shaping. I don't know if that's if that's accurate or

Speaker 5:

There's 2 weeks in between cycles typically where we where we will shape up fine like, shape up final projects. Mhmm. But sometimes the shaping process can go on for months, here and there.

Gavin:

Mhmm.

Speaker 5:

Right? Like, Ryan and I will toss ideas back and forth. We'll explore some stuff. We'll get, like, kinda far and then hit a roadblock and be like, let's put this on the on the shelf for a while, come back to it later, or have a breakthrough on something 3 months later that we talked about 3 months before. So there's a bunch of stuff that's always in motion.

Speaker 5:

Mhmm. Always, like, kinda floating around. But, roughly the 2 week period before we begin a a new cycle is when we pick we go to the betting table essentially

Gavin:

Mhmm.

Speaker 5:

Lay some stuff out. Like, here are the things we think we should do next. And then we kinda we those things have either been fully shaped up or they've been mostly shaped up, and then we kinda polish them up and get them ready to go. Mhmm. And then, then they're ready to go.

Speaker 5:

But the actual process of shaping up work can can like span you can connect dots to discussions months in advance. Mhmm. So it's not really a moment the only kind of formal moment is when we actually decide the projects and then, like, polish them up and write them up for the teams. But there's a lot of informal back and forth playing around with ideas, discussions, observations, intuitions. Hey, we should try this sometime.

Speaker 5:

Hey, should we do that? Hey, this is really irritating. What do you think? Let me think about it. I'll get back

Gavin:

to you. There's a lot of that

Speaker 5:

stuff that's happening always bubbling even within cycles because it's always happening. Yeah. So so so it's not about, like, don't think about anything until you have 2 weeks to think about it. It's not about that. It's

Jon:

like, it's, like,

Speaker 5:

you're always thinking about stuff and you're always talking about stuff even while you're working, like, a new idea might bubble up. So as we talk about in the book, there's kinda, like, this idea of the big batch, which is, like, the full 6 week project, and there's like the small batch, which are like the 2 weekers or 3 weekers. Sometimes so the way it works is a team is dedicated to a big batch or full 6 week project, and then a team is dedicated to a series of small batch or couple week projects. Sometimes we only schedule a team basically, like, 4 of the 6 weeks.

Gavin:

Mhmm.

Speaker 5:

So they've got a couple small projects to do, and we leave 2 weeks at the end for, sometimes for new ideas that bubble up as we're working

Jon:

Mhmm.

Speaker 5:

Or, like, as we're building something we're, like, ah, this could be so much better if we had one more week to work on it because as we built it, we came up with another thing. So we sometimes leave a little bit of space, spare empty space in there to do that. Sometimes we don't. Just it's another way of being flexible there.

Justin:

One thing I've been thinking about is just how I'm used to doing all of this stuff individually. Right? When you're working on an individual project, you're always thinking about it, and then you're implementing it, and you have this cadence that kind of makes sense. Jumping from 1 person to 2, now I can see it it feels like, wow. I need to learn a whole new skill set here because to coordinate work between 2 people really does require some sort of system like this.

Justin:

Right? I think part of me is, like, realizing, like, how would we actually implement this? How would we would we just take a day a week? Getting it into my natural cadence, I think, feels is what's challenging of I'm just used to, like, thinking about work and then doing it. And now it's like, okay.

Justin:

I have to learn how to do work with somebody else. And I realize I need some sort of rails for that. But implementing it is the part that I just can't visualize it. I can't visualize how I would do this, you know, on a week by week basis.

Speaker 5:

Well, you're not doing it week by I mean, what part of it? Like, you're building all the time, I imagine. Like, you're building things. But, like Yeah. I mean, I I know you.

Speaker 5:

You you've you've got ideas. You you think about stuff all the time. Like, you don't what what I would try to be careful about doing is, like, forcing yourself to think about ideas at this. This is the moment when I think about ideas. It's like, mhmm.

Speaker 5:

Not really like that. You've got stuff bubbling, you guys have a product, you're thinking about what it could do later, you don't need to think about everything it could possibly ever do. Just like what are the next things you want it to do? Mhmm. And what are the kind of the next set of improvements you wanted to have?

Speaker 5:

And you start to think about that and you set up like the 6 the next 6 weeks is like we're building x we're building these features or whatever it might be or maybe it's one feature because it's just 2 of you or whatever it is.

Jon:

Mhmm.

Speaker 5:

But like while that's happening you can have other ideas for other things too and you just kinda make note of it, cycle ends, and you go, what do we wanna work on next? Well, here's some stuff we've been thinking about. Do we feel like we're pretty confident in these things? Are there tons of unknowns? Are there big unanswered questions?

Speaker 5:

Are we do we really know if anyone wants this? And those projects probably aren't ready yet.

Gavin:

Mhmm.

Speaker 5:

So, like, what do we feel like we could do next that we're pretty confident in? I mean, all this stuff is hard, but, like, it doesn't you don't have to make it harder than that. Mhmm. The point the fundamental point is that you go into when you decide to take on a project, you have a really good sense of what's what it's about, what's involved. There's no big unopened questions.

Justin:

Yeah.

Speaker 5:

You that that you're ready to go on that piece of work. That's the fundamental idea here because what you see all the time is that people get involved in projects and they don't really know why they're doing them and they have a general sense, but then they start to be they second guess. Someone else brings a new idea in and you don't know if it's, like, within the scope of the concept or not, and so there's a bunch of debate that opens up before you know it, you've blown 2 or 3 weeks arguing.

Gavin:

Mhmm.

Speaker 5:

Things going all over the place. Like, it's going in different directions now. No one knows where it's headed, and, like, you've just wasted 3 months.

Justin:

Yeah.

Speaker 5:

Arguing and not even arguing, but building but building something that's, like, it's it's incongruent. It's sort of pointing in different directions. It's not really clear why you did it, but you did it because you were under pressure to make something. It's like you don't want to avoid those situations. That's where projects go south quickly.

Speaker 5:

Yeah. You wanna make sure that whatever you're working on, you have a pretty good sense of the boundaries of it, the scope of it, the why of it, roughly the idea behind it. And then you spend the 6 weeks building it, and then you're done.

Jon:

Mhmm.

Speaker 5:

And that's the point is that you're done. So it cannot go on. Yeah. And maybe the first few you do, you're like, shit. We didn't plan our time very well, but this is like anything.

Speaker 5:

You've gotta practice it. Mhmm. But but a big part of this is is, you know, I think getting things on hill charts and asking the right questions as you go, which is like, where are we? Are there unknowns or there knowns? Like, how much is left that we can't see?

Speaker 5:

Like Yeah. If we're 4 weeks in and there's a bunch of big fundamental shit we're totally unclear about, like, we're in trouble. We gotta jump in on that, or or we gotta do this earlier next time. It's like, gotta ask the right questions to bring out the right

Jon:

Yeah.

Speaker 5:

The right details of the project. So, anyway Yeah. I mean, all the details, of course, are in the book, but, fundamentally, that's what I'm trying to to get people to to think about. Yeah. I think

Jon:

we we do we do some of that, I think. I think, you know, I'm not gonna speak for Justin, but but for me, coming from working with a group of people to basically working with for myself or with one other person, you kind of you have this idea that you wanna move quickly and and ship fast and and and that there's so many things to do that it's it's almost impossible to know that you're doing the right thing at the time. But, you know, talking to you and hearing you talk about this stuff, it's like, it's not really that there's one right thing. There's not one right feature for that time. They're all potentially good.

Jon:

You just kind of have to choose one that you know is gonna provide or not know, but, like, you think is gonna provide some benefit. Kind of go with that and plan it out.

Speaker 5:

I think another thing I would just to be clear is, like, big part of why this works really well is that you're not planning months months in advance. One of the problems with that is that if you have all this work lined up or if you have backlogs, like, we don't believe in backlogs. If you have backlogs, backlogs make you feel guilty. This is all the shit I haven't gotten to.

Gavin:

Mhmm.

Speaker 5:

And planning way ahead of time is all the shit we haven't gotten to also. And if I plan it all out and now what I'm working on is pushing I'm not working in 6 week cycles, let's say, and now I'm letting this one thing go for 3 months. When I pushed off all this other I pushed off all the stuff in front of me even further down the road.

Jason:

Yeah.

Speaker 5:

And the backlog is even further away from me now. Like, you're pulling and pushing at the same time. It's like you're trying to make space for yourself. It's very it's unnerving. You it's

Jon:

very strong. Yeah. We ran we ran into that. You know?

Speaker 5:

Everyone does. It's like everyone does and they think that's the right way to work. It's like, no. It's a fucking broken way to work.

Jon:

Yeah. We had a call about that, and it was, it was me. I was, like, I was very anxious about our backlog and the amount of things that we I was staring at this list of stuff being like, I don't know what to work on. I'm, like, frozen. And, Never.

Speaker 5:

Yeah. So yeah. So this is this system eliminates. I mean, backlogs, I think, are dangerous, horrible things. So, like, I would never have a backlog.

Speaker 5:

In this system, it eliminates that entirely. It's about 6 weeks. Now we decide what we wanna do next. Mhmm. We don't look to the past to figure that out.

Speaker 5:

We talk about it. What do we wanna do next? Not what have we put on a list to do next? What do we wanna do next? What do we feel like we're confident that we can pull off in the next 6 weeks?

Speaker 5:

What's the most important next thing? What do we know really well that we could do? How you know, all those those are the questions, not like what's next on a list. What's next on a list is just like it's just a list of shit that makes you feel guilty.

Gavin:

Mhmm.

Jon:

So if there is no if there is no backlog

Speaker 5:

There is no backlog. Not a

Jon:

There is no backlog.

Speaker 5:

There is no backlog. You obviously have ideas that are floating around

Jon:

in your head. So is it a matter of of if those ideas stick around long enough, then they're worth pursuing. And if they just you forget about them and it's like, well, whatever. They didn't exist anyway.

Speaker 5:

Yeah. It's very unlikely that that amazing feature you need to build is is going to like, the only reason you're gonna remember it is because you put it on a list. No. It's it's you know it because you use the product and you understand where you're going and you have sense of what you wanna do and you have a sense of what people are doing and, like, it's that. And it's also things change through context.

Speaker 5:

I mean, 6 month like, the problem with backlogs is they're old.

Gavin:

Mhmm. It's the

Speaker 5:

number one problem with backlogs. Backlogs are not current. They're old. And to feel like you have to go prune them, it's like wasting that's a waste of time. Context is important because what you put on a list 6 months ago may not turn out to be important 6 months from now because as you're using the product, you realize that that didn't matter anyway.

Speaker 5:

Something you were so confident would matter, but it doesn't matter. Now you've got old shit. Like, forget the past. Keep ideas current in your in your mind, fresh ideas, things that are interesting. Don't look at everything.

Speaker 5:

You're not picking from 200 things. Like, you're thinking what's in your head. What do we know? Where where's the product deficient? I don't need to look at a list to know whether the product's deficient.

Gavin:

Mhmm.

Speaker 5:

I mean, of course, unless especially with you guys, you're 2 people. Like, it's not like it's you have a customer service team which is keeping track of complaints that you never see and then you like, that can happen too.

Gavin:

Mhmm.

Speaker 5:

And that does happen, of course. But so you can you can be detached from the product at some point. But right now especially this this also this question of what should I be what should I work on next that the problem with that is that you have a rolling you have a rolling work and that means work can roll on also like forever.

Justin:

Yeah.

Speaker 5:

So so that's kind of thing. Whenever you ask yourself, like, well, I'm free now. What should I work on next? It's like the problem is is that is is that, like, again, there's no discipline around when to stop or when to start. It's just like I'm free now.

Justin:

Yeah.

Speaker 5:

So then you're like, oh, shit. Well, I can't just sit and twiddle my thumb, so I gotta, like, pick something. So let me go pick something that's old, and then you're, like, working on something that's unformed because it's but it's on a list. And it's like, I don't really know where to go with it, and then you stall out and you slow down again. So, this is kind of how these things go and and it's it's amazing to me that, people put up with it.

Speaker 5:

Although, I I get it because we've been down that road too in the past. Yeah. But it's not a good way to work, and yet it's, like, seems to be the common way to work. And I think, hopefully, we we can help change that. But

Justin:

No. This has been really helpful. Everything you're saying is resonating. Like, I feel the emotion of the situations you're describing. And I think the only challenge, of course, is before you've done it that way, before you've you've had some sort of system around this, and, you're used to actually, Derek Sivers just has this article about old clothes and new clothes.

Gavin:

Mhmm.

Justin:

Like, you're used to wearing the old clothes, and you might look at the new clothes. Like, I'm, like, looking at it. Like, okay. That makes sense. But these old clothes, I'm just used to them.

Justin:

I'm used to waking up Yeah. And going, okay. What am I gonna work on today? Well, this looks good. And then and, you know, and just hoping John is working on something worthwhile.

Justin:

And then, you know, we're obviously talking about the future and stuff, but I think that's the challenge where I'm at right now. It's like, oh, I'm in the old clothes, and how am I gonna put on these new clothes? And how is it practical with 2 people?

Speaker 5:

Well, I think well, it's totally practical with 2 people. Like, the size does has very little to do with it. I think the big question is, are you struggling enough?

Gavin:

Mhmm.

Speaker 5:

So if you're not struggling enough to break a habit, like if you think the way you're working is actually fine, then you should continue to do that. Like I think the only thing that's gonna encourage you to change is motivation. When you're like fuck this, like we're not getting anywhere, I feel like we're spinning we're going in circles we're spending way too much time on things or feel like we're running into moments where we don't have anything to do yet there's everything to do Yeah. Like when you when you have like when you run into those kind of moments then it's like that's motivation that's a struggle. Like, there's gotta be a better way to do this.

Jon:

Yeah.

Speaker 5:

There's gotta be a better way to do this. It's it's like, really, that moment when I I should I'm gonna write about this. It's one of one of the reasons I like doing interviews and podcasts is, like, something comes out of your head and, like Yeah. This this feeling that, like, I have nothing to do, but there's everything to do.

Justin:

Yes. That is a

Speaker 5:

very real feeling. I think, John, you just described that. And, like, that's one of those moments where, like, that those things should not be happening

Gavin:

at the

Speaker 5:

same time. And when they are, like, something's wrong. So it's really it's ultimately at the end of the day, struggle is required to even open the door to change. Yeah. So again, if you guys feel like it's fine, then you should keep doing it that way and maybe it is fine.

Speaker 5:

But if you're at the point where, like, this isn't gonna we're not gonna be able to grow this way also and, you know, part of it, like, is you you you need a system at some point. Like, when you have 2 people or 3 people, you can kind of hack your way towards anything. Yeah. But the 4th person comes and the 5th person comes in. Like, you you need a system all of a sudden.

Speaker 5:

You can't just have, like, a do I DIY rough way of doing things because you can't communicate that to other people, and then it gets really chaotic pretty quickly. So

Gavin:

Mhmm.

Speaker 5:

It's good to I think, form good work hygiene or good work habits early so when the next person comes in, they can join up with your system versus you then having to you're flailing around, and now it's too late. And then it's even harder to get that done.

Jon:

I think I think, yeah, this discussion is timely too because we've we've recently been talking about maybe hiring a customer service, person at least part time, and and I I think we both want to, but part of me is, like, now we have someone to manage. And, like, if we're already sort of frustrated with how we're planning and managing right now, like, how is this third person gonna fit in? Yeah. So, yeah, start starting those habits early, I think, is is a good idea.

Justin:

Cool, man. Well, I appreciate your time. This is, you're very good at articulating emotion that I think a lot of people have felt before. So the the thing, the emotions that are inside that have never been articulated, stand up comedians do this all the time. They they say, oh, but this is what the way you feel.

Justin:

And so as you're talking, I'm like, oh, man. That is exactly how I feel, although it's never been articulated like that.

Speaker 5:

I think the only reason I can do that is because I felt that way too. Like, we've we had we've been working on this system for a long time because we've had those moments where it's like, this doesn't feel right. Like, this is complicated. It's things aren't going well. Like, we've had to come up with these things.

Speaker 5:

So I've felt all these things and still occasionally do. It's not what we have is not a perfect system. And even if the system was perfect, we don't execute it perfectly. Yeah. We still run into these things occasionally where it's like, shit.

Speaker 5:

You know we're we're too far down the road here. We should have thought about these things earlier. We should have talked about this more. Like, we should have gotten this unknown out of the way. What are we gonna do?

Speaker 5:

God, we need to give this another week. Like, we still run into that stuff. So I still feel those moments too, but we we try to like, none of this is theoretical. We've this is a practical system that's been built based on, like, working on software for 15 years

Gavin:

Mhmm.

Speaker 5:

And being very conscious of problems working on software for 15 years and and and human nature and all that stuff. And not, like, trying to come up with a a system that sounds good on paper, but really, like, practical system that, like, really addresses the things that people deal with all the time working on projects. So I I hope hopefully, it's helpful for you guys, and hopefully this maybe this conversation will help others who are like, I don't quite get it or I'm not sure what to do, and maybe they'll resonate. Maybe their emotional angles will resonate and go, yeah. That's me.

Speaker 5:

I totally now I see it. Or maybe not, but thanks for allowing me to just mumble for a

Justin:

while. Well, maybe we should touch base again in a little bit, and we'll see we'll we'll talk about how we were able to apply some of that. Because, I mean, ultimately, we have to figure this out in our way as well. Having some sort of, like, direction to head is helpful. So Yeah.

Justin:

Cool. Is there anything else you want, our listeners to know? You wanna tell anyone about something?

Speaker 5:

No. I mean, I'm sure you'll link up the book. This is kinda what we're we've been talking about, shape up. And, there was actually a couple maybe maybe, relevant. We we did a couple podcasts recently on the book and had, like, this roundtable with with a designer, a developer, Anne Ryan, who's head of strategy who wrote the book, talking about the process and how it helps them.

Speaker 5:

So we just did an episode on that on our podcast rework.fm. Yes. So I would link that up because that that's a good roundtable with a designer and a developer talking about how they work together on a project and sort of the changes they've seen at having implemented this this system. So I think that might be something people can really understand

Justin:

Yeah.

Speaker 5:

As well.

Justin:

That's great. Are are are you folks gonna eventually put this in print somewhere?

Speaker 5:

Yeah. The plan is so we we released it as a website first for a number of reasons. One is, we wanted people to be able to, like, link to it and refer to, like, individual pages or quotes. In fact, if you select some text, you can, like, tweet that text. Like, we kinda put that in there.

Speaker 5:

You know? And then the other thing was that we knew that once we put it on the market, so to speak, like, we'd get feedback like any product. And we realized that there's a few area we knew we'd be missing out on a few things like what did you really wanna know that we didn't quite say. And so the 2 things that have come up specifically, it's been a number, but the 2 things have been, like, how do you integrate QA into your process? Yeah.

Speaker 5:

And, also, what do you do with bugs? If a bug comes up, do you stop everything and fix it? Do you slate those into 6 week cycles? Like, how does that go? So we're currently, like, next week gonna be updating the book in a few different areas to talk about that.

Speaker 5:

Also, another one that comes up, the 3rd most popular one really is about team size. Like, how do we implement this as a small team? Because we're we talk about how we have 50 people. The thing is is that we don't have 50 people working on product. We have, like, a dozen or so.

Justin:

Yeah.

Speaker 5:

So we're actually a lot closer to the small teams people already have than than than maybe it sounds, But we're gonna talk about the difference between, like, 3 people and maybe a dozen or multiple teams working on something. So we're gonna include that as well. Once we have that in place, we feel like we've really kind of nailed it.

Gavin:

Mhmm.

Speaker 5:

And then we'll do a PDF, PDF version. We'll do a Kindle version, and then eventually, we'll do a print, probably, eventually do a print version or also do an audio version. But we kinda want to get out there amongst the community first

Justin:

Yeah.

Speaker 5:

And then shape it shape it with them afterwards, basically. Cool.

Justin:

Sweet, man. Super helpful. Thanks.

Jon:

Yeah. Thanks a lot for the time.

Justin:

Yeah. Thanks for your time, man.

Speaker 5:

You bet.

Gavin:

Talk to

Justin:

you soon.

Speaker 5:

Take care, guys. Thanks.

Gavin:

Alright.

Justin:

Well, that was our conversation with Jason. It was good.

Jon:

Yeah. It was that was good. It was a lot of insight. He really brings, I don't know, fresh fresh set of eyes to to these problems, and, I don't know. We hope hope you all got something out of it.

Justin:

Let's, quickly thank our patrons, and then we will say goodbye for this week. John, who supports us on Patreon?

Jon:

Alright. We have, Noah Pral.

Justin:

That's right. Brand new.

Jon:

David Colgan.

Justin:

Also brand new.

Jon:

Robert Simplicio, Colin Gray, atalit2.com, Josh Smith, Ivan Kerkovic, Brian Ray, Miguel Peterafita, Shane Smith, Austin Loveless, Simon Bennett, Corey Hanes, Michael Sittver, Paul Jarvis, and Jack Ellis, Dan Buddha, my brother danbudda.com. Darby Frey, Samori Augusto, Dave Young, Brad from Canada, Sammy Schubert, Dan Erickson, Mike Walker, Adam Devander, Dave Junta. Junta. Kylefox@getrewardful.com, and, our sponsors this week, ActiveCampaign and ProfitWell.

Justin:

Thanks again, everyone. We will see you next week.