I’ve been seeing a lot of Shape Up popping up on my LinkedIn feed recently. I even took part in a short discussion and received messages asking me to talk about my experience. Having tried Shape Up myself in 2020, I’ve always wanted to share my point of view on the framework, and specifically, why I think you should not simply copy-paste it into your org.
Overall, I think Shape Up is great and it helped me get out of a crisis I got my product org into. Here’s a short story how it happened. It was early 2020, the beginning of a year. Our current ways of working could no longer handle the complexity of our products and growing organisational structure. We finished planning Q1 well past the middle of Q1. On a cold January evening, I had a sobering realisation: our planning was derailed, and the team was unlikely to deliver anything meaningful by quarter’s end. Everything was going sideways. I sent a frank, transparent message to my five co-founders telling them we won’t make it and set out to fix this mess.
It took me some time to research alternative ways of running a product org while simultaneously putting out fires. I met with product/team leaders, re-read some of my books and eventually came across Shape Up by Ryan Singer and 37signals. It was enlightening and quite an emotional experience. It felt as if all the answers were there.
I knew Basecamp was a different product to ours (Packhelp is a packaging e-commerce/ marketplace), I knew their culture was different too. Therefore, I took the best parts of Shape Up and came up with our own version of it. I took time to prepare our own process manual in Notion, collected some feedback and deployed it in a pretty organised way. Despite that, and this is something I had anticipated, it took us at least three cycles (6 months) to be running smoothly.
There is a lot of seriously good stuff in Shape Up: 8 weeks-longs cycles, setting the appetite, integrating one vertical slice at a time, hill charts, rabbit holes, cool-downs, bug smashing, prioritising affordances before pixel-perfect screens. I encourage everyone to read Shape Up. It’s inspiring, it’s easy to read and it gives hope.
On the other hand, it’s not for everyone. It’s tailored to 37signals way of operating, to their leadership structure and type of products they build. Let’s focus on their unique characteristics first.
- 37signals built Basecamp without VC and achieved amazing product-market fit. Not many companies can genuinely claim they’ve achieved PMF by Silicon Valley standards. It’s a different game you are playing when you are searching for PMF and once you have it. 37signals built a healthy company, earning more than they burn. There was no one pushing them to go for the enterprise. There is no runway, there are no fund lifecycles, there is no pressure to run after crazy numbers.
- They keep it small. Jason and David are (still) very much taking an active part in Betting Tables. In 2025, 37 Signals is approx. 80 people. There’s no middle-management.
- They build products they use themselves. If your situation is the same, you’re lucky. If you ever worked in JIRA (and hated it), you probably know how it could be improved. Not everyone is so lucky. This has huge influence on how you operate, who you hire (for example Product Managers) and how engineers operate.
There are more unique features of 37signals which are reflected in Shape Up. Today, however, I want to bring your attention to certain parts of the framework which will cause issues if you simply try to copy-paste it into your org.
- Scalability — I do not believe Shape Up “scales”. One of the bottlenecks are Betting Tables which require leadership to take part in them. As the organisation gets bigger, there many more leaders and important stakeholders who influence what gets built. As these meetings grow, they become inefficient and hard to manage. They also become boring. At larger orgs, the leadership tends to focus on discussing higher-level outcomes, rather than detailed pitches. What also happens at larger orgs is that people complaint about the org becoming less transparent, decisions being made behind doors. You’ll end up with a dilemma whether your Betting Table should be open, and if not, who should be excluded.
- Small teams — At 37signals, projects are typically assigned to just two people (occasionally three: one designer and two engineers). This approach works because collaboration in pairs is inherently more efficient and straightforward. If you’ve ever played tennis with more than 4 people on the same court, you understand the chaos that ensues. Consider the simplicity of a two-person team: when it’s just you and me working together, we can easily a) schedule meetings, b) hold each other accountable, c) adapt when needed, and d) divide responsibilities clearly (if I’m not handling task X, you must be responsible for it). With just two people, there’s only one relationship to manage. Add a third person, and suddenly you’re juggling three different relationships. With four people, it jumps to six relationships. With five? Ten different relationships. The coordination complexity doesn’t just increase—it multiplies with each additional team member. This exponential growth in communication overhead explains why larger teams of four or more people typically require more structured processes and coordination mechanisms to remain effective.
- The genuine full-stack skillset — When I researched Shape Up in 2020, I looked up the people working on Basecamp. I discovered that all of the designers there were able to code. They actually wrote production code. This is exactly how me and Arek, my co-founder and CTO, worked in early days of Packhelp. Arek would prepare data endpoints and I would take these endpoints and both design and wire up the UI. But how many of us have teams like that? Not many. I imagine there are ways around this problem but you might want to read Shape Up again and consider where this might cause issues (because it will).
- Product Managers are not needed — The reason for this boils down to the uniqueness of 37signals. First, it has a strong PMF and no VC. They got nothing to prove to anyone but themselves. They don’t need (or want) to support enterprise. They make enough money to thrive. It comes down from the top. Second, the leadership is very much involved in product decisions. Third, almost everyone at 37signals is their ICP (Ideal Customer Profile). They use their own products, and, as a result get ideas how it could be improved. Their customers are like them (small companies), they all speak the same language. Consider if it’s a different story for your team and the product you are building.
- Quality as virtue — Imagine you could hire the best people out there. Pick anyone, who you admire, and assume you have enough money and are interesting enough to have her/him join your team. Talent is everything. You won’t build a great product and an amazing company with mediocre people. In case of 37signals it’s safe to assume that the code and work people do is of top quality. This means less bugs, more stable infrastructure, less time spent fixing. If you struggle with bugs and don’t know why — Shape Up won’t fix it (it might actually worsen it). Figure out the reason(s) for buggy delivery first.
- Autocracy — The product is led by Jason (CEO), David (CTO), and influenced by Ryan (back in 2020), who was their Head of Strategy, not a product person. They have no CPO, no Head of Product, no PMs. It’s them who decides at the Betting Table. Sure, everyone brings initiatives, prepares pitches but it’s up to them. Consider, in your case, who is going to be taking part in Betting Table and whether that person has enough agency to make these decisions.
- The circuit breaker — This is a controversial topic. Say you were developing a feature you set appetite to six weeks of development. You didn’t manage to launch it on time. At the very end, you realised that the external API got updated and you need to refactor some part of your backend to make this feature work in production. This is going to take three to five days. There are most loyal customers waiting for the feature and they told your Sales people they won’t renew if it’s not there. In Shape Up, you drop the feature. You’ve over invested, underappreciated complexity, the circuit breaker goes off and the manual tells you to drop it. You have the opportunity to pitch it again, after you rethink it but it’s going to delay it by months. If you ask me, I am not 100% sold on that idea. I understand the reasoning behind it, but it also stems from the fact that 37signals perceives less pressures: money flowing in, no runway, no VC. It’s not like that everywhere.
These are the key areas that come to my mind when I recall working with Shape Up. I hope you consider this when trying it out at your org. I believe it’s worth reading Shape Up at least twice. Once to get excited, second time after you did your research. Lenny recently published an episode of his podcast with Ryan Singer, talking about, you guessed it, Shape up.
If you found this interesting or would like to know more, let me know!
