How we Doubled our Product Releases by Adopting Shape Up

Is the software you’re building delivering the most value to your customers? When we asked ourselves at UserVoice this very question at the beginning of 2020 we weren’t proud of our answer. Realizing (and admitting) we’d failed to maintain focus on one of the most important goals of any software organization was the harsh wake-up call our organization needed. One that prompted us to make drastic changes like throwing our backlog in the bin, saying goodbye to SCRUM, and adopting an entirely new development methodology: Basecamp’s Shape Up.

Today, I’m proud to say that not only is our answer to the above question a resounding yes, but also the team is aligned toward our product vision, we’re shipping better software faster, and we’re making our customers happier than ever.

In this article, I’d like to share how adopting Shape Up helped us get here.

• “Output over outcomes” trap
• Basecamp's Shape Up was the spark we needed
• What Shape Up looks like at UserVoice

“Output over outcomes” trap

As the former VP of Engineering I was a proponent of SCRUM for a long time (and still am, for the right team), but our move from SCRUM to Shape Up has helped me recognize just how easily SCRUM teams can fall into an “output over outcomes” trap. Traditional SCRUM metrics like velocity help ensure teams have predictable delivery times, but it’s important to remember that velocity isn’t everything. Looking back to where we were before shaping up, it’s clear we were more focused on when something would be ready than whether or not it was the right thing to build in the first place.

SCRUM was fine for our engineers, but wrong for our product team. SCRUM allows you to reassess priorities at the end of every sprint (for us, those were two weeks long). It wasn’t until we dove into Shape Up that we realized that two weeks is a problematic time period. SCRUM teaches us that if something goes awry, two weeks isn’t such a long amount of time to head in the wrong direction. While this is true when it comes to software development, two week time periods cause product teams to scramble to develop requirements, acceptance criteria, and hold meetings to organize work. This means less time to analyze the importance of the software they’re building and in short, it causes them to take their eye off the ball.

If you’re putting something out every 2 weeks then you become hyper-focused on the small things and not on the big picture. There's no opportunity to step back and reflect that those small things contribute to the right direction.

The frantic cadence means that if your engineering team is good, the product team is running themselves ragged just to keep up with providing gas for the machine. The likely result: you do the things you can do because you’re ready to, rather than the things you should do, but you didn’t have the time to figure out what those are.

Basecamp’s Shape Up was the spark we needed

Our engineering team is a dedicated, hard-working bunch, and they weren’t necessarily bought into the things we were asking them to build. They recognized that the product team had a really hard time keeping their heads above water and they had an innate desire to impact business outcomes more directly. Change was a must.

About a year ago, a few of our engineers suggested giving Shape Up a try. Initially, I was uncertain about changing software development methodologies, it can create a lot of anxiety within the teams. Those responsible for delivery wonder if the process will be as efficient as the old one and developers worry about whether their days will suddenly be filled with boring meetings, keeping them from doing what they love. Though, as I learned more about Shape Up I became reasonably confident in its ability to help solve for some of our team's challenges.

We chose Shape Up for its collaborative and timely nature. The brunt of our issues came from misalignment and focusing on short term solutions rather than the big picture, so Shape Up was a possible answer to our troubles.

What Shape Up looks like at UserVoice

We now work in eight-week cycles: six weeks of development and two weeks of cool down. The six-week development cycles are at the disposal of the product team and the two weeks of cool down are up to the engineering team to do with what they want (refactors, learning something new, tuning performance, bug fixes, etc). You’ll see, though, that Shape Up will give the developers a much clearer picture of what’s important to customers and therefore the business, so that their efforts during cool-down are always valuable.

The next thing to note about Shape Up is that we work off of what are called “pitches.” The free, online book does a great job of explaining what a pitch is, but the TL;DR is a pitch is a clear statement of the problem we’re solving, the value that it has to our users, and how we’ll go about solving it. The solution is typically a simple sketch that we suggest (not mandate) that outlines how we’ll solve the specific issue. There’s also a time frame allotted, or as Shape Up refers to it “an appetite” of either two weeks or six weeks. Appetite answers the question “how big of an investment do we want to put into this problem?” Two weeks typically is enough to make a minor improvement or bug fix and six weeks is enough time to deliver a holistic solution to a meaningful, new problem.

Planning in Shape Up

At UserVoice, we create pitches using a process that has developed organically. Seven weeks before the start of a cycle, we start a Google Doc that we call the “Virtual Whiteboard.” Any and all ideas are welcome on this virtual whiteboard, we don’t start with any kind of pre-filled list of ideas to work off, meaning we do not have a backlog. Ideas are expressed as problems or jobs to be done that we can solve, not solutions themselves.

After a week of ideating and a couple of open-ended discussions, some of the items are naturally kicked out of consideration. In some cases, problems that seem like good ones to solve, end up being too daunting and ambiguous to tackle within the few weeks we have to think about them. Those items get moved into a section on the document called “Not This Time.”

Bringing the Go to Market Team into the product fold

After whittling down the Virtual Whiteboard we start talking about the other items on the list with our Go to Market Team. We ask, would you be excited to demo this? To sell it? To market it? At the same time, we bring in our engineers and have them consider whether the problems we’re looking into are manageable within two or six-week cycles. We also ask if the problems we’re considering are ones the team is excited to work on. Answers to these questions often lead to another round of cuts.

To begin formally writing pitch documents, we speak with our customers and non-customers about the ideas we’re throwing around to gauge interest, and to better understand if we’re expressing the problems the right way. Sometimes we’ll have a wireframe to test a proposed solution. We’ll also consult all of the product feedback we’ve got on the subject — you have a solution that helps you do that, right? ;)Sometimes in this phase, we learn that our good ideas are misguided. We discard a lot of pitches, which is good. We’ve avoided building, releasing, promoting, and supporting things with middling enthusiasm in the market. This is where the rubber meets the road.

Deciding what to focus on: the ”betting table”

Our strongest pitches are brought to what we call the “betting table.” Like all organizations, we have fewer resources than we’d need to execute against all of our ideas, so we place “bets” on the pitches we believe are most likely to move the business forward against our strategy.

Our betting table is made up of me (CEO, Head of Product), our Chief Customer Officer (who oversees the entire GTM team -- sales, success, support, and marketing), our Director of Marketing, and our VP of Engineering. These people represent the entire organization, and we reach a consensus on the best things to spend the next six weeks building, releasing, and marketing. Involving the broader organization breaks down the product team silo and has the whole company backing the R&D investments the company is making.

As for the pitches we’ve shaped but decide not to tackle? They do not go into a backlog. Someone can always bring them back to the Virtual Whiteboard in the future, but that’s not the default. I emphasize this because by eliminating the backlog the team is forced to look at a blank page every cycle and ask “what’s the most important thing to do next?” rather than to choose the convenient, already planned work that’s sitting there ready to go.

We bet on pitches one week before a new cycle begins. This gives the engineering team enough time to figure out which projects they’d like to work on and what’s going to be the best arrangement of skills to get the projects done. This method gives agency to engineers to decide who they want to work with and what they want to work on.

Shipping software in Shape Up

During the development of pitches, the product team is working alongside our Go To Market teams. We’re making sure we have clear statements of value for them to build campaigns around. We’re making sure that our sales team has a clear understanding of new functionality, customer outcomes can manage change and help customers see new value, and our team is updating our demo environments when it’s appropriate to showcase new functionality.

On day one of a new development cycle, everyone gets together for a light kickoff. We hold a quick meeting to answer outstanding questions and discuss options like what would we like our designers to produce? How do we want to tackle the problem? Is anything about the pitch unclear right off the bat? By immediately opening up the conversation, expectations are set and the team can hit the ground running.

Since pitches in Shape Up focus on the problems we want to solve rather than solutions, the engineers have a lot more latitude when considering solutions. This was an uncomfortable adjustment at first and it took us several cycles to get to a point where opinions were freely expressed. By giving our engineers this level of autonomy, they’re excited to build things their own way and have more skin in the game. As for JIRA, it’s returned to the hands of our engineers as a productivity tool.

I can’t emphasize the importance of this enough, it’s this alignment of goals — engineers and product managers working together to produce solutions to problems our customers have — that is the superpower we’ve gained. You can achieve this relationship with any software development process, but for us, Shape Up was the forcing function that triggered the behavior we’d been struggling to achieve.

Heading here → achieving product development efficiency

Switching our product development methodology to Shape Up has led to tremendous efficiency improvements. Today, our engineering team is:

• Not estimating individual tasks — they’re only estimating the scope of a bigger project.
• Not sitting in backlog grooming meetings.
• Not spending time optimizing “meta” questions like “what level of granularity does acceptance criteria need so that you won’t be mad at me later?”
• Not worrying that velocity is a measure of their value to the organization. ‍
• Not feeling muzzled when they want to share opinions about the product’s big picture.

The reduced communication friction between engineering and product has resulted in a lot more “getting it right the first time,” which has led us to double the number of features that we’ve released in 2020 vs. 2019. That led to an increase in MAU of 28.7%.

‍Switching to Shape Up is not the only way to focus your product and engineering teams on customer value, but for us, it was a key part of the answer. Any tips that you have found that bring your product and engineering teams together to focus on customer problems? We’d love to hear them!