House
/
Blog
/
5 Rules I've Learned for Executing Shape Up

5 Rules I've Learned for Executing Shape Up

When Shape Up goes well, it's a brilliant process. However, things haven't always gone well. Those stumbles and failures have led me to 5 rules for success with Shape Up.

5 Rules I've Learned for Executing Shape Up

I got introduced to Basecamp's Shape Up about a year ago. I admit I was skeptical at first. We had been through several different iterations of "project management" as a company and I had never really been happy with the results we got from any of the tools we used. However, once I read the book I was a believer. I loved the approach and felt like it really resonated with me. I launched into shaping after reading it and haven't looked back since. I've been very happy with the process and the results I've seen when things go well.

 

However, things haven't always gone well. Those stumbles and failures have led me to 5 rules for success with Shape Up. They can probably be applied to any approach to work more broadly, but they fit especially well within the context of Shape Up. I'm going to give you a rundown of my 5 rules and provide an example at the end of how they come together.

 

Rule 1: Say no to almost everything

 

This is the first rule because I believe it is the foundational principle that makes Shape Up work. You have to be methodical about doing this. The book calls this point out explicitly (https://basecamp.com/shapeup/1.2-chapter-03#responding-to-raw-ideas), but I feel like it’s either way too easy to miss or so contrary to human nature that it needs much bigger, bolder text or even its own chapter. (Incidentally, I just wrote about the importance of the word no and getting into a habit of saying it here: https://www.g2i.co/blog/use-your-no-to-guard-your-yes.) From what I’ve seen, it’s way easier to opt-in to ideas and features than to opt-out in the planning stage. New ideas to solve the problem come quickly and are easy to be excited about, but cutting down ideas and features is hard. The problem is, it’s the exact opposite at the implementation stage. It’s infinitely harder to actually build something than to not build it. Getting into the habit of saying no at first corrects this asymmetry. I've worked to make the bar to say yes to an idea almost as high as the effort required to build it. 

 

Rule 2: Shaping should involve 1 or 2 people max

 

Our most successful shapings were done with 1-2 people. I can’t think of a shaping that was successful when it involved too many people too early. Committee shaping just doesn’t work. This is also stated in the book (https://basecamp.com/shapeup/1.1-chapter-02#who-shapes), but I saw that it was really hard to stick to at times. Again, I think this was a point that should’ve gotten more emphasis. The thing is, ideas need owners. There has to be someone that has a clear vision and accountability for the decisions being made. When you have lots of people in shaping there are too many voices, no ownership, and no accountability. It’s a lot easier to say no to yourself or to one other close collaborator than to 5 people. It’s also a lot easier to be in sync with yourself or one other person than 5 other people. All of that is essential for shaping to work. 

 

Only once you have the core shaping done should you bring it to a wider audience. At that point, it’s all about poking holes, not about adding new features. You have to be the owner of the shaping and say no to anything that goes against the core vision. Be open to holes being poked and realizing where your assumptions were wrong, but don’t compromise on the core principles. Don’t add anything new, just take away what doesn’t need to be there. 

 

Rule 3: Think in bets, not estimates

 

You have to start thinking like a bettor. We used to do estimates and what I've seen from a lot of people used to "agile" is that they are comfortable with estimates. They live and breathe estimates. Any time they see work to be done, they start by estimating it. I am convinced this is wrong.

 

The reason I'm convinced is that I've seen first hand projects that have gone over the estimate. There are 2 outcomes: it either goes a little bit over or A LOT over. There is no in between. Overages in projects live in a domain known as fat tails. In the world of fat tails, rare events have huge effects on the properties of the distribution. For a simple explanation of this concept see Nassim Taleb's video here: https://www.youtube.com/watch?v=t7Fr6iGhmBM&ab_channel=NNTaleb%27sProbabilityMoocs

 

Essentially, this means your estimates are useless. They aren't giving you information. They lull you into a false sense of confidence when starting a project. Then you get to the end of the estimated period and you're not done, but you figure you might as well finish it due to sunk cost bias. So you re-estimate and keep going. Rinse and repeat until 9 months later you're still not done, you're way over budget and you wonder how the heck you got here (By the way, that was my real takeaway from Andrew Wilkinson's thread a couple of weeks ago https://twitter.com/awilkinson/status/1376985854229504007).

 

Betting is a totally different approach. Betting starts by focusing on outcomes and asks "how much would I be willing to wager and how much would I have to be paid in return in order to make a bet on this outcome?" For example, I could offer you a bet: flip a coin, heads you win, tails you lose. The cost and payout structure of the bet are going to determine whether you want to take it or not. If you win $1 for every $1 you wager, it's probably not worth it. If you win $2 for every $1 you wager, it's more attractive. If you win $1 for every $2 you wager, you'd probably tell me to take a long walk off a short pier. That's the root of thinking in bets. What are the outcomes? What are the payoffs? What will it cost me?

 

When it comes to shaping, this is where you have to start. What are the possible outcomes of building this thing? How much am I willing to wager in order to take the bet? You should only wager as much as you're willing to lose. If you would be upset about losing the time and money with no ROI, then that's a bet you shouldn't be taking. Decide what your limit for the bet is upfront. You also need to define what success is upfront. It needs to be a falsifiable statement, something like "We expect X results within Y time period." It either happens or it doesn't, there is no middle ground. By structuring your bets this way you create a level of rigor in your decision making and force your ideas to prove themselves in the real world. Either the bet will succeed or it will fail. When you start to approach it this way you will find yourself getting more conservative, which is good. You're making bets on smaller concepts and forcing them to be proven before you dedicate more resources to them. That's exactly what you want to do.

 

Rule 4: Use the Alpha/Beta/1.0 model to help with scope hammering your bets

 

I came up with this model while struggling with the ambiguity of ideas and how to get started without getting overwhelmed. Working in this model has helped me scope hammer effectively and create bets I'm comfortable with taking. This framework is all about taking an idea and subdividing it until you can’t anymore. Once you get to that stage you have the elementary principles. You then start testing those principles in the real world and building up your bets over time.

 

The first stage is Alpha. Alpha is all about picking the most important elementary principles without which nothing else could work and then proving those. Shape the simplest way to prove that those elementary principles will work in the real world. This is where you do things that don’t scale and accept messiness. You build things that you will probably scrap later. That’s fine. This is about proving that the core idea is viable.

 

Beta should only be undergone if Alpha is a success. You’ve proved the core concept, now you need to see if you can do that same core concept in a way that is sustainable. This is where messy code gets re-written. Manual intensive processes need to be replaced with ones that require less effort. You want to answer the question: Is this something that can be taken to a wider audience? You’re still not adding anything new here. All you’re doing is trying to replicate Alpha’s results at a larger scale with effort that doesn't scale at the same rate as your growth. 

 

If Beta succeeds, you can move to 1.0. This is where you now have something validated in the real world. You’ve proven that you can do the core concept in a way that scales. Now you want to keep getting your effort curve to go asymptotic in its relation to growth while starting to test new additions. Any new features should go through a similar Alpha/Beta/1.0 cycle. Make your ideas prove themselves in the real world before betting on them. This lowers the risk and ensures that when you do go all in, you have a really solid thesis for doing so.

 

Rule 5: Shaping takes longer than you think

 

Shaping is an organic, evolutionary process. It is trial and error, tinkering. I’ve done shaping work that took 6 months of my CTO and I going back and forth. Ideas were created, edited, thrown out, brought back, edited again, thrown out again over and over until we got to a place where we were happy. 

 

Sometimes a deadline cannot be avoided. If you are being forced to shape on a deadline, the number one thing you can do to improve the quality of the final shaping is scope hammer. Cutting things down to the essentials brings clarity and makes decision making easier. You want signal, not noise. As Basecamp says, you want half a product, not a half-ass product.

 

A Practical Example 

Recently we decided to start shaping a mentorship program for the developers in G2i. The seed came from seeing how many developers were joining G2i, applying for jobs, and struggling to convert those applications into jobs. When we started to dive into the client feedback and look at things closely, we came to the conclusion that some developers needed guidance on things like interviewing, setting their rate, and communicating their knowledge in a way that inspires confidence. We thought the best way to address this would be to pair developers who have already found jobs in G2i with developers who are still working towards that. The members with jobs could help those who are searching maximize their chances with practical advice. 

 

The first thing we did was establish the team that would do the shaping. It was decided that it would be up to Dylan and me to shape the plan. We started out by dreaming about what mentorship could become. Things started to get really big and heady and we had a lot on the table. That's when it was time to start saying no to things and to introduce the Alpha concept. 

 

We scope hammered mentorship to get to the core problem: How do we help developers who are struggling to convert applications into jobs? From there, we worked on developing our success criteria, what would we have to see for the bet to be considered a win. The most elementary core concept we had to prove was that we could make mentorship happen. It could be messy and imperfect, but if we can get some developers mentored and on jobs then we had a basis for continuing to bet. Our success criteria ended up being to complete 5 paid developer mentorships by the end of the quarter.

 

Next, we had to settle on what resources we were willing to wager in pursuit of this outcome. We decided that Dylan should own the execution so his time and energy were put in. My time and energy was also put in, though to a lesser extent. Finally, we said we were willing to stake up to $10,000 in mentor incentives to test this out. Mentors would be paid only if their mentee got a job. That number arose from what had already been approved in the budget and what we felt was worth it based on the success criteria.

 

Now, we had our Alpha concept. We also briefly sketched out what Beta and 1.0 would look like. Beta is about trying to scale the program in the same time frame, something like 25 completed mentorships in 1 quarter. 1.0 is about pushing that further and expanding the scope of the offering in some other areas we believe will be valuable. Ultimately, it's not finished and doesn't need to be until Alpha is complete. 

 

With those details settled it was time to execute. Dylan got started on an initial plan and I let him run with it. My goal was to stay out of his way and let him take ownership and accountability. We didn't set deadlines for this part of the work as it was very early and we were in exploratory mode. By structuring it this way, Dylan was able to have some great conversations with members of our collective including John Bailey and Tracey Goguen. This helped to point him in the right direction. If we had tried to impose deadlines at this stage or if I got too in the way, those things would not have happened.  

 

That's where we are today. We're still shaping it while testing concepts in the real world. We feel safe with the bet we've made since it can't run over. We're not going to spend more time, energy, or money than we've already allocated. We'll see how the results play out over the next 2 months, but the process to get here has been a great success.

 

If you've struggled to get results you're happy with while using Shape Up or any other system, I would encourage you to try out these 5 rules and see if they help. We're going to continue testing and refining them to build a process that we can consistently replicate. 


React

Looking for the best pre-vetted developers?

We have React, React Native, and Node.js developers available on a contract or full-time basis.

Group

Related Articles