Linear: Choose the workflow, so teams don’t have to.
Linear built a project tool with strong defaults and published the working method behind it. Explore when choosing for your users beats letting them configure everything, and what that choice asks of you.
See the idea in one picture ↓- method published
- 30 Jun 2020
- cycles, the most common
- 2-week
- per issue and project
- 1 owner
Figures as reported by the company.
Independent educational analysis. Scenarios, people, numbers and illustrations on this page are original PMcademy practice material, not company research results or an endorsement.
A blank canvas is also a chore.
Every team invents its own workflow
One clear way of working, built in
Read the analysis
Imagine your product can be set up any way a team likes: custom states, custom fields, custom rules. Every team says it wants that freedom. A year later each team works differently, nobody can read another team’s board, and someone spends Fridays maintaining the tool. The product question is not only how much flexibility to offer. It is who pays for the decisions you leave open.
Build for the person doing the work.
“Let me do the work. The report should write itself.”
- The next task, clearly
- Less busy work
- Fields only managers read
- A board nobody else understands
Read the analysis
Our fictional learner, Nia, is an engineer who wants to pick up the next task and get it done. Her manager wants status reports. A tool designed around reports asks Nia to fill in fields she never reads. A tool designed around her work makes the report a by-product of doing it. Ask whose job your product makes easier first, and whose job it quietly makes harder.
Defaults instead of a blank canvas
- 1Everyone invents
When every team designs its own workflow, nobody can read anyone else’s board.
- 2Shared defaults
One clear set of states makes work readable across teams from day one.
- 3A built-in rhythm
Work runs in short cycles, and unfinished issues roll forward on their own.
Animated illustration. Names, numbers and people are fictional teaching material.
Make the good path the default path.
Illustrative data and simplified behaviour. This model does not represent a live company system or measured company results.
Read the analysis
Use the model below to compare three set-ups. In the first, every team configures its own workflow from scratch. In the second, the product offers sensible defaults that teams can change. In the third, the product builds a way of working into its structure, such as short cycles where unfinished work rolls forward on its own. Notice how setup time and consistency change. The numbers in the model are illustrative.
Opinions win fans and lose some deals.
- Faster setup
- Readable across teams
- Loyal fans
- Wrong for some teams
- Lost sales checklists
- Pressure to add options
Read the analysis
A product with strong opinions is faster to adopt and easier to keep tidy, and the people who agree with it become loyal. It will also be wrong for some teams, and those teams may leave or never sign up. Flexibility wins more checklists in a sales process and pushes the cost of design onto every customer. Decide which opinions are core to your product and which should bend.
Write the opinion down where people can argue with it.
Linear published its method: build for creators, avoid workflow chaos, work in cycles.
That opinionated tools suit every team or grow faster.
- Time for a new team to start
- Defaults changed first
- Teams still active after a year
Read the analysis
Linear published its method alongside the product, so people could see the reasoning behind the defaults before adopting them. A published method sets expectations and attracts users who share them. It is also Linear’s own account, not proof that its approach suits every team. In your project, look for evidence in behaviour: how long new teams take to start, how often they change the defaults and what they change first.
Which choices will you make for your users?
Your fictional team is building a tool for school teachers to plan lessons. Some teachers want a fixed weekly template. Others want to design their own. Choose what the product decides by default, what teachers can change and what they cannot. Explain the evidence that would make you loosen or tighten one of those choices.
Choose a next move
Leave with a defaults charter.
Your artifact
Write a defaults charter: the decisions you make for users, the ones you suggest, the ones you leave open, and the reason for each.
Critique my project artifact using only the evidence I provide. Write a defaults charter: the decisions you make for users, the ones you suggest, the ones you leave open, and the reason for each. Separate observed facts, assumptions, proposed tests and missing evidence. Identify a failure mode and a cheap check. Do not invent company results or user research. Ask for my artifact before starting.
Read the analysis
List the decisions your users must make to get value from your product. Mark which ones you will make for them, which you will suggest, and which you will leave open. For each default, write the reason in one sentence a user could read. Add the behaviour you will measure to check the defaults help, and the signal that would tell you an opinion is costing you the wrong customers.