How we use Linear to build product at Stacker

It’s a new year and a new decade, and as we adopted Linear in late 2019 we decided it was a good moment to evolve our product process at Stacker.

We’ve been blown away how Linear has changed the way we work so quickly, we have ended up dramatically improving our product process empowered by Linear. This post gives a quick rundown of how our new process works.

We set direction with a goal

To keep iterating quickly on our product we are running weekly sprints. Each sprint has a goal which we determine in advance of the week. The goals should be as specific as possible, but we do accept vaguer goals.

Our first weekly sprint goal for 2020 is: “Make leads more likely to subscribe”.

We set this in the cycle name:

Tracking progress through our weekly cycle

Move with a weekly cadence

We setup our cycles to last a week from Monday to Friday with no cooldown period. We are a fully remote startup and we find that we make the most progress by having few fixed meetings. We decided to have a single meeting per cycle at the start of the cycle, on Monday mornings. As we have no cooldown period and only this single meeting, the meeting serves to both start a new cycle and close the previous cycle.

The settings we use for cycles

Demo in production

Our weekly product meeting starts with demos of the features that have been shipped the previous week. These demos are all done from production as the delivery of all tickets is required before the end of the day on Friday. Making developers demo their work is a great way to keep everyone up to date with the state of all parts of our product, and to highlight the great progress being made.

Any tickets that haven’t been completed will not be completed unless they get selected again as ideas for the next sprint.

Everyone contributes ideas

Next in our weekly product meeting we gather ideas. Ideas is our catch all term for both new feature suggestions, existing feature improvements and bugs that need fixing. Everyone is responsible for thinking up new ideas for how we can improve our product.

For the moment we write these on a shared Notion page while the whole team is dialled into a Zoom call. In future we may surface ideas that have already been written up as Linear tickets.

Once all ideas are written out and understood by everyone on the call, we stop accepting new ideas for the current sprint. Any ideas team members have later in the call or later in the week can be brought to the next weekly product meeting.

Estimate in T-Shirt sizes: S, M, L

Next we estimate the issues in three broad buckets:

• Small for items that will take a couple of hours
• Medium for something that would take more than a couple of hours, but less than a day
• Large for anything that would take a day or more

The settings we use for estimates

Linear converts the T-Shirt sizing to numbers automatically (S is 2, M is 3, L is 5). These are shown in the totals at the top of the columns on the board view but we ignore them.

Pick the largest ones first

Here we adopt a principle from a product process shared by Michael Siebel from one of the companies he worked at before Y Combinator: we pick the largest items first.

Depending on the capacity available in the week we agree how many large tickets we can deliver and we agree which of the large items should be selected. We then do this for medium and finally for small. We refer back to the sprint goal to help decide which items should be included.

Deliver continuously

We all commit to delivering the entire sprint before the end of the week and start working! The tickets move through these status steps that we have setup:

Our product workflow settings

The key steps for us are after the Backlog section from Todo through to Done:

• Todo means a ticket is in the cycle but hasn’t been started. Anyone can pick it up.
• In Progress means that work is actively ongoing by the assignee.
• In Test means that development is finished and the ticket is available to test in our test environment.
• Testing Completed means that testing has passed and the code is ready for review.
• Done means that the item has shipped to production.

Here’s how our board looks right now:

Our sprint board

An evolving process

We’ll keep you updated as our product process evolves in the coming weeks and months, until then I’ll get back to shipping features.

P.S. If you like the sound of working like this, we are hiring :)