SEASON 2 - EPISODE 0072 - AUG 30, 2023

Writing a Pitch

If you’ve been following the REWORK podcast, you’re undoubtedly acquainted with the concept of Shape Up, a cornerstone of 37signals’ approach to product development.

In this episode, we delve into a core component of Shape Up: the delicate art of crafting a pitch.

Join REWORK host Kimberly Rhodes as she sits down with 37signals founders, Jason Fried and David Heinemeier Hansson for a conversation encompassing everything from the essence and purpose of a pitch to the step-by-step process of constructing a finely tuned pitch.

Listen in as Jason and David walk listeners through Shape Up’s five-point compass for an effective pitch: problem, appetite, solution, rabbit holes, and no-gos, plus insight on how to use “tracer bullets” to manage the balance between scope and execution while avoiding the pitfalls along the way.

Check out the full video episode on YouTube.

Show Notes

00:00 - Kimberly introduces listeners to Shape Up, and the topic of the day: “writing a pitch” for product development.
00:34 - Jason shares what a pitch is and its purpose in product development.
02:16 - David emphasizes a crucial counterpoint to common practices at most organizations, highlighting the two common pitfalls.
03:12 - Striking a balance: providing boundaries without stifling creativity.
04:05 - The key innovation of a Shape Up and the importance of avoiding extremes of over-specification or vague one-liners in your pitch.
05:44 - Jason shares who can write a pitch, and the distinction between throwing out ideas and formalized pitches.
07:47 - David introduces listeners to the concept of “framing” before pitching.
09:28 - Why it’s vital to distinguish between identifying a problem and crafting a pitch.
10:25 - Effective pitch creation requires contextual awareness to devise realistic solutions.
11:46 - Pitched solutions are more about direction than detailed execution—the true execution and implementation are the responsibility of the assigned team.
13:06 - Pitching is a powerful tool for attracting and nurturing independent decision-makers.
14:54 - The magic of deferring decisions until the implementation stage.
15:46 - Pitching projects is a blend of autonomy, mastery, and purpose, aligning with Daniel Pink’s principles of employee satisfaction.
17:21 - Shape Up’s five key details for making a pitch: problem, appetite, solution, rabbit holes, and no-gos.
18:23 - Rabbit holes: tempting yet treacherous distractions that offer the illusion of progress. Why unveiling these traps early is essential.
20:08 - David shares an example of a recent project using a time zone auto completer.
21:15 - A “science project” - the macro version of a rabbit hole.
22:41 - How a “tracer bullet” or “traceable” helps the 37signals team understand a project’s feasibility and complexity leading through a small investment of information gathering.
24:29 - Why a "tracer bullet is crucial for prioritizing projects, using an example of using a tracer to explore billing in other currencies and how it provided clarity on the project scope and timeline.
25:40 - Next week’s episode of REWORK will focus on the “Betting Table” and how the decision-making process unfolds to choose which pitches to work on. In the meantime, don’t forget you can still enter #TheUnderdogChallenge by sharing the story of your scrappy team on the 37signals LinkedIn post here for a chance to be featured on a future episode of REWORK. Look for show notes and transcripts on our website with full video episodes available on Twitter and YouTube. If you have a specific question for Jason or David about Shape Up leave your voicemails at 708-628-7850 and we just might answer it in a future episode.

Links & Resources

Transcript

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. If you’ve been following along with the podcast, you’ve heard us mention Shape Up, which is 37signals philosophy around product development. And today I’m joined by Jason Fried and David Heinemeier Hansson, co-founders of 37signals to talk about one of the elements of Shape Up, writing a pitch. We talk about it all the time, writing a pitch, but just so we’re all on the same page, Jason, why don’t you jump in and tell us first before we get into the details of a pitch, what is a pitch? What do we use this for?

Jason (00:34): Yeah, so whenever we decide to build a new feature in one of our products or actually build a new product, but this is primarily around building new features, we will think it through, we’ll talk it over and then we’ll write a pitch. A pitch is essentially a direction, that’s how I think about it. It’s not details, it’s not full-blown details. Here’s every little thing this thing needs to do, but it’s a directional statement. It’s a directional document saying, this is sort of the idea we’re after here. We want to add this feature to this product. Here’s essentially why. Here’s some things, some feedback we got from customers, which is a common format we now include in our pitches, and here’s kind of the problem we’re trying to solve. It’s not detailing exactly how to solve it, it’s a suggestion for how to solve it. It’s maybe a first shot, sketch and description of how to solve it, and then it’s about 800 words typically something like that, and then it’s given to a team. And the team then takes that and transforms that into actual real work.

(01:32): So they take this direction and then figure out how to get there in the amount of time we’ve allotted to it. That’s essentially what a pitch is. So it’s mostly words, it’s a sketch or two. It might be a little bit of evidence here and there, but it’s about 800 words or so, and with that, whoever’s working on the thing knows what to do. They look at that, they read it, they go, I know what this is about, now I’ve got to figure out how to make it happen. That’s sort of the extent of the pitch. What you want to be careful of is you don’t want the pitch to be so detailed that it’s six pages long and lays out every little thing in bullet points because now you’re writing a spec, and specs aren’t really where to go because you don’t really know what you’re going to need to do until you actually get into the work itself. So this is enough to point you in a direction and then leave you alone.

David (02:16): It’s also a counter to what happens at a lot of places, which is we want to do this thing often because a customer suggested it and you get a one-liner. No one has actually thought through what this means or what it takes to build it and have not arrived at a common place of understanding of if we actually built the thing is that what we want? Is that roughly the shape of something that would soothe the problem if that’s what we’re trying to tackle? So I feel like a lot of shops end up in one or two buckets, either as Jason say, they end up with these overly specified specs where they write everything out, there’s a bunch of methodologies and use case techniques you can use to minutely detail, here’s everything that you can do and you can give it to a team that then almost does not even have to understand the problem because they are simply implementing and design that someone who had carefully thought through it would do.

(03:12): And then you have the other end of it which is, hey, here’s just a ticket. Oh, we should have Kanban to Basecamp. You could imagine that in your head, right? There’s a card to say, just have Kanban. What does that mean? What is the shape of that? Where’s the cutoffs? Where are the trade-offs? We’re trying to find something that fits in the middle to be enough of a structure that a team has an idea of where the boundaries is, where the epicenter is, what’s really important here. If we didn’t do this one thing, would it really be the thing anymore, without overly specifying everything they need to do? And the reason in part why you don’t overs specify is A, because most of these problems you don’t know until you start building. We don’t know exactly what you want until you start building, and B, if you specify everything in minute detail, what you end up relying on is estimates.

(04:05): Now here’s a complete thing, a hundred percent of everything that needs to be done, how long is that going to take? You can’t run like we do with cycles. You can’t say this exact thing that I’ve just specified over six pages in minute detail with fine stencil drawings is going to take five weeks, six weeks. That is the traditional sort of waterfall-ish approach to software development that has failed for decades upon decades. And the key innovation, if you will of Shape Up is to flip that to let go of estimates, forget estimates and focus on budgets, but you can’t have budgets together with specs. So if you want budgets that is, hey, do you know what we think this problem is worth four weeks, six weeks? You have to leave it loose. You have to leave it bendy. And that means just describing things in enough detail that a team that actually then starts implementing can make the real final choices of what this thing is supposed to be while not just sending them off on a wild goose chase where if they end up building something, Jason goes afterwards, what’s this? Oh, that’s the one-liner. That’s our one-liner that’s implemented. Yeah, that’s not what I meant at all. So trying to find that Goldilocks space of not too much, but just enough. That’s what the pitch means to me.

Kimberly (05:28): Okay. Also tell me who writes these pitches? Is it just the head of product or can anyone write a pitch about anything? Is it designers, programmers, customer support? Kind of talk me through that.

Jason (05:38): Kimberly, you just sort of pitch. I did. So

Kimberly (05:42): I’m pretending, I don’t know.

Jason (05:44): Yeah, I get you. No, anyone can write a pitch. Pitches that are directly related to project work, typically written by a few people who are designated the people who are writing the pitches and deciding what work to do next. But anyone can pitch an idea. So there’s a couple different, the lingo is a little bit strange. Anyone can come up with an idea and pitch it and say it out loud or write something up, but the formalized pitch, I still don’t think we have the right language for this by the way. This is what we’ve also called a shaping document, but that doesn’t quite roll off the tongue. A formalized pitch is work that we’re going to do, but people can pitch an idea. So people will pitch ideas all the time. Doen, one of our designers just pitched an idea for how we could change the way we organize things on the homepage inside Basecamp.

(06:35): It wasn’t a formal pitch, it was just an idea that he shared. And then we took some of those ideas and had some other ideas and molded that into a formalized pitch. So it’s a tricky set of words and I think people get caught up, we get caught up on it sometimes, but the real way to think about it for us is a formalized pitch is what determines what we’re doing next. But people can throw ideas out or pitch ideas out. It’s almost better to say throw ideas out, not throw them away, but throw them out there if you just want to share something. But it also depends on different teams, so like Support might have their own collection of people who are pitching next things to do Ops might have that, so there’s not three people or two people dedicated to do this company why, but on a given team or product area, there’s typically one or two people who are in charge of that piece of work.

David (07:24): One way that Ryan Singer who compiled the original Shape Up book here at 37signals and now works as an individual consultant has proposed afterwards is this notion of framing, which is essentially the step before pitching, where you define the problem and the business value in solving but don’t actually specify what the solution is. And I think having some distinction between those two things. A pitch is a attempt at a solution. It’s attempt to, again, this is where words get overloaded. I was just about to say frame the solution, but you really overload it where the pitch defines what the solution is. And at a bunch of companies you have people who want to propose that we work on certain problems, but they’re not the ones who are going to design the solution. This is what Ryan now calls framing, and we’ve had that too where sometimes, for example in Support, they might be hearing about some problem all the time and they go, we need to fix this.

(08:32): But it’s not always that Support is the right unit to come up with what the actual solution is. Because one of the key things to note when you’re dealing with customer feedback is customers are exceptionally good at telling you their problems. They know exactly where it hurts. What they’re not always so good at is to tell you how to alleve it, because that’s why you’re a software designer. And I think actually a lot of software is bad because user-centrific development shops, that’s the positive spin here, simply take what a customer says, you should add this button on this part of the page because that’s exactly what I need. And they go like, oh yeah, yeah, the customer’s always right. Let’s just add the button. You do that for three years across thousands of customers and all of a sudden you have 5,000 little buttons that all individually solve some tiny little problem but does not constitute a cohesive solution.

(09:28): That’s why software development is (a) hard and (b) rewarding because you take this mass, this flood of problems and feedback that people give you and then you try to spot big patterns. So often as Jason say, we now do this explicitly. The pitch will reference maybe five customers who complained about something that the pitch is trying to address. But what you often find is that those complaints, they point to specific solutions because that’s how people verbalize the annoyance that they have. They say, you should have this. They not so often just say, I have this problem, could you fix it for me? They present it in the form of you should fix this, but a good shaper takes two steps back, looks at maybe 5, 10, 20 different complaints that perhaps don’t seem like they’re related, but all are due to some underlying problem that you could shape a pitch to solve.

(10:25): So separating those to think what’s the problem, what’s the solution? Different people can identify a problem and then you probably want someone who has, if not outright training in it, some expertise to come up with the pitch. And I think that’s another thing that’s just really important for this whole pitch process is the people who work on the solution have to have awareness and context about how to solve it. You can’t actually have a good pitch written by someone who don’t know how to build software. They don’t know what the constraints are. They don’t know what’s reasonable, what’s plausible, what cuts, as we like to say, with the grain of the existing system that you have. If you just ask essentially a customer, you could say, hey, what do you want? They’re going to come up with their thing in their blue sky way of thinking. They’re not necessarily a software designer. They don’t know the internals of the system. That’s not a way to end up with a pitch that’s going to be a really nice solution for something that fits inside of six weeks.

Kimberly (11:25): Well, I also think it’s interesting as I read pitches about our product feature that have been written, this is what we’re working on the next cycle. That solution very often isn’t execution. It’s just like this is what we’re trying to get to and there’s a couple ways to go about it, but it’s kind of left up to – correct me if I’m wrong – the designer and the program are actually coming up with how to execute that.

Jason (11:46): The team of two who’s assigned to the work, they have to solve the problem. We suggest a solution, but the words aren’t the solution. The paragraphs aren’t the solution. They explain a potential solution, but the solution is the actual work itself, the interface, the backend, the experience, whatever it is. That’s their role, that’s their job. So they take that and then with help if they need it, they figure out how to make that happen within the given time with all the constraints and trade-offs that they have in front of them and sometimes cutting the scope or adding the scope or changing the scope. Again, this is not defined. This is not a list of what it needs to be. That’s not what the pitch has in it. If you have that, then you have conflicts. It’s like, well, it said it had to do all these things.

(12:35): I can’t change that. It said it had to do these things. That’s not how it really works. It’s, here’s what we think it should probably do, here’s the problem we’re trying to solve. If you have a better version of that or a better idea or look, we’re running out of time, we can’t do it all. What’s the most important part of this and what can we lose? They can negotiate that with the project itself and sometimes with me or Brian or David or whoever is involved or Jeff or whoever it might be, and figure out the best way forward to actually execute and build and design and ship this thing to customers. So that’s how that works.

David (13:06): And I think that’s why pitching and that whole way of framing what are we going to work on is such a powerful tool. Not just for getting what you want but for getting the kind of people that you want. You want people who can embrace the autonomy of making decisions on their own and actually have to dive into the problem to flex that autonomy. When you dive into a problem, you understand that problem and when you understand the problem, the work is just more interesting. When people talk about code monkeys, it’s usually in terms of do you know what? You’re just going to be given something. I want exactly this output, you just put the bolts together. Here’s a Lego sheet. Don’t divert. The colors need to go exactly as it is. You’re just putting pieces together. Now, it could be fun to put Legos together. I actually enjoy putting Legos together from an exact description of it, but what I’ve found, at least with my kids, they like building their own stuff more.

(14:03): Not that it can’t be fun to follow a description, but there’s more of an expression of creativity and you feel like you’re advancing across multiple dimensions at the same time. When you actually have to understand the problem and you have the trust and power to come up with new solutions. I think this is one of the most gratifying parts of this whole process is that Jason and I might sit down, work together on a pitch, think we got this cracked, think we could have analyzed our way all the way to a perfect solution. The team starts building it and they go like, yeah, do you know what? That just doesn’t work. And then you show an in progress piece of work and you go like, oh yeah, you’re right. This is clunky. It sounded good. It drew well, but it doesn’t actually implement well. So then the team goes like, okay, then what do we have to do instead?

(14:54): That’s the magic of deferring so many of the decisions of the design until you have to work with the materials themselves because the materials will reveal shortcuts to you. They will reveal better ways of doing it, but you don’t know that before you’re in it. This is, again, the reason why all software that’s planned for the long-term is always failing, always behind schedule is because you just can’t know all the stuff upfront. Even on a six week project, usually the best we can do with the pitches, we can give you a really good direction for the first two weeks. First two weeks pretty likely that our guesses are correct. You get into week three or week four more and more will the direction start to diverge from the map. That’s a good thing that at least needs to be in the context of it and especially because we do this whole budget thing.

(15:46): We say, do you know what? This is worth six weeks. The map tells you, you should walk in this direction, but if you get halfway there and you go like, do you know what? There’s no way we’re going to make it. We’re going to need a shortcut here. You have the power to come up with that shortcut. So I really like Daniel Pink’s Drive 2.0 book and he spells out these three pillars of employee satisfaction. They are autonomy number one, mastery number two and three purpose. To me pitches draw on all of those. You give the autonomy that someone can come up with their own path of how to solve this within some broad boundaries. There’s intense mastery of doing that process, not just asking someone else what the solution should be, but actually having to figure it out yourself. And then the purpose of building something, being an integral part of it, not just a quote unquote “code monkey,” but part of the process of coming up with it is just so gratifying When you put those three forces together, you get people working on stuff that feels like, you know what? This is good, this is fun, and once you do that, you have a much better chance that you can go the distance. We can do six cycles a year. It’s actually interesting, gratifying work that you can continue to do for a long time, which is one of the reasons why we have quite a few people at 37signals who have been here for a long time. This is many of the same attributes that Jason or I take away from our satisfaction of being here for 20 years. Autonomy, mastery, purpose.

Kimberly (17:21): Okay, well in Shape Up there is five details that go into making a pitch problem, appetite, solution, we’ve talked about those. The last two are rabbit holes and no-gos. You guys kind of talk me through those.

Jason (17:34): Well, rabbit holes are these things that sort of for a second I think kind of look appealing maybe, and then you start to go down the rabbit hole and you can get stuck there forever. It goes deeper and deeper and deeper and deeper and then you find yourself just swirling in this hole where you’re working and working, working but not getting anywhere. And we try to avoid those because sometimes there’s something at the bottom of that that’s necessary to get to, but oftentimes it’s a trap. And so whenever something seems like it’s circling where a lot of work is happening but nothing’s, you’re not really getting anywhere, there’s a good chance there’s a rabbit hole there. So we’re very careful about those situations and want to spot them early so you don’t get trapped and then it gets hard to get out of them. That’s how I would define, I dunno if David has another take on that.

David (18:23): Yeah, I think a good way to illustrate this is with an example. So we were just recently working on defining a time zone auto completer, so we were building something where we needed to let the users specify the time zone that something was going to happen. There’s a lot of different ways you can specify that. A really fancy way that Apple’s iCal actually use is it’ll do this mapping between, you can type any city in the world more or less and they will do this geo lookup where they find out which time zone that city is actually in and then they’ll auto complete it and they’ll set it up. That’s a really neat solution that’s actually quite technically advanced and complicated and perhaps that’s worth it in some instances where that’s something you do all the time and you pick different time zones constantly and you don’t even know which time zone you’re in.

(19:11): But for what we were working at, do you know what that’s smelled like a rabbit hole to me. That smelled that, if we went down that we would be adding very incremental value to the experience and something that wasn’t going to happen all that often when we could also do something else. We’d also just do a dropdown list. Just do a list. You can do a normal list that’s just alphabetically sorted and you go like, okay, well that also doesn’t quite feel right. Perhaps. I was relaying the example, when I worked with time zones. I often work with two, I mean two different places or Jason is in one place, I’m in another place, they’re sort of stable. So what I normally do is I just have a handful of time zones, I need to pick it. I don’t need to pick against all 180 time zones that could, I don’t even know how many time there is in the world, probably not 180, but there’s a lot of different time zones and mapping those two explicit cities and so on, that was not where the value was.

(20:02): So when you spot that rabbit hole early and go like, wait a minute, we’re making this form. It has maybe five elements in it. One of them is a time zone thing. If you spend all your time coming up with the gold plated geo IP lookup, city to time zone thing, you’re going to spend like five of your weeks on that and you’re going to leave one week for the rest. That’s a rabbit hole. And spotting those rabbit holes up front is a good way of just defining the trade-offs that you can at least anticipate so that the team doesn’t go in and think like, oh, do you know what the bar for this is here. So much of shaping is not just about here’s what to focus on, but here’s what not to focus on. Here’s how we’re going to liberate your attention and your time to focus on the epicenter because we explicitly say this thing, this thing, this thing that’s a rabbit hole, that’s out of scope that could be dropped. Bringing that into part of pitching is sort of that negative space that in many cases are even more important than the positive space of what we’re going to do.

Jason (21:07): We’ve also used the term science project. That was kind of our original term. David, maybe you want to hit on that. That was mostly a technical thing. This is going to be a science project.

David (21:15): Yeah, science project is essentially the macro version of a rabbit hole. A rabbit hole is like, hey, here’s one component of a feature that we’re do it science project is what we actually usually term entire pitches. A good example, I saw someone bring this up in the Basecamp Community project. Someone was asking about tables in our text editor. And we had a project, I think maybe we even talked about it, maybe we only talked about it on the Basecamp community. We worked on it, we totally worked on it, but I don’t think we announced it publicly, but we may have hinted at it in the Basecamp Community and that’s how this person knew about it. Plug by the way, for the Basecamp Community if you want to get that kind of early insight to things we’re working on, but that was an example of something we worked on and we knew going and this was a science project.

(21:58): The whole pitch was a rabbit hole because we knew it was quite complicated to get at, especially in the time zone. I think we set aside like four weeks to do it. We knew it was a science project. We knew there was a fair chance that we weren’t going to be able to deliver, and that’s what happened. We dug into it, spent several weeks and realized, you know what? This is software. You can fix anything. You can literally do anything. We could make the text editor, I don’t know, send a person to the moon. You can change any piece of software into any other piece of software given enough time and resources. We weren’t going to give it enough time and resources within that scope to do it. We learned a bunch of things. That’s the other thing that’s good about these science projects. Sometimes the project or the hypothesis fails to replicate.

(22:41): Do you know what? That’s science. That’s information, that’s feedback, but it didn’t pan out. So we take the science project label is a way for us to mark a pitch of going, do you know what? This is not going to have the same odds of success of shipping as our normal pitches. We know this, eyes wide open. Another word we’ve used about this when we do somewhere between a science project and a rabbit hole is the trace a bullet. We come up with all these terms to describe these. I sometimes think of it as the vocabulary we come up with, and maybe this is even just the urban legend, but Eskimos have eight words for snow. They’re different versions. If you really, this is your work, this is your environment, you will come up with more and more, well jargon to some extent, right? Anyway, tracer bullets.

(23:32): For us, it’s this idea we’re working on a new project product. We’re actually working on a new product right now. We’ve fired multiple tracer bullets where it’s sort of like a pitch, but we’re unclear of even how much this is going to take. We need to do a scaffold version of it or traceable, see where this lands before we can go further. So there’s all these different marks on the probability curve, on the confidence curve in terms of what we start working on, and I think developing, whether you call it tracer bullets in your company or something else, developing an eye for when are we sure about something? When do we have concerns about something? When do we think something could take the project off track here? And then finding ways of identifying that together such that when the team dives in and actually attempts a solution, they have some idea of like, do you know what?

(24:29): You shouldn’t step over there right away. You’re going to fall down the rabbit hole. Do you know what? We don’t really know what the distance is here. Can we fire a tracer bullet? A good way of framing this, it’s like two days. This is often what we do when we don’t know if something’s going to be four weeks or four days, <we’ll call it a spike also>, spike is another word that we’ve used for that, right? Where we just go, do you know what? Dedicate two days to this, see what’s there. Maybe the two days is a loss or it’s never a loss. The two days is just an investment in information. Actually, another example, sometimes I think the examples actually helped clarify this further. We were just looking into what it would take to do billing in other currencies and Anup, one of our programmers who’ve been working on our billing backend that’s called QueenBee, just fired off a trace of bullet. He spent two days looking into this problem. What would it actually take to plug in another way of doing it? And that helped us arrive at it. Do you know what? If we want to do this and we want to do it right, it’s going to take four weeks. Before that, we were like, I don’t know if it’s even doable in a single cycle. I don’t know if it’s going to be two weeks. Now we can make an informed decision about whether to put that pitch onto Betting Table for this cycle.

Kimberly (25:40): Well, David, that is a perfect transition because next week we’re going to be talking about the Betting Table, what happens when all of these pitches are compiled and how things get decided on what we’re actually going to work on. So that will be next week’s episode, so join us for that. I’ll also link in the show notes to ShapeUp we’ve been talking about. You can download a copy of ShapeUp for free at 37signals.com/books. You can also find a link to purchase the book there if you’re more of the type that likes to flip the pages. If you’re a small team, last plug, we mentioned it last week, competing against bigger teams and you’re scrappy, you’re an underdog, and we want to hear from you. If you’ll go to our LinkedIn post, comment with a picture of your team and your underdog story. We’ll be selecting one of you to join us on a future episode of REWORK. REWORK is a production 37signals, so you can find show notes and transcripts on our website at 37 signals.com/podcast. Full video episodes are also available on YouTube and Twitter, oh X, on YouTube and X, and if you have a specific question for Jason or David about ShapeUp, leave us a voicemail at 708-628-7850 and we just might answer it on an upcoming show.