Rework

In this episode of Rework we're turning the spotlight onto you, our listeners, with another episode of listener questions. 

Today, Kimberly Rhodes sits down with Jason Fried and David Heinemeier Hansson, the co-founders of 37signals, to pull back the curtain on the intricacies they faced when hiring a COO for their team, and the intuition-driven decision making they used to ensure their new hire would be a good fit and complement the team. 

Plus, how to help your company get started with working in six-week cycles, and adapting product development principles to professional services companies.

Listen in to explore Jason and David's unconventional yet remarkably effective strategies for business development and growth.

Show Notes: 
 
[00:00] - Kimberly introduces the topic for today’s podcast, listener questions, with a question from Justin who asks, "I saw that you hired a COO in 2021 after not having someone in that role for a while. What’s the 37signals approach to executive hiring?" 
[00:46] - Jason discusses their decision to use a recruiter for hiring their new COO and shares which qualities were more important to them than the candidate's resume.
[03:20] - David elaborates on the challenges of hiring executives, the importance of chemistry, and how Elaine complements their team.
[06:41] - Reflecting on adding a third person to a team with a long history—why it was important to find someone who could introduce a dose of healthy conflict without making everything a grind.
[08:07] - Jason shares how long the hiring process took, and what made them think that Elaine might be the right fit.
[09:13] - David shares the importance of "gravitas"—having the weight and legitimacy to inspire trust and confidence in the team and how Elaine stood out compared to others in the hiring process. 
[10:44] - Kimberly shares this two-part question from Reuben: “What's your suggestion for helping a company get started with working in six-week cycles—is there a specific time to start? And are all the teams across 37signals synced on six-week cycles?”
[11:07] - Jason shares his perspective on getting started with six-week cycles, his advice on when is a good time to start a cycle, and the one time he wouldn’t. 
[12:50] - David discusses the importance of individual focus in problem-solving and why he believes in starting with a small team to test Shape Up's effectiveness before implementing it company-wide.
[15:41] - The benefits of having the entire company operate on the same clock frequency.
[16:27] - Kimberly shares a question from a mystery caller asking for advice on adapting product development principles to professional services type companies, like public accounting or legal that work on hourly billing and tax deadlines or legal deadlines that they have to meet. 
[17:21] - Jason and David share how to apply the core ideas of Shape Up to diverse service types and internal areas of your organization.
[19:43] - The value of setting shorter goals over six weeks, rather than annual goals to increase the chances that things will get done. 
[20:11] - How shorter cycles help prevent the pile-up of tasks and overwhelming situations that often occur at the end of longer timeframes. 
[20:49] - Kimberly introduces a listener question about whether the 37signals team uses telemetry or relies on intuition in their product development process.
[21:14] - Jason discusses their approach to product development, emphasizing the importance of other factors extensive telemetry, and A/B testing.
[22:12] - David shares the challenges they have encountered with telemetry and A/B testing.
[26:11] - The value of speed, forward momentum and making decisions instead of stalling to find a perfect solution.
[27:24] - How launching quickly helps your team, with an example of how the team trimmed two months of analysis down to one day.
[28:22] - Data can only reflect the past and doesn't accurately predict the future.
[29:14] - Momentum in making continuous improvements is both crucial AND hard to measure. 
[30:10] - If you have a question for Jason or David about a better way to work and run your business, leave us a voicemail at 708-628-7850 or send us an email and we just might answer it on a future episode. The REWORK podcast is a production of 37signals. You can find show notes and transcripts on our website. You can also find full video episodes on Twitter (also known as X) and YouTube

Links and Resources:

Do you have a question for Jason and David? Send us an email or leave us a voicemail at 708-628-7850.  
Shape Up
Books by 37signals
Sign up for a 30-day free trial at Basecamp.com
HEY World | HEY 
Dev.37signals
37signals on YouTube
The REWORK podcast
The 37signals Dev Blog
@reworkpodcast on Twitter
@37signals on Twitter 

Creators & Guests

Host
Kimberly Rhodes
Customer Success Champion at 37signals
Guest
David Heinemeier Hansson
Creator of Ruby on Rails, Co-owner & CTO of 37signals (Basecamp & HEY), NYT best-selling author, and Le Mans 24h class-winner. No DMs, email: dhh@hey.com
Guest
Jason Fried
Founder & CEO at 37signals (makers of Basecamp and HEY). Non-serial entrepreneur, serial author. No DMs, email me at jason@hey.com.

What is Rework?

A podcast by 37signals about the better way to work and run your business. Hosted by Kimberly Rhodes, the Rework podcast features the co-founders of 37signals (the makers of Basecamp and Hey), Jason Fried and David Heinemeier Hansson sharing their unique perspective on business and entrepreneurship.

Kimberly (00:00):
Welcome to REWORK, a podcast by 37signals about the better way to work and run your business. I'm your host, Kimberly Rhodes, and I'm joined by the co-founders of 37signals, Jason Fried and David Heinemeier Hansson. This week we're going to knock out some questions from the audience, so let's get started. The first one is about our C-level leadership. This one says, "Jason, this one's for you." David, I guess you don't get to answer. "I saw that you hired a COO in 2021 after not having someone in that role for a while. Can you talk about what the hiring process was like? Most C-level leaders seem to have all the achievements, but no experience and of a lot of companies make one disastrous C-level hire after another. What was the 37signals approach to executive hiring?" and that comes from Justin.

Jason (00:46):
Well, first off, this actually is very much about me and David. This is out of all the roles we hire, this is probably the only role that we've both fully been involved with in a long time together. So for a role like this, we actually went to a recruiter. Every role we hire, with very few exceptions, are typically just done. So we write a job ad up, we post it on our own channels, we get the word out, we get between a hundred and a thousand plus applications. But for C-level, we wanted to go with a recruiter who kind of knew or had basically a book of people they've worked with in the past, and they could get to people that we couldn't get to through our own channels. We thought that there'd be somebody out there who maybe knew who we were, maybe didn't, but wouldn't be paying attention the same way. Or maybe wasn't looking for a job but would be looking to be recruited for a job, that kind of thing.

(01:39):
So we hired a recruiting firm and went through a pretty extensive process. I think we ended up, I mean we looked at dozens and dozens of candidates, but I think we narrowed it down to kind of three for a while. Almost went with somebody, got really close, had three or four meetings with this guy, and then we met in person and it just didn't quite feel right. And I think that's the thing that ultimately made the biggest difference. How does it feel to be with this person? This is a person is going to be a true peer, a one of three around the table. It's got to feel natural, it just has to feel natural. It has to be a certain chemistry, the ability to riff and just feel right. They've been here for a long time, so a lot of people are hugely qualified for this job, obviously.

(02:32):
Some people have been CEOs, some people have been COOs, some people have been lower and then trying to move into COO role. The resume didn't matter that much. It turns out it kind of matters, but not really. What really mattered for us was getting together. So we got together with a few people in person and it was kind of tight between two people in the end and we went with Elaine. And she's been great, but I remember it really is this subtle thing. It's a feeling. It's like this person is the right person for who we need at this time for what we need. There's always someone who's more qualified, there's someone who has more experience, but it's not really about that. This is not like weighing a bunch of different facts and figures and then coming out at the end with an answer. It's a human decision and that's kind of how it played out.

David (03:20):
I think what's interesting about hiring at executive level is unlike most other hires we do, you can't really give them a work sample product or project to do. When we hire programmers, when we hire designers, we get to look at the actual stuff that they do every day because we'll give them an assignment that's tailored exactly, and we can compare one candidate to the other. When you're dealing with executives, you really can't. And I think that's why the source behind this question is it often goes wrong. Of course it does when you can't really tell whether this candidate's going to fit in this role at this company because you don't have a good way of testing them beyond I was going to say just talking. I mean obviously that's hugely important and Jason says so much of this is does this feel right? We're going to be this gang of three at the executive level.

(04:10):
There has to be good chemistry, there has to be sort of a complimentary set of sentiments, almost. Not just skills but also sentiments. Elaine is complimenting Jason and I think in many ways by being a far more calm individual in a lot of circumstances. That was exactly what we need it, but it is so hard to find that, so I can totally see why it goes wrong. And I also think one of the reasons it goes wrong is that the job description for an executive is so vague. If you are like, I'm hiring you as a designer, you're going to work on this product. We know what we're talking about. When you talk about COO in particular, it's basically all sorts of stuff. It could be employee things, it could be go to market, it could be marketing, it could be all these different disciplines, and you don't really sort of know until you get started whether that's the right fit or not.

(05:10):
So I think there's far more of a leap of faith when it comes to executive hiring. Then we would trust to our normal process because that normal process is so tailored to being able to look at the actual work. And here we have to actually go off the CV a little bit, go off the conversations that we had and we had quite a few. I think we met with Elaine in person two times or three times, which as a distributed setup, it's not that easy to coordinate. But then we met for hours and hours. I mean we talked to both Elaine and the other candidates far longer than I've ever talked to any other candidates because she didn't have those particulars of the work product to review against.

Jason (05:51):
Yeah, we did have a little bit of work sample, kind of, not in the same way we had writing. Oh, that's right. It's kind of like here's some ideas. How would you handle these situations? So it was very broad, very specific, but it was all done in writing. And also the way it was presented was something that was important to us as well. Someone going to throw together keynote slides because we don't use Keynote or PowerPoint. We don, we don't do decks at 37 signals ever. So it's more like we write. So seeing how they write, seeing how they formulate ideas was a really big part of it, but all told it was a small part of it ultimately, but it was kind of a gut check. Could this person actually do the work too?

Kimberly (06:27):
And I don't think this is Justin's question, but I would think that it would be extra hard because the two of you founded it and has been together this whole time and now it's like you're introducing this third personality into the mix. I think the stakes are pretty high.

Jason (06:41):
Yeah, that's probably a question for Elaine. What's it like working with two idiots like us in a sense? So I think, yeah, it is hard. It is hard for the third person for sure just because first of all, David and I have worked together for nearly 20 years regardless of whether or not we kinda started the thing together. In a sense it's like we've just been together for a long time and we've been making a lot of decisions solo to one-on-one for years and years and years. So it is a hard thing to slot into. So that was another thing we were looking at, would this person would they create a certain degree of healthy conflict, which is pushback and challenge? We want that, but we don't want everything to grind. We didn't want everything to just be a grind. And that can happen too when someone's very strong-willed and has a very strong point of view and doesn't know when to let up, and that includes us too in certain situations.

(07:31):
So just got to find that right balance of negotiating hard lines and a lot of that comes down to some fundamental principles about how someone sees the world and how someone would approach problems and we felt like Elaine was a great match for the team really. And that's the other thing is when you're hiring a third, you have two and you're hiring a third person, you're really hiring for the team. You're hiring an individual, but it's really what is this person doing to the team? It was a fun process and this long and in arduous in a lot of ways.

Kimberly (08:05):
How long are we talking about?

Jason (08:07):
Months? I don't know. How long do you think it was? Four months? Four or five months? Yeah, something like that. And it can be disheartening sometimes because you meet a bunch of people early on. I think one of the things we learned by the way, and this would be valuable for others is it can happen that one of your really early candidates is the one, but it turns out that doesn't seem to always be the case and you can get, we got I think pretty far down the road with one candidate because he stood out amongst the early candidates and that got us really fired up. But as the more we talked, the more we just felt like it wasn't the right match for us. He was beyond qualified and very well achieved person. He's done a whole bunch of stuff, impressive things, but I think we got excited early because wanted to get it done. You want to get it over with. It's a lot of interviewing and a lot of talking and you want to just find the person you think will end the process soon enough. In a sense, and this sounds terrible, but it is a feeling that you have, but it really is important to stick it out and meet a lot of people and get more perspective to make sure you find the right one in the end.

David (09:13):
And I think that long process really showed to me how important something like gravitas is. We met some early candidates who had a bunch of good experience and technical skills, but in contrast to some of the other candidates we then looked at, they felt like they didn't have the gravitas as stepping into a role where this person essentially has to not just be able to, but a lot of fronts actually do step into the shoes that Jason and I have filled for 20 plus years. That is really difficult to do and it's difficult to do in a way where when you are relating to others in this company that you have that people have a sense of trust that this is legit. There's weight in it, which was one of those very ephemeral. How do you specify gravitas? Oh, what we're looking for is you could say gravitas, what does that word mean?

(10:02):
It only really means something in relation to other people. It means something in relation to Jason and I, the relationship we have to the company and then in comparison to the other candidates. And I think that was what was helpful. Even though as Jason said, it was just so draining to have all these long conversations. I mean even an introduction conversation with a candidate would be like an hour, an hour and a half, maybe even two hours to really get a feel and make sure you felt you had a fair ground for assessing someone. And we just did quite a lot of these, but that gravitas element really stood out in comparison. We just go like, Elaine's got it. Elaine's got that weight to it, that gravitas to it, and some of the other candidates just didn't have that in the same way.

Kimberly (10:44):
Okay, well we're going to go to a question from Reuben. This was posted on a podcast video on YouTube. Reuben asked, it's a two-part question. What's your suggestion for helping a company get started with working in six week cycles? Does it make sense to start at the beginning of a month or a quarter of a year and at 37signals are all the teams across the company synced on six week cycles?

Jason (11:07):
I don't think it matters too much when you start, except you probably don't want to start around a major holiday or something where you're going to lose a week and it's just going to be complicated. So just find a six-week stretch that is open for everybody just to set yourself up for the best possible odds I would say. But I think that the bigger thing is just start versus when's the right time to start? And how do you start? And when don't you start? Just, tomorrow. Start. Or pick Monday, next Monday, start with that kind of thing. I would also say pick something that's not highly critical to begin with because you're going to put yourself under undue pressure and if it doesn't work the first time you're doing something, it may not work. You don't want to overshoot on something that's or under deliver whatever term you want to use on something that needs to happen right now.

(11:56):
So find something important. You don't want to do work that doesn't matter. You want to find something that matters, but I wouldn't pick the most important possible project next. So find something you think you're capable of delivering and maybe it's a little bit challenging or maybe something you haven't been able to do before and this could be a chance to like, well, let's try a new way to do this or I don't know, but that's what we're do. And the other thing is I would make sure the team's as small as possible. So we work in two person teams. The more people you put in, and this is actually a very important thing for six week cycles, which is a relatively short period of time. More people doesn't get it done faster. Sometimes it can, but most times it does not. And especially if you're doing something new, there's probably going to be a lot of interpersonal communication and people aren't going to be sure what they're supposed to be doing and when they're supposed to be doing it and there's going to be a lot of chatter that's going to slow things down and muck things up.

(12:44):
So I keep it small, keep the project relatively small, keep it doable and start Monday.

David (12:50):
Fred Brooks has a great saying, what one programmer can do in one month, two programmers can do in two months, that there just is not this scalable nature to a lot of problem solving that a lot of it simply has to just happen with an individual who dives into it. And I think it's also easier if you are an organization dipping your toes into Shape Up to sort of cut off a section of the people you have working like alright, let's give these two teams for example, let's say you have a handful of teams, let's give these two teams a chance at Shape Up. They're going to get six weeks of uninterrupted times. We have some pitches that are shaped up, we're ready to go. These people are just going to be left alone to do the work. And I think what you're going to see and perhaps even be shocked at is just how incredibly productive individuals can be when left alone for long stretches of uninterrupted time to work on something that's clear enough but not overly defined.

(13:49):
And I think then the process is going to sell itself. If you go, hey, this is a big bang, we're going to turn the entire company over to this new clock cycle and clock frequency working on, there's just going to be a lot of, oh, I don't know and what about this, what about that? You can sidestep all that by simply showing results with a smaller team set going into this new process from the beginning and then it's no longer a discussion. That's what I love about doing things and it's not just about a process, it's also about making things in general. You can talk and talk and talk and people can have a reasonable argument one way or the other and then someone does something and the argument is over. The argument is simply over. If you embark on Shape Up for six weeks with two teams and they just deliver some great stuff, you can just, Hey, do you know what?

(14:41):
There might be all sorts of things we don't know yet or we have to tweak the process, but the results are undeniable hopefully, or at least there's enough promise here to keep and then just don't overthink it. I think that's what Jason's saying too, just start, don't overthink it, let the results speak for themselves and then the rest will follow. I think though when the rest does follow as it has at 37signals, every single team at our company runs on the same clock frequency. Not everyone runs exactly the same with pitches and some teams have large slices of them dedicated to reactive work. The operations team for example, just had a lot of stuff coming up with servers that need attention that wasn't planned for necessarily. So they have a bunch of time dedicated to reactive work, but they still report on the same clock frequence and I think that's actually a benefit once you get there, don't start there, but once you get there every six weeks we have the entire company essentially reporting in.

(15:41):
They're writing their heartbeats, they're giving an assessment to the rest of the company, not just to executive, not just to her for their reporting, but to everyone saying, here's what we worked on. And it just feels great. It feels great to read the report, for example from the ops team. Look at all this work that's gotten done. I think this is one thing that happens often in companies is that you end up in this sort of little group, you know what your team is working on, you know what they've accomplished, but you're perhaps a little fuzzy on like, oh, what's marketing been doing? What's operations been doing? What's recruiting been doing? If you get on the same clock frequency and everyone is sharing at the same time, it's such a feel-good moment. Yeah. So that's the payoff to look for once you get the whole company on it, and I would recommend getting there. Just don't start there.

Kimberly (16:27):
Okay, and this next question is a voicemail from a mystery caller and David, I think it actually goes along with what you're saying.

Listener (16:34):
Hey guys, I appreciate the podcast and thank you for all the work that you've produced. I was wondering, you talk a lot about the principles for companies that deliver a product, whether that's software or really anything that ships, but do you have any advice on how to adapt those principles to a professional services type company specifically like public accounting or legal that work on hourly billing and have externally imposed deadlines like tax deadlines or legal deadlines that they have to meet? Thanks a lot.

Kimberly (17:13):
I think this is kind of what you're saying is we're still, regardless of what your job function is, everyone has this six week period that they're getting work done.

Jason (17:21):
And of course you have to account for reality. So tax are due April 15th, you build your cycles project or your cycles around some milestones that exist in the year. I mean it might be a trade show, it might be this thing that you have to attend every year in July because that's just what the industry that you're in does. You just work around these things. These are milestones. Maybe you see them as obstacles, whatever they are, they exist. So work around them is my best advice there.

David (17:49):
I'd also say that perhaps with the exception of tax reporting, something like a trade show, getting ready for a trade show, looking at that through the lens of budgets rather than estimates is a really good way of making sure you meet that deadline because I think that's really the core for me at least about Shape Up is to shift your focus away from, here's a specific list of work we have to get done. How long is all these steps going to take exactly, like getting ready for a trade show. There might be a small list of things you absolutely need and then there's a ton of stuff you'd like to have or embellishing you can make, and if you set it up in sort of a budget way where you give autonomy to the team to pick exactly what's going to make it in by that deadline, that's totally in line with how the rest of the Shape Up methodology works.

(18:36):
But as you say, we run this for things as diverse as accounting or as marketing things that don't really otherwise align. You'd think with product development where Shape Up was born, but this idea that we have sometime we're going to dedicate to reactive work, things that just come in and come at us. And then we also have some longer term projects. For example, accounting. We've had several long-term projects for installing new reporting systems and all of these things can run under the same idea of having budgets instead of estimates and trying to look for what can we get done within the cycles. But the further you get away from software development, the less I think we have confidence in saying, oh yeah, this is going to be perfect and just right for you. So even if just the main thing you take away for these other departments is hey, having a regular clock frequence for reporting to the whole companies through heartbeats and then kickoffs of what's going to happen next cycle. It's just a good practice even if it doesn't entail all the other elements of Shape Up.

Kimberly (19:43):
Yeah. I also will add, because I have never been in product development until this situation at 37signals, but I think there is value in setting goals that are like this is what we're doing over the next six weeks regardless of what your job function is and doing that for a short period of time where a lot of companies are like, here are our annual goals, here's what we're going to accomplish this year. I think the Shape Up philosophy is shorter times means things are actually going to get done and if every department is doing that, it just is an incremental gain.

Jason (20:11):
Here's the other thing about that is that when you have one, just one big window, let's say like annual things tend to pile up at the end because things always push towards the end of whatever space you're giving them. So if you have one big space, you have one huge pile up at the end and that sucks. So if you have six cycles a year, you have smaller pileups sometimes, which is good or just hopefully no pileups, but you just have these breakers where you have to reset and move on to the next thing. This is a really valuable thing, otherwise things just keep going and then there's never enough time and too many things are happening at once at the end and everyone gets frustrated and it's holiday season. Bad idea.

Kimberly (20:49):
Okay, this question comes from Jake. "Love Basecamp and the transparency sharing your process in the live design review for mentions in the Hey menu." I'll link to that in the show notes. "Question, do you all add any kind of telemetry or user action recording, A/B testing or similar LaunchDarkly et cetera, or do you design more based on feel intuition, big fan of your podcast and books? Thanks Jake."

Jason (21:14):
Yeah, it's feel and intuition and then also feedback that we get once something launched live so we don't test ahead of time. Sometimes we do internally, so we'll ship something to staff only. Look, we have 80 people here. We should have a pretty good read if things are way off base pretty quickly, you know? Versus inviting customers in which slows everything down and we could still get the same feedback our own way in shipping it into production is just the best way We do it internally, but we don't use telemetry. We do sometimes A/B tests on the marketing sites, but we're very rarely, I don't even know if maybe we have once or twice in the product, but oftentimes we don't. It is intuition. This feel is knowing the product, it's knowing the customer base. It's knowing what we're trying to build here and then going with something. That's it. Just this is what we're going to build and we're going to put it out there. We think it's our best effort. We think it's the best solution given all the constraints. We don't have to explain the constraints to anybody. This is just what we're doing. And then you put it out there and you see what happens and that's the best way to find out if it worked or not I think.

David (22:12):
We actually used to have a system for telemetry that would record user actions that we then had some one in data analytics look at and try to deduce insights from. And I think we just never really arrived at something that felt like, oh wow, that's going to send us in a totally different direction. Our intuition on this perhaps is completely wrong and it felt like we were doing it because it's a thing you can, especially with SaaS software. It's very easy to instrument everything into minute detail and how many people are adding this thing and then what are they doing afterwards. And for a long time we were searching for this holy grail, and the holy grail was what is the set of actions that we could induce that triggers conversion, right? This is a business and we're trying to get customers who take a look at our product to buy our product.

(23:06):
And we've looked at this over and over and over. Literally spent months and months of research on it and the only conclusion that came out of that was really self-evident in a lot of ways. If you can use Basecamp with others, if you can get others to use Basecamp with you, you're going to stick around, you're going to pay for it. But what does that mean? What can we take that with, for example, we try to do something like, okay, if you can just get more people to use, we should shove the invitation process really early in the project. So you get onto this thing and then immediately we're trying to get you to invite other people to it. You know what? That didn't really move the needle. And again, why not? It's obvious. You're signing up for this yourself checking out Basecamp, is it right for me or not?

(23:47):
Until I've determined that I'm not going to invite someone else, I'm not going to invite the entire company before I know whether I think Basecamp is actually right for us or not. So being able to tweak this is quite difficult. We were, I think, or at least I was, and some of the data analysts we've had on kind of infatuated by the Facebook myth. And the Facebook myth was that they found early on in testing that the number one thing that mattered as to whether someone would stick with Facebook or not was whether they would upload three pictures where they tagged someone else on Facebook in it. If they could just sort of get someone to upload three pictures, the engine itself would kind of take over and it would just start working. And I don't dispute that there are those viral vectors when it comes to consumer apps like that.

(24:33):
I very much do dispute that that is likely to be these main fundamental triggers that you find in business software. We certainly haven't been able to find them. We've spent years and years and years trying to find them. And that's not free either. It's not free getting lost in the data, it's not free focusing on all these statistics coming in. I think the statistics sometimes have this nature that's similar to if you want to get more confused about a decision, just ask more people. If you want to get more confused about a decision just to add more data, more data points, more things from different, and suddenly your gut, your intuition gets in doubt. And what I've found, at least what I've seen in the history of this company, we make the best product decisions when we do go with that gut because the gut doesn't come out of thin air.

(25:22):
It comes out of running a software company for 20 years and talking to a bunch of users and having strong ideas and opinions about how to build great software. I remember early on looking at the process Microsoft had for some of their development and going like, do you know what? That is not what we want. We do not want this committee-based tabulating user requests against telemetry data and then just letting the data decide where the software goes. That's not the kind of stuff that we're making. And I think proudly so, and this is why the software we make is not like the software Microsoft makes or any other large corporation to a large degree. It has a point of view. It has an opinion and it's going somewhere that you could almost trace back to not almost that you can trace back to individuals making gut-based decisions.

Jason (26:11):
The other thing I would say that we value here is just speed and moving on and building new things. So someone might say, and I've heard people say, well, wouldn't you want to know? If you could know the exact four steps? You want to know that? I go, well, maybe. But how long would it take to know that? How certain would we be? How many paths would we go down to find that? How many times would we be wrong about those four things? Maybe it was a different four things or it was actually three things and not four, but we felt like it was four because this always came after that, but that didn't matter. You can go down all these paths and then you've got eight months behind you and you've made no other progress because you're afraid to do anything because committed to making this investment and this thing, you need to find out.

(26:50):
I don't like the stall involved with that. It really feels like a stall. And you want to try to make sure you don't crash before you hit the ground. You got to just keep moving forward, I think with this stuff. So maybe you make a few mistakes, maybe you get a few things wrong. I don't really care. These things individually don't matter that much. It's more about the long-term trend of improving the product for the customer base as a whole. You're not going to hit on everything, but you just keep moving forward. That's why I'd rather train. I'd rather train that than waiting around to try to find this magical answer that's probably not going to come.

David (27:24):
And you're going to get better at the intuition part if you make more decisions, if you get to make a hundred decisions a year, you have a hundred opportunities to let reality be the referee, and let reality feed you back the vote on whether your aim is on. If you launch something quickly without a lot of preemptive data analysis and you push it out there, you know quite quickly, whether it's got some fight, whether it's going somewhere or not. And if it's great, let's do a little more of that. If it's not okay, get back up there. Bat again. I think a great example of this was when we were experimenting with our pricing structure. We kind of did get lost a little bit for a while in the analytics rabbit hole. And what I thought was so interesting about that whole process was we spent, I think perhaps even a good two months debating back and forth, running sort of internal analysis to end up sort of where our gut already had told us that we should go right away.

(28:22):
And I just said it was a great example of those two months could just have been cut down to one day, do you know what? Let's just give this a try. It's not going to be the end of the world if this pricing set up doesn't resonate, okay, fine, we can change it. What's so important to realize is that data can only tell you about the past. It can't tell you about the future. It can't give you the accurate feedback on how are customers actually going to react to a new price. We can try to have some theories, but until you put it in front of someone and it goes for pricing, as it goes for features, you won't really know. So, oftentimes what I see is this is an example of lack of confidence. When someone needs to cover all their bases with data and analysis and so on, it's often because they don't have confidence in their own intuition or because they need something to point to if it doesn't go right.

(29:14):
And that's just excess stuff that we don't need to do. And if we dump that, we have more time to try more experiments and just rolling with it. I think the other thing here too is to realize not everything we do needs to justify itself on the individual basis. As Jason said, momentum alone is actually a huge factor that's very hard to measure. How do you measure pushing out five features within six weeks? What is the value of that in terms of the market? And so you can't really taste that by sampling the data on one individual feature because it's this meta aspect of it. And again, having confidence in this that you are making software, you should know something about the software, you should have opinions about the software that you're making, and you should trust those opinions and then kind of calibrate when you get things back from reality.

Kimberly (30:10):
Well, we do have more questions, but we're going to wrap it up there for now so we're not dragging this on forever. But if you have a question that you want to ask Jason or David about a better way to work and run your business, leave us a voicemail at 708-628-7850 or send us an email to rework@thirtysevensignals.com. And we might just answer it on a future episode. Rework is a production of 37signals. You can find show notes and transcripts on our website at 37signals.com/podcast and also full video episodes on YouTube and Twitter/X.