Case Study #4: Products are bets (ShapeUp Method at Basecamp)

Moving from 'planning' to 'bets'

Before we dive into the case study, I want to share about this new format of Productify. 😀

Why is Product Case Study method my biggest bet?

Productify was started for two reasons :

i) To bridge the gap between theory (ideal product practices that product gurus/coaches state in books and social media) and reality (Product Managers finding that cultures at their company that are nothing like ideal and it is extremely hard to make a change). 

ii) To help early stage PMs to grow into senior PM/ Group PM roles - this is one growth stage that many product coaching companies do not address, but forms such a critical part of PM’s first 10 years in product.

So, the biggest bet I am taking in 2022 is that Product Case Studies are going to be the best way to teach product management practices that puts readers and participants in less-than-ideal situations from where they could choose multiple paths and come out of it. In the process, they would also reach closer to ideal product practices.

Hence, for the first time in the Productify newsletter, I am starting with a Product Case Study. I promise the readers that this is just the beginning and case study #1 is just the mirror to what’s going to happen in the future. I will try to spend enough time on focusing on “middle paths” (through a section below) - these are actions PMs can take in their day to day work life that are not too far away from the realities they face at work but will be taking them closer to the ideal state.

(Psst…do register if you’re interested in participating in the case study group discussion, see end of the post)

Let’s begin.

Product Case Study #1: Products are bets - ShapeUp method at Basecamp
Moving from product development ‘plans’ to ‘bets’

Background

The more I observe how product teams are run in organizations, the more I see that at some point at the end of the year, there is “roadmap planning”. This exercise encompasses all dependent teams to work together and come up with a plan to be executed for the next entire year, preferably divided by quarters.

First of all, let us normalize and accept this is what happens in the majority of organizations and there is nothing wrong in acknowledging this. This doesn’t make the organization “a bad product culture organization” because, truth be told, some of these organizations end up being leaders in their space and there is something else (if not roadmaps) they are doing right in their product development process.

One thing I have learnt as a PM is that do not get discouraged by product culture in an organization. Wait, and you will know what that (one thing) organization does really well in order to overcome the other “product culture” shortcomings. In-fact, there is a better way to think about this:

An organization actually has a “portfolio of product practices”. The teams could be great at one product practice or a few and really below average at others. This is completely fine. “Product culture” and “Success of organization”  do not seem to have a cause-effect relationship always. I will talk about “portfolio of product practices” another time. But for now, we are focusing on how teams plan their features or build roadmaps.

What’s currently wrong with making Product plans/roadmap?

Just like in life, nothing is certain for our customers too. Their needs and wants change and we, as product teams, can only guess what they would like or not (i.e aiming for a product-market fit).

So why do teams still create “Objectives”, “Roadmap’ “KRs” for next year when they know (deep inside) plans can change, customer reality can change and there could be internal/external factors that can derail the roadmap?

The answer lies in the fact that “if roadmaps are not ideal for product teams, there should be someone else who values highly-certain plans”. That someone generally is the investor, shareholder or leadership and if you think from their point of view, it makes sense. They cannot go out in the market and say “We could grow 10x next year or 2X or -1X , we don’t know yet”. The outer world doesn’t think in terms of bets. It likes ‘certain plans’ based on which they can make decisions. So the organization discussion within teams goes something like this:

Investor/Shareholder: How much will the organization grow next year? Which areas will you invest in?

Leadership: Let us build projections, plans and run strategy exercises to figure out key areas.

Mid-leadership: We want to grow 5X as per business projections by leadership and corporate strategy. Can you make a roadmap and product feature plan for next year that is aligned with leadership goals?

Product Manager: Sure (while reading Marty Cagan’s how fixed roadmaps are bad)

So, how can a product manager change this? It is a mountain of change. Can a product manager inform leadership - “roadmaps are not useful since they can always change” ? That’s not the case, there has to be a middle path - we will come to it in one of the sections. But let us first define the problem statement of this case study.

Problem Statement

How can Product Managers convey (to leadership) that “all product features are just bets” and these bets can change (when needs of customers change) or be revised (when a bet fails) according to feedback from users?

What are the challenges in moving to ideal product practices?

PMs can often get disappointed by what they see in their organisations. Because either they read product books and newsletters and can’t relate to the realities of their own organizations OR they are overwhelmed by the mammoth task of changing the “product culture” of their organization. Either is not the right approach. You can only make small incremental changes and that is enough.

PMs cannot move from “roadmaps” or “highly certain next year plans” to “hypothesis-thinking” or “product bets” overnight because as I shared in previous section, the problem is not with the product organization but the whole organization has been wired to work in a certain way (and create highly successful organizations still). So, the change has to start within your own scope:

1. Start by changing how roadmaps are planned within your team (it could just be you and your squad - engineers/designers)

or/and

2. Start by changing how roadmaps are planned within set of teams with a common manager (needs a buy-in from your manager and few more motivated PMs)

Introducing ShapeUp Method of Product Development

Before I introduce ShapeUp, I really want to emphasize that, as a PM, you do not have to move to any fancy new groundbreaking way of doing product management - you have to pick up one good thing from a good product practice and try it, and then some more over time. So read the rest of this section with that intent. Let’s get started:

Basecamp caught my attention 4 years back when I finished reading “REWORK” by Jason Fried. I am a big fan of the new and practical product development practices that basecamp constantly comes up with and I am sure many future case studies will feature basecamp. But today, I want to talk about the problem with ‘roadmap planning’ and one such practice (in today’s context) that caught my attention is ‘Shape Up method’ by Ryan Singer.

A bit about Ryan Singer before we dive into the method. Back in 2003, Ryan Singer, as a web designer, was a big fan of 37 signals (now Basecamp). He constantly saw highly loaded and packed website designs around him but he was surprised by the minimalism of 37 signals website (had only text). So when he started interviewing at 37 Signals, he met Jason Fried, who in the final round gave him the challenge to redesign the Verizon website. Ryan got selected.

Ryan, in early days, tried to be a bridge between programmers and designers - he understood both well and hence was trying to bring both together. One challenge that Ryan discovered was that programming was “structured” while designers had to be “creative” but both were working on similar problems around the same set of rules (example timelines). This wasn’t right.

Over the next few years, Ryan and Jason had figured out a way to develop products that shifted the focus from ‘uncertainty of impact’ to ‘certainty of which bets to take’. Once the method had matured, Jason asked Ryan to write a book on (what was then begin to be called) ‘Shape Up’ method.

You can read the whole ‘Shape Up’ book online but let me just briefly touch upon key principles and practices:

1. PMs often either end up at two extremes about ‘shaping their work’ (a discovery phase before a work/feature becomes ready to be presented as a bet and it can be worked upon in a fixed time by the time) - i) Sometimes they will end up defining exactly what requires to be built (for programmers) and how it should look (for designers) ii) PMs end up being too vague, sometimes not defining the scope and loopholes, and leave programmers and designers to work on something that is too fluid and take many shapes.

PMs should ‘shape their work’ at the right level of abstraction (not too abstract, nor too concrete - but using low fidelity designs and texts that describe the bet) and adds it to the set of bets that will go to the betting table. (Image credits)

As an example, below is how a PM could explain user flow - including what PM might see at each step without mentioning the visual elements. This step has been described as ‘breadboarding’ by Ryan in the book.
(image source) 

The bet should have three elements: 1) Problem 2) Appetite (how much time and effort are we willing to spend on this bet given customer and market reality)  and 3) Solution with right level of abstraction

Every bet (that is to be presented) should have a Payoff  i.e If we dedicate x weeks to building it - we should know we deliver y impact.

3. ‘Betting table’ is a period of two weeks where key stakeholders (mostly senior) take a call on which bets (out of the ones submitted by PMs) should be build in next 6-week cycle. The accepted bets are announced and programmer/designer/leads are assigned to that bet and then 6-weeks are given to build and launch/test.

(Personal Note: 6-weeks shouldn’t be taken too seriously. 6-weeks worked at Basecamp but it could be 4 weeks or 8 weeks or something else- depending on what works for your organization. This is an antithesis to how sprints work. The logic is that 2-week sprints are hardly enough to ship out something meaningful and hence committing the whole team to a bet and then not distracting them for 4 to 8 weeks is better than doing ‘sprint drama)

4. After ‘building period’, ideally the bet should have been delivered to customers with defined success metrics to validate. If it has not been delivered, then the bet needs to be re-presented in the next ‘betting cycle’ so that the call can be taken whether to pick it up again or kill it.

5. After the building period is over, there is a cooldown period (2 weeks) During this period, each team member (PM, designer, programmer) have their own personal backlog and they work on it (could be improvements, mock-ups, bugs, tech-debt etc.)

6. Most importantly there is no central backlog. Every team member has their own backlog.

In summary, the whole process has 3 steps:

1. SHAPING → Team members that work on giving shape to their work and present their bet.

2. BETTING TABLE: Seniors choose which bets to build on for next 6 weeks (or x weeks)

3.BUILDING: Programmers and designers come together to build and launch the bet.

How is ‘Shape Up’ method different from the regular roadmap planning method?

1. There are no yearly plans. Every 6 weeks, there are new bets on the table and most promising bets are committed to, for building.

2. Teams are empowered to build their own solutions since ‘bets’ do not include solutions and only have a limited abstraction.

3. Teams are not distracted for 6 weeks since they only have to work on 1 bet (per team).

4. Tech debts/bugs/improvements are taken up in a 2 week cool down period. If there is a serious bug/tech debt/improvement, then it can be brought to the betting table to dedicate more time.

Middle paths for PMs (Choosing your battles)

Now, as a PM, you should not go to your management and say I want to introduce ‘Shape up’. But you can start with below three middle paths:

1. Within your team, divide time to work on ‘promising features’ (call it ‘BUILD’ period) and then another period ‘COOLDOWN’ for working on ‘tech debts/bugs /improvements’ - could be a 80:20 split. Example: Build period could be 4 weeks and Cooldown could be 1 week. Choose what suits you.

2. Instead of sprint planning/backlog grooming , meet after every ‘BUILD’ period and decide what should be next promising features to work on (for next ‘BUILD’ period) and what bugs/improvements to work on in the ‘cooldown’ period.

3. Instead of presenting a 100% foolproof roadmap to your management, present all features as bets.

Example:

Feature 1 - Q1 - 80% of success
Feature 2 - Q2 - 50% of success
Feature 3 - Q3 - 90% of success
And so on..

This is a good way to make your management curious. Once they ask ‘why do you have percentages of success’ you have your chance to explain why these features may or may not work given complexities of customer need, resource constraint and others.

In the meantime, if you’re curious how other companies are implementing ‘Shape up’, you should definitely go through Shape Up Forums  and check the discussions going on.

Takeaways

1. Roadmaps give a perception of ‘we know what we will do next year’. But we should change the narrative to ‘we know which bets we are taking next year - some may succeed some may not’

2. Instead of running 2-week sprints, run ‘BUILD’ and ‘COOL DOWN’ periods. Decide BUILD period as per what suits your organization.  2-week sprints is not a must. I have observed that sprints are never questioned and assumed to be the ‘right way’ to do development.

3. PMs should work at the right level of abstraction - don’t tell your team exactly what needs to be built nor be too vague and leave too many directions open.

Open questions from this Case Study:

1. How is roadmap planning done at your organization today?

2. Does your team/organization understand that features are just bets?

3. If not, how can you take micro-steps to create awareness around ‘hypothesis-oriented thinking’ or ‘thinking in bets;?

4. Is a 2-week sprint cycle working for you? If not, how many sprints does it take for you to launch a meaningful feature?

5. How detailed do you become (as a PM) when giving problems and solutions to your team?

(Note that all of my publications are self-writings and do not reflect my employer's views )
—--------------------------------------------------------------------------

👉Register here in case you would be interested in Group Case Study discussion on ‘Moving from plans to bets’. Depending on the level of interest, I will soon announce dates for the session.

Follow Productify on Twitter for daily product tips.