Introduction

Principles

Build for the creators

Software project management tools should build with the end users – the creators – in mind. Keeping individuals productive is more important than generating perfect reports.

Opinionated software

Productivity software should be opinionated. It's the only way the product can truly do the heavy lifting for you. Flexible software lets everyone invent their own workflows, which eventually creates chaos as teams scale.

Create momentum – don't sprint

We should find a cadence and routine of working. In cycles, we decide priorities and assign responsibilities. Our goal is to maintain a healthy momentum with our teams, not rush towards the end.

Meaningful direction

Our daily work might be filled with tasks but we should understand and remind our teams of the purpose and long term goals of our work. Roadmaps, projects and milestones are all important to keep in mind as we plan our weekly schedules.

Aim for clarity

Don’t invent terms if possible, as these can confuse and have different meanings in different teams. Projects should be called projects.

Say no to busy work

Our tools should not make us the designers and maintainers of them. We should throw away or automate the busy work so you can focus on the more important work.

Simple first, then powerful

Teams at different sizes have different needs. Tools should be simple to get started with and grow more powerful over time.

Decide and move on

There isn't always a best answer. The important thing is to make a decision, and move on.

Practices

Set monthly, quarterly or/and annual roadmaps

Ambitious goals are the only way to make a significant impact. Companies should focus on them when they define their high level direction. Reserve some space on your roadmaps for unexpected and reactive work that always comes up and allow your roadmap to change if needed.

Connect daily work to larger goals with projects

All projects and work should directly correlate to these goals. Review projects and their target dates during roadmap meetings and pull from projects as you plan cycles.

Work in n-week cycles

Cycles create healthy routine and focus teams on what needs to happen next. 2-week cycles are the most common in software building. They're short enough to not lose sight of other priorities but long enough to build significant features. Cycles should feel reasonable. Don't overload cycles with tasks and let unfinished items move to the next cycle automatically.

Keep a manageable backlog

You don't need to save every feature request or piece of feedback. Important ones will resurface and low priority ones will never get fixed. A more focused backlog makes it easier and faster to plan cycles, and ensures the work will actually get done.

Mix feature and quality work

All software has bugs, more than we can ever fix. Include bugs and other fixes as part of your cycles. Invest in tooling as it is a force multiplier if done right.

Specify project and issue owners

Each project should have a named owner responsible to own delivery and write the project brief. The same goes for issues. Others should collaborate but responsibility should lie with a single person.

Write project specs

Aim for brevity. Short specs are more likely to be read. The purpose of a spec is to briefly communicate the "why", "what" and "how" of the project to the rest of the team. Ideally these short documents force teams to scope out work so priorities are clear and teams avoid building the wrong thing.

Understand your users

The more popular your product, the more feedback you'll get. Overflowing inboxes are a good sign unless they're bug reports. Don’t worry too much about organizing all the feedback. Collect it and use it as a research library when developing new features. Try to spot trends. Use feedback, even complaints, as an opportunity to get to know your users and ask them to explain why they want a specific feature so you find out their needs. Solve the problem – don’t just build the feature.

Scope issues to be as small as possible

It's hard to see visible progress when working on large tasks, which can be demotivating. Break down work into smaller parts and create an issue for each one when possible. Ideally you can complete several concrete tasks each week. It feels great to mark issues as done.

Measure progress with actual work

The clearest way to see whether something is complete or not is to show the diff in the code or design file. When the tasks are scoped small, your changes will be small and easier to review, too. Avoid massive pull requests or large design changes.

Run cross-functional teams

Designers and engineers should work together on projects, creating a natural push and pull. Designers bring their skills to explore ideas and push your team's thinking. Engineers can challenge thinking around implementation and will bring the winning ideas to reality. The best creators often have talent for both. Directly loop in other teams when building features they'll use or ask customers they interact with to use.

Write a changelog

It’s important to look back and celebrate what you achieved as a team. Consistent changelogs also communicate to the user new features, the value they get from your product, and your commitment to improving it. It's also an easy way to connect your team's individual work to the collective value they create. Read more on how we write ours.