The guidance I normally give to PMs on product briefs is to describe a room. If you want to build a movie theater, you tell the team, “Here are the dimensions, here are what the walls are, you need to be able to support x people watching at the same time.” And then you let designers and engineers actually design and build the room.

This particular product brief went a little bit further than that metaphor, largely because of how huge and cross-functional this project was. We wanted to be as clear and well-scoped as possible to avoid risk. We call this type of project a boulder (as opposed to a rock or a pebble), and we try not to have more than 1 or 2 boulders on our roadmap per year. This feature ended up taking about 10 months to build.

When we kicked off this project, I was transitioning out of being an IC and Larry took over the team I used to lead. He made the transition go really smoothly and knocked this project out of the park.

There were two impetuses for this project: a clear user problem and a market trend. The user problem was that Webflow is not a synchronous multi-user product, and that became a problem as we went upmarket. Our larger customers had up to 10 people wanting to work on a site, and they couldn't do it at the same time. All they could do was Slack each other to say when it was ok for another person to go in there.

The market trend was headed towards branching as a best practice. We are a visual development platform, and developers branch things. So it made sense to follow that best practice as we were moving up markets. We needed to make sure our enterprise product was valuable to customers, and this was one of our first big enterprise features.

When we began this project, the problem was very clear, but the solution was not. We defined the problem during ad hoc conversations and pillar reviews, and then for about 4 months, we debated heavily what the right solution was. I got together with JZ (our ) and our former head of engineering to explore and t-shirt size our options. Synchronous was going to be next to impossible, and site branching was more attainable but didn't fit the user need. Page branching ended up being the Goldilocks solution.

The version of the product brief you see here was updated after all that exploration, when we had aligned on the solution.

In case helpful: there is a youtube video overview of 

Larry Blyth

Britt Jamison

This brief enabled us to build and launch Webflow’s first big enterprise feature to support scaling teams.

 | #proj-page-branching | Last updated: 01/2022

Today, scaling teams struggle to efficiently build websites in Webflow because only one designer can work at a time. We believe enabling multiple designers to divide and conquer with page branching will unlock productivity for larger teams.

In FY23, Webflow’s strategy is to power mission-critical sites for scaling teams

Scaling teams need an increasing # of designers to be able to build in Webflow in parallel

~XX designer seats purchased per sales-assist customer

~XX unique users accessing the Designer each month while a teammate has design-control

These teams want professional-grade workflows that enable designers to safely divide and conquer across pages 

(not to work on the same object at the same time)

A design system owner: to build and maintain the styles and symbols

Multiple page builders: to build pages in parallel, using existing styles and symbols

As a result, we see many companies already enabling similar workflows (e.g. Figma branching, Bubble branches, Retool branching, Contentful environments, etc)

Multiple designers are not able to divide and conquer on pages because only one designer can have design control at a time

‘To achieve a level of productivity, our teams had to work around the clock one by one’ -- [Customer 1]

 ‘We have so many conversations in order to just coordinate who is in the Designer’ -- [Customer 2]

‘We duplicate the project [to divide & conquer], bring it to ~90% completion, but then get set back to 40% after merging changes’ -- [Customer 3]

How might we enable multiple designers to divide and conquer on a site safely?

Enable multiple designers to work on one version of the site

Enable multiple designers to work on multiple versions

#1 would worsen existing collaboration pain points, e.g.:

inability to do larger redesigns and smaller fixes in parallel

#2 better aligns with how scaling teams want to work

page-builders: want to have their own branch / a safe sandbox to work in parallel that allows others to approve changes before merging

design system owners: want full control of the site and not to be limited by objects being locked (like in option #1)

Designers can create a ‘branch’ of a page so they can safely work on it in parallel

Simultaneously, another designer can have full design control on the ‘main site’ (just as they do today)

Designers working on page branches can choose to update their branch with the latest styles from the ‘main site’

When the designer is finished, they can request approval of their changes, then replace the original page on the ‘main site’

How page branching solves the ‘one designer’ problem:

Goal: Multiple designers are able to build pages in parallel

Making Webflow easier to use for non-technical users

Mitigation: descoping the most complex aspects of page branching (e.g. no merging)

Engineering staffing: Enterprise pod currently made up of new engineers

Mitigation: consult and knowledge transfer across pods/pillars

Interaction with upcoming features (e.g. Components, Logic Flows, Memberships, Ecosystem)

Product Brief: Page Branching at Webflow

Product brief: Page branching

Summary

Background

Sign up to see more