How we build ShiftX using the Shape Up framework

How should you organize your work when you want to build a digital product as fast, painless, and right for the customer as possible?

The question is old and has many answers.

No more Scrum or Kanban

Several of us in the product team here at ShiftX has been working in consultancies for many years and have met both the positive and negative sides of frameworks like Scrum and Kanban.

And while these classic frameworks might work in bigger companies, we wanted a framework that made the product team feel more ownership. We want to hire people who love solving problems and are passionate about building quality products, and not just turning tickets.

Before, we struggled with:

• prioritizing features
• thinking too far ahead into the future
• not spending enough time digging into the real problems

While developing, we also started questioning our own decisions:

Were there other more important features than the ones we decided to make? Did we find the wrong solution for this feature?

Shape Up our way

We also saw that it was hard for the rest of the company, the ones working in admin and commercialization, to understand why we did what we did.

When we got feature requests and bug reports from customers, it was hard for people outside the product team to understand why we didn't make or fix them immediately.

The answer was clear for us. In a startup like our own, where there's an endless list of features we want to create, with a relatively small team (we're about 3-4 people working full time with product development), we need to prioritize hard.

Our solution has been to mold our version of the Basecamp-created framework called Shape Up.

How Shape Up works for us at ShiftX

So, at the core of Shape Up lies a premise of "betting":

Given what you know at this exact time, what feature (that can be made in a realistic amount of time, with a realistic amount of people) do you bet on to improve your product the most for existing and potential users?

You align the product team and the whole company, with bets taken on which improvements matter the most for you, right now. And when the decisions are made, everyone knows this is what the product team is focusing on solving.

How it's set up

Each "Shape Up cycle" is run in six weeks. And the setup of every cycle looks the same:

• Pre-work: Ideation
• One week shaping
• Four weeks implementing
• One week cooldown

Ideation (pre-work)

Everyone in ShiftX can suggest ideas for implementation. This is nice, both for making the whole company feel ownership and making it evident that when we get 20-30 ideas, everyone understands we can't make them all at once. It's about prioritization.

Often the ideas are based on customer feedback (in Shipright, our customers can give us product feedback directly) or our long-term roadmap. Before every cycle, we collect ideas in Slite before we move over to the shaping phase.

Shaping the ideas (first week)

At the start of each new cycle, the product management team hold a meeting where we decide what ideas we want to dig deeper into. This is the first point of prioritization.

How many ideas we pick for shaping in each cycle depends on how many people we have available for working with them. But it can be anything from 1 to 4 ideas.

The owner of every idea that gets chosen for shaping then gets one week to write a pitch, with a description of the problem and a suggestion for a solution.

Betting (one meeting)

After the shaping week, we sit down with the product management team and go through all the pitches. Our product management team consists of people with different responsibilities, from product, commercialization, and strategy. Out of the pitches, we pick the one or two idea(s) we believe to be the most important for our users and for pulling us in the right direction following our roadmap.

Implementing (two-four weeks)

This is where we create the features we've decided to make. And even though the ideas have been shaped the previous week, the team implementing the feature still has a lot of autonomous thinking and problem solving to do. That's a central part – we're leaving independent thinking and problem solving to our product people, and they feel ownership in return.

What's also important to note here is the strict timeboxing. Not done in your given four weeks? Too bad! Ship what you've got (if it's working fine), and create a new idea for further developing the feature in the next cycle.

Cooldown (last week)

"So, what about all the bugs and smaller fixes that constantly pop up? Don't you fix them?"

Yeah, we know. Bugs appear when they want to. And obviously, we do take some minutes here and there for some minor fixes. But nothing (almost) is so important, it can't wait for a week or two. If you zoom out, the bug someone just discovered has probably already been there for a month. It doesn't matter (to the very large majority of the world) if it stays there a couple of more weeks.

Takeaways

• We are now (more) sure about our decisions after each phase. If we made the wrong decision, we time-boxed it to 6 weeks, and we also learned a lot. No biggie.
• Make the feature (or at least a shippable part of it) fit inside 2 or 4 weeks. It makes us not think too far ahead.
• Easier for the company to follow the cycle and what we are making
• Easier for the company to raise their voices on what we should make

Want more? Read Ryan Singers' full version of the book Shape Up.