Product Development Processes You Might Not have Heard of

According to the Department of Product’s survey data, by far the most popular product development methodology (for our audience at least) is Scrum with 2 week sprints. This makes sense; it’s pretty ubiquitous and gives companies – particularly larger companies – a predictable cadence of regular releases and at the same time allows them to say that they’re doing things just like everyone else.

We’re not scrum / sprint bashers at the Department of Product, but we do also recognise that it’s not a one size fits all approach, either.

Scrum with 2 week sprints may work very well in larger corporates, but startups who need to pivot regularly and change direction may not be as well suited to such a fixed process.

But what are the alternatives to scrum, you ask? Well, here’s 3 different product development processes that modern product teams are using that you may very well have never heard of.

ShapeUp

Popularised by the project management SaaS company Basecamp, ShapeUp is a methodology that regularly gets mentioned by our community.

We’re going to massively oversimplify things here but if you’re not familiar with ShapeUp, it works in 3 core phases:

1. Shaping
2. Betting table
3. Building

Shaping

At the core of the ShapeUp process is the belief by its creators that something truly valuable can’t be built in just 2 weeks. Instead, teams are encouraged to work towards a 6 week development cycle.

And before that development cycle can start, teams are tasked with ‘shaping’ what the solution might look like.

Shaping is the process of designers, engineers and PMs examining the problem space and attempting to flesh out solutions before committing to building a first iteration. Shaping activities include:

• Designing prototypes
• Engaging with engineering teams to figure out how complex a first iteration might be
• Identifying assumptions
• Writing a customer facing pitch, similar to Amazon’s PR FAQ docs

The process is meant to be rough and fairly messy – perfect designs are not encouraged.

Setting the boundaries

Another important aspect of the shaping phase is setting boundaries. Figuring out what’s not going to be included in this new feature and working within those set boundaries.

This means thinking through must haves and nice to haves, plus considering how future feedback might impact the shape of the potential solution.

Once the boundaries are set and the idea is fleshed out in more detail, a pitch is drafted which is taken to the next step of the ShapeUp process: the betting table.

Betting table

The betting table is where investment decisions get made in ShapeUp. Similar to a Product Council , it is a vehicle for deciding which pitches should get built.

One of the principles of ShapeUp is ‘bets, not backlogs’. And whilst many PMs might get attached to their backlogs, the reality is that once something gets chucked into a list of things to do, it often gets forgotten about forever.

No such risk with ShapeUp – instead, the betting table gives stakeholders a few, shaped potential pitches to place as bets.

If a bet is unsuccessful, it gets let go (and potentially revived in the next round of betting if necessary). If it is successful, it moves to the next stage: build.

Building

Build phases in ShapeUp are 6 weeks long. The belief that underpins this period is that nothing truly meaningful can be built in a period shorter than 6 weeks. This might be true but as we know, often in 2 week sprint cycles, a lot of the work can sometimes get frantically pushed back until the final week. This is also a risk with a 6 week development cycle when teams feel they have plenty of time to get stuff done, only to realise 1 week before the deadline that there’s still a lot to do.

The goal of building in ShapeUp is to build something that works. This something must include front end and back end – a fully functional, integrated piece of functionality, and not a chunk of a fcuntionality that will be finalised in some later iteration.

Plan > build > ship

Next up, is a development process called plan, build ship.

Waterfall has a pretty bad reputation in the product development space, but some teams still opt for a waterfall approach, accepting that it might make things more difficult to pivot in the future.

Plan, build, ship has its roots in waterfall but is a lighter version of it.

How plan, build, ship works

In plan, build, ship, teams operate a mini waterfall approach to development where each feature is owned by an engineer or group of engineers from start to finish, with the goal of shipping it as soon as possible.

The plan phase includes:

1. Gathering requirements
2. Designing solutions

The build phase includes:

1. Implementing the designs
2. Iterating based on feedback

The ship phase is self explanatory – the feature gets shipped!

Whilst this does seem like a fairly rigid way to build products, proponents of the plan > build > ship methodology argue that there is still in place for waterfall style development.

GSD (get shit done)

This succinctly named methodology was popularised by the product teams at Shopify. For an in-depth view of how Shopify applies this methodology to its product development teams at a program level check out this in-depth post.

The company’s employee value statement makes it clear that getting shit done is at the core of what they do:

“We’re Shopify. Our mission is to make commerce better for everyone – but we’re not the workplace for everyone. We thrive on change, operate on trust, and leverage the diverse perspectives of people on our team in everything we do. We solve problems at a rapid pace. In short, we get shit done.”

The company even hired a Director of Getting Shit Done.

✅ GSD (or Get Shit Done) is an important framework and sentiment at Shopify — and wow did our teams understand the assignment! Thank you for shipping these projects just to name a few… pic.twitter.com/gdaHWponag

— Shopify Engineering (@ShopifyEng) December 30, 2021

The Get Shit Done mindset is designed not just for product teams, but as a company-wide ethos.

But in product development terms, the methodology includes 3 distinct phases, which are broadly similar to the ones we’ve already discussed:

1. Think –  product managers, engineers and designers work together to flesh out the program from a customer point of view.
2. Explore – solutions are fleshed out and assumptions are tested
3. Build – no further options are explored; it’s now time to build

But beyond the high level phases, there are some important details about the Get Shit Done process that are worth highlighting in more detail, too.

In this video, Shopify’s CTO explains in more detail the tools, structures and processes the company uses to get shit done:

Shopify – How we Get Shit Done from Jean-Michel Lemieux on Vimeo.

The most important points worth noting

Tools –  Shopify uses an internal tool called Vault to track work. This in-house tool is designed to allow anyone to keep track of a project that’s currently in any of the 3 core phases of Get Shit Done (think, explore build).

Why this internal tool works

The tool allows anyone to search for and keep track of any project in the company at any time. Keeping track means shared, accessible data for each project.

This helps stakeholders because when stakeholders meet, they’re not talking about the status of a project (since that’s already available in Vault), instead they’re talking about problems that may have arisen or questions that need clarifying.

Projects over tasks

Each project is accessible to everyone in the company at any time and projects can be favorited and tracked by execs. News feeds are also available per project which keep stakeholders up to date.

Now I know what you’re thinking, this is all well and good if you have the capacity to build these incredible internal tools, but what if I don’t? Well, if you were to choose to adopt the GSD methodology, other project management tools can be tailored to work in similar ways.

Bringing it all together – development processes compared

Most product teams according to our data are still using Scrum, Kanban or Scrumban – and there’s plenty of good reasons for this.

Scrum gives companies predictable cadences of releases with neatly prioritised backlogs derived from roadmaps and Kanban offers an ultra flexible approach to product development which allows teams to rapidly change direction. Scrumban takes the best bits of both and merges them into one.

But there are plenty of teams following neither of those methodologies. Hopefully this deep dive into some of the processes you might not have heard of will give you some food for thought when you’re planning how to set up your team’s process.