Implementing Shape Up: A Case Study

There was a time in late 2018 where we were having real trouble shipping the things we had planned to ship within the timeframe we’d estimated. I remember a particularly gnarly project where we wanted to enable our users to book multiple spaces within a given location – instead of being able to book just one space per location at a time. What we’d originally estimated to take roughly 3 sprints ended up taking around 5. Some people on the team will still shudder if you mention “multi-space bookings”.

For context: At store2be, we’re building a platform where brands and live marketing agencies can book promotion spaces in physical locations such as shopping malls, train stations, universities, airports, public spaces and more.

Since then, we’ve started to implement Shape Up – a product development framework developed at Basecamp and put into writing by Ryan Singer a few months ago. For the purpose of this post, I’ll assume familiarity with the framework. If this is your first time hearing of Shape up, you best get started by reading the book (online or PDF) or by listening to some of the podcasts linked here.

In its entirety, Shape Up can seem intimidating. It’s so very different from the Scrum/Kanban/Scrumban way of working that most tech startups are used to – sprinting 2 weeks at a time – that a very common response to it is: “Sure, that might work at Basecamp, but there is no way this could work for us, because …”. I disagree wholeheartedly. After my experience with the framework, there is no reason why Shape Up should not work for your team. Ryan even provides explicit guidance on how to adapt the framework to different scales. But in the end, the purity of Basecamp’s Shape Up implementation is impressive yet intimidating. After all, they’ve created this way of working over the course of 15+ years. They should have mastered it. Yet from the perspective of someone stuck with 2 week sprints and endless backlogs, it is very hard to believe that there does exist this magical place where all works out just as Ryan describes it in the book.

That’s why I want to offer some encouragement to anyone thinking about implementing Shape Up, or already en route. We’ve started to adopt the framework since early 2019 and overall we’re extremely happy with the results. But the reality of our implementation is still messy and far from the pure Basecamp way. It’s a work in progress. And I think that’s ok. So in the following sections, I’ll share some examples of the guidance that Shape Up gives and how we’ve adopted things in practice for now.

6+2 Week Cycles

The most notable difference of Shape Up – at least from the outside – is that projects are typically run in 6 week cycles that are buffered with 2 weeks of cool-down (to tackle bugs, regroup, decide on what’s next …). We’ve adopted this cadence 1:1 from the book and this was probably the easiest thing to change for us.

From a Product Manager’s perspective, the biggest positive change is having more time to think about and spell out what’s next. This fact alone has allowed us to be more considerate and intentional about the things we build. For example, I’ve since run two internal Design Studio workshops to gather input on problems, as well as an external workshop involving both customers and partners. I’ve been able to plan dedicated discovery projects while the 6-week development projects are ongoing. Before, these very deliberate discovery activities had usually gotten lost in the busyness of managing sprints. I think it’s easy for PMs to mistake sprint planning for “figuring out the right thing to build”. It feels like you’re planning what you’re going to build, so you must be intentional about the product work. That’s not true.

From the perspective of the team that’s building the software, the biggest improvement is in having more time to build momentum and get ingrained with the purpose and context of a project. When you’re sprinting, you’re literally heads-down all the time. It’s just about ticking off as many tasks as quickly as possible. In that context, I don’t think most developers (can) care a lot about what a task is really about from a functional product and user perspective. With these 6 week projects (and the format of the pitch), in contrast, the team gets to understand the problem they’re going to solve. From what I’ve heard, the developers on our team appreciate this very much and motivation has taken an upswing.

Still, there are things we’re struggling with. The biggest bottleneck is actually building that momentum which the 6 weeks promise. In our company, it still happens that developers get pulled away a lot “to just check out this issue really quickly”. We also have a rule in place where programmers work on bugs while a cycle is ongoing. Those bugs are tracked and assigned by QA and the team currently feels like they cannot not work on any bugs for 6 weeks. That feeling has only grown after we’ve run into cool-down with some cycles and thus had to cut that short. Ultimately, though, stripping away some excess things pulling at our developers’ focus feels like the biggest lever we still have to improve our output.

Another thing we seem to find difficult: Anticipating the deadline and making decisions and trade-offs as quickly in week 1 as in week 6. For all 3 past cycles, I can remember the hectic of the last week. People start to realize at last that they’ll need to ship in 5 days. Trade-offs are being made – usually great and pragmatic trade-offs. I wish we’d start cycles with that spirit of pragmatism and not only end them in this fashion. And actually, two out of three cycles ran into cool-down. One slightly, one significantly. Besides our missing willingness to make trade-offs on day 1, I think we also don’t yet have a strong muscle for knowing what we can realistically build within 6 weeks. It seems we’re not yet leaving enough space for discovered work and we’re not anticipating that things will be harder than they seem. But we’re learning and have started to double-down on “de-risking” a project before it is actually taking on. Early results of that look promising. This is mostly a shaping issue.

No Backlogs, But Roadmaps

Basecamp prominently maintains no backlog, and as far as I’m aware, not even a roadmap or (explicit) vision for where the product is headed. While we’ve also gotten rid of our backlogs (?), we still have roadmaps for each of our three products.

I have to say: Not having a backlog is a liberating feeling. Before Shape Up, I would regularly “groom” the backlog and assign values to tasks for their impact, difficulty and other lofty guesstimates, trying to find the perfect order of what to do first, second, third … and 131st. But I didn’t plain remove the backlog. I leveraged the information that was in it at least to some degree, by grouping tasks that seemed to tackle a related problem as subtasks under more abstract “themes” like “Improve the briefing form” or “Enable better project management” and then put them on a roadmap. Not a time-based GANTT-style roadmap, but a simple board of “Now | Next | Later”. Most themes landed immediately in “Later” and, to be honest, I will probably let some of them go.

This roadmap board has since evolved to include the following columns, from left to right:

• Done (under evaluation): Projects that were completed; we’ll usually write a brief report on the outcomes once significant time has passed (6-8 weeks after go-live).
• Now: Projects that are part of the current cycle.
• Shaped Pitches: Links to pitch documents of shaped pitches that are either currently submitted to the Betting Table or that I am thinking of submitting in the future.
• Next: A handful of ideas that I want to shape next.
• Later: A rather large collection of ideas that I want to keep a record of, but not think about at the moment.

The roadmap helps me have conversations with different parts of the business, like sales, marketing and operations. It helps sort feedback from our customer-facing teams and keep track of issues that keep reappearing. It also helps those team members that submit feedback feel heard because they can see that their feedback task is added as a subtask to a theme on the roadmap. When it’s then time to act on a theme, there are already a few starting points to go deeper into research and a few people to talk to in more depth about a given problem.

In combination with more time to think and running meaningful projects of 6 weeks, the spirit of not having a backlog adds to a feeling of: “We’re now doing this, and we’re getting it done. Afterwards, we’re free to do whatever we deem most important then.” It’s antithetical to the iterative nature of sprints where you’re constantly thinking “I can always come back to this later”. A common phrase in our team was “Let’s just build the v1 of this – we can then improve the UI in v2 later.” Thing is: especially for internal-only tools, this v2 never really happened and we ended up with some Frankenstein “v1 UIs” in different places. Now, we’re more focussed of finishing projects in a state that we can be proud of (or at least live with) for the foreseeable future.

The Betting Country Club

Formally, we have two betting table meetings. One during the first week of cool-down that we call “What’s on the table?”. We have another meeting in the week after that where we make a final commitment for the next cycle. The people involved in these meetings are: Our CPO and CTO, our two most senior frontend and backend developers and us two PMs.

In the first meeting, the stakeholders go through the submitted pitches briefly and discuss open questions, share opinions on strategic direction and so on. The outcome is usually a list of projects that we’d like to do, along with some clarifications regarding the scope of those projects, team availability or potential project allocation of team members.

In the second meeting, answers to those open questions are presented and the room usually lands pretty quickly on a commitment for the next cycle. Team members are assigned to projects and the PMs can schedule cycle kickoff meetings with the developers and designers that they’ll be working with.

That’s the formal side of things. The truth is, though, that at least the big batch project(s) for an upcoming cycle are usually discussed and decided on before the formal betting table meetings happen. For example, I regularly speak with our CPO about the direction that we want to next take the product in. We discuss proposals that I have, for example balancing features that make the product wider vs. deeper, and align on the strategic direction for the next cycle. I then take this guidance and discuss it with other stakeholders that need to be aligned around those projects: our CEO, COO and CMO. The true decision about strategic projects is made as soon as these stakeholders are onboard. The Betting Table then is mostly a formality and concerned with fitting projects to people.

As a result, for example, it’s pretty clear we’re going to spend the next two cycles focussed on building out the booking process on the platform. I still have to shape the work for the second cycle, but I’m confident that the shaped project will then get picked up and worked on.

I think it’s totally fine that we have this political process which supersedes the formal betting table. What matters is that we’re intentional about the things we are building, which we are. In addition, the process we have has helped spread an anticipation within the company for what the Platform team is going to work on. By discussing ideas early and broadly, it has moved our team closer to the rest of the organization.

Still, there are certainly things we can improve here. At the core, our Betting Table does not really contain the deciders. That’s why the political process is necessary. I think within the PMs & CPO, we’re somewhat afraid to let “the business people” decide what we’ll build next in the products, based purely on pitch documents. That naturally hamstrings the betting table meeting and downgrades it to a resource planning meeting. The people inside the formal betting table are aware of this fact, though, and there’s general willingness to include the business side alongside in the betting table. Looking ahead, we might temporarily end up with a fairly large round of people in there and later shrink it down to just the “true deciders” once everyone feels ready to do so.

Design Frenzy: PM Copywriters, UI-only Designers, Frontend Engineers

In Shape Up, Ryan explains how Basecamp usually staffs two programmers and one designer on a project. The thing is that their designers aren’t what the industry typically refers to as a designer, at least in my understanding.

When a designer at Basecamp gets started on a project, they start stubbing a UI in un-styled HTML to figure out the affordances so that a programmer knows what endpoints will be needed and in which format, for example. As the project progresses, they then start structuring and styling the UI in its final form.

When a designer on our team gets started on a project, they start converting fat marker sketches or wireframes into high-fidelity design files in Figma. These Figma designs are then input to a frontend developer on the team, who takes them and starts building the final UI. It is our intention that the designer creates those designs with technical feasibility in mind, so that we don’t end up in a position where we have fixed time and fixed scope. At the same time, frontend developers are encouraged to give early feedback on designs and work with the designer to iterate over the Figma files.

The goal is for the designer to come up with a design that fits within the scope of the cycle and can be picked up by a frontend developer without the need to change many things. At the same time, we’ve always still made trade-offs and changes on designs in the coding phase, like deciding not to build a new dropdown-button component which would look better but take too much time and instead going for a simpler version of two buttons side-by-side.

This process – integrating design work (as we see it) into a cycle project – is one we’ve yet to come to terms with. So far, we’re very happy with the user interfaces we’ve shipped. But the final product almost never resembled the design files 1:1, to the dismay of the UI designers. And the back-and-forth between designers that own the UI look-and-feel and frontend developers that have to build it all was always stressful. Not to mention product managers who act as copywriters.

My best guess for what’s still broken in this process is that we’re piling on too many integration problems. Product managers, who come up with the fat marker sketch or breadboard, have to integrate with designers, who come up with the designed UI and have to integrate with frontend developers, who finally have to integrate with backend developers. When changes to the pitch document are made as a cycle is ongoing, for example through scope cuts or refinements, there is a ripple effect throughout the chain outlined above. Depending on how far the cycle has progressed, the designer won’t have time to reflect the scope cuts in the design files. Then programmers don’t have a source of truth anymore for where specs are coming from: the pitch document or the design file? That has been an issue in every cycle we’ve done so far.

That said, there are some benefits to the design role as we have it and that I’d be hesitant to give up. Our designers do not just work on the delivery track, but also join PMs in discovery projects (when they are currently not on another project). They can sit in on customer interviews, help facilitate workshops and then be sparring partners to the PMs when it comes to shaping an idea. They can also create interactive hi-fi prototypes to help validate an idea in discovery (something I believe Basecamp does not see any value in). Those hi-fi prototypes are also a great tool for PMs to get stakeholders and other teams inside the company excited about an upcoming development project. For us, they have proven to be a useful tool this way.

In any case, I’m starting to believe that the way Basecamp has defined their role of a Designer is one of their “unfair advantages”. By essentially having designers be experts in UI design, copywriting and frontend development, they eliminate at least two integration problems that other teams with more traditional UI designers have.

Product Managers who Project Manage

In Shape Up, projects are given to self-organizing teams. They alone are responsible for shipping some version of the pitch by the end of the 6-week-cycle. Before we started our transition to Shape Up, the role of a PM on our team was very much focussed on delivery management. We were entirely guilty of using PMs as project managers first and product managers second. The order of responsibilities has since been reversed, but the project management aspect is still there.

To give you an example of the routines that us PMs have while a cycle is ongoing:

• We participate in standup meetings with the team (usually every other day).
• We are set up and are an active part of the projects in our project management tool (we use Asana).
• We monitor the project team’s Slack channel and regularly participate.
• We clarify questions on tasks or the pitch document (which lives as a Google doc).
• We set up and participate in design review meetings between designers and developers.
• We remind the team to update the Hill Chart (if we’re using it) or write regular project updates.

Before Shape Up, all of the responsibility for the shipped feature was with the PM (in terms of functionality, look and feel). At that time, we also had no designer and were filling the role between product management and frontend engineers. It was common and accepted for developers to say: “But that wasn’t how you specified it – guess you should’ve been clearer in the specs!” Coming from such a place, I guess it’s a massive change to put the responsibility for the complete project within the hands of the builders. This is change that is hard on everyone involved:

• PMs fear losing control and that the team won’t do as they would.
• Developers feel like they’re making decisions they shouldn’t.
• Designers feel that developers aren’t implementing what they’re putting on the screen (because they are not involved with coding).

We have quite some work to do here and I think this is the hardest shift to make because it redefines so many roles at their core. It changes the basic day to day behavior of all people on the team.

Parting Note on QA & Bugs

We still work on bugs continuously. That should probably change, but we’ve also messed up cool-down quite frequently by running slightly longer. Mostly that was because we haven’t yet found a good way to include QA. Oftentimes there were very few days left at the end of a cycle and things still hadn’t landed on the staging environment for our QA engineer to review. Something I’d like to suggest to the team in an upcoming cycle is to try and build more in orthogonal scopes, as well as starting in the middle.

Summary & Outcomes

If you’re thinking about implementing Shape Up or are already underway, I hope that this blog post can provide some perspective on the messy reality of product development work. While there are still quite a few kinks we have to iron out, the current outcomes make Shape Up a unequivocal success for our team:

1. We’re shipping what we intend to ship, when we intend to ship it. This is the most direct impact of adopting Shape Up as a delivery technique.
2. That leaves more mental capacity to think deeper about the right thing to build. Shape Up therefore has an upstream effect on our ability to run Product Discovery.
3. In general, we’re learning more systematically. For each of the past three cycles, I can clearly reflect the things we struggled with and why they were a problem. We might not always nail the improvement in the next cycle, but being able to point at the problems is a great starting point.