We Pivoted Our Product Development Method to Shape Up: Here’s How It’s Going

When our Product Manager, Alex, came to the team with a new methodology for building features, it was met with hesitation.

Since hiring engineers, Officely had been using Agile as its project management method, but something needed to change.

For those unfamiliar, Agile is a project management process in which all engineers work on one project at once, splitting the work into chunks and incrementally building.  Product teams work side-by-side with engineers to collaboratively build features.

You have a goal within each sprint, set to an element of the new feature.

The risk here is that you could spend months' worth of sprints on pushing out just one new feature… and that feature could turn out to be not as well received as first thought. 

This was exactly the issue Officely had run into. Perfectionism, constant iterations, and the drive to build the best version possible meant our output was dropping significantly.

‍

As Alex saw it, we had three options.

1. Stick with Agile and create harder boundaries for our two-week sprints.
2. Split the team into squads who each work on particular areas of the product.
3. Attempt a complete overhaul of the product management strategy, and adopt Shape Up, a six-week, output-focused methodology.

‍

While it sounds like a no-brainer, as our co-founder, Rich pointed out, Shape Up wasn’t without risk. Six weeks, by the standards of B2B tech, is a relatively long time to spend on a cycle. 

Would it still provide us with enough time to adapt to the market, or to changing feedback? Would it be too rigid for a startup that prides itself on being iterative and flexible? 

The only way to answer these questions was to find out first-hand. And, as you can tell from the title of our article, that’s exactly what we did.

‍

How Does Shape Up Work?

Shape Up is a Basecamp method that to optimize workflow. It involves six weeks of project-focused work and two weeks of cool-down. 

The engineers are given a minimum viability level for the feature – it has to carry out a specific function that Alex details. Other than this, it’s up to them to decide what can and can’t be added within the timeframe to ensure the features will be pushed out at the end of the cycle. 

While every company is different, at Officely, we’ve split our engineers into two teams of two. Multiply this by the six weeks of the cycle, and that’s 12 engineering weeks to deliver something of value per team.

In the meantime, our UX designer, Phil, works in tandem with both engineering teams to design the feature. He then hands it over to be coded up, and we launch between weeks 6 and 8. 

‍

‍

How Do We Decide Which Features to Work on?

For many businesses implementing Shape Up, there is a team of product managers overseeing the various aspects of the cycle. 

However, as a startup, Officely looks a little different.

The goal with Shape Up is to never have a backlog of features. Every cycle, our product manager pitches a handful of new feature ideas, based on research and feedback from both customers and the team.

Traditionally, the executive team would then vote on which features get taken to cycle. However, as a team of one, Alex instead pitches the ideas to the heads of each team, plus one engineering representative, and the three most popular features are the ones we build in the cycle.

Because every cycle is brand new, unless the same feedback comes up repeatedly or circumstances have changed, there is never a backlog of features that need to be built. Those that aren’t voted for are shelved, and we start fresh at the beginning of each cycle.

It’s easy for tech startups to get caught up in the must-haves, even if, four months later, they’re no longer relevant (trust us, we know firsthand).

With six weeks of discovery, we’re no longer caught in that trap. Instead, we can focus on what’s important, filter out anything that wouldn’t work for Officely, and make sure our features are relevant to the current market.

‍

How Are We Finding Shape Up?

We knew when deciding to introduce Shape Up that there was a chance it wouldn’t work.

And the reality is, we’ve had to find our feet with it. 

Sticking to six-week cycles to push out a feature was a necessity, but also challenging in comparison to the iterative processes we previously worked to.

Understanding how much was too much when it came to the features and their minimal functionality, was another area that required more thought.

And, while our original problem was that we were prioritizing quality over speed of launch, we also need to make sure we don’t swing too far in the other way: forcing features out of the door due to time constraints, that aren’t ready for our customers.

But clearly, if we’re writing a blog about how it’s going… it’s not all bad news, right?

Right.

‍

Why Shape Up Works For Us

As a startup with a small team of engineers, we had to stop limiting ourselves to perfectionism. There’s always something that could be changed or improved, but in order to make progress, a line needs to be drawn somewhere. 

“That’s exactly what Shape Up provides us with. With hard deadlines, we’re now in a position where we can look back at the end of six weeks and say, ‘Here’s what we’ve been working on, and here’s what’s shipped.’” Alex explains. 

Since launching the Shape Up in August, we’ve launched six new features. Compare that to the same timeframe previously, and we’d launched just one.

It also affords us more time to work on features that move the needle the most.

“There’s an opportunity cost for not shipping features quickly: you need to either prioritize a perfect feature, or learnings from users. And we now focus on the latter.

“This means we have to be ruthless. We’re a startup. If the feature isn’t going to improve our metrics, we won’t waste time on it.”

As for choosing and building the features, the way Shape Up works emulates our core values at Officely. 

It’s a more democratic process, and the creativity behind each feature is spread wider than just the product manager and designer.

The betting meeting is made up of team leads, which sets the direction at the very top level. 

Nobody can walk into the room one day and say ‘stop, we’re going in a different direction.’ Everyone has a voice at the betting table and can lobby for the features 

This carries through to building the feature, too.

Where previously Alex would write up specific feature requirements with every use case, and Phil (UX) would design it, the process is now far more collaborative with the engineering team.

Now, Alex writes the pitch, Phil does the skeleton design, and then it’s up to the developers to either add something extra to the project or take elements away if they feel the deadline won’t be met.

‍

Shape Up Does a Lot With a Little

At Officely, we’re all about doing as much as we can with the little we have. 

We’re a small startup, we’re purposeful and we prioritize our workload incredibly carefully – especially because we have a four-day workweek.

Shape Up emulates the way we run our business, and while it’s not always smooth sailing (when is product building ever smooth sailing?) it puts the emphasis on progress. And progress is exactly what Officely strives for. 

‍