Principles & Practices
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 needs to be opinionated. It's the only way the product can truly do the heavy lifting. Flexible software lets everyone invent their own workflows, which eventually creates chaos as teams scale.
Create momentum – don't sprint
Find a cadence and routine of working. In cycles, you can decide priorities and assign responsibilities. The goal is to maintain a healthy momentum with your teams, not to rush towards the end.
Meaningful direction
Even if your daily schedule is filled with smaller tasks, it's important to understand and remind everyone of the purpose and long-term goals of your work. Milestones, projects, and initiatives are all essential to consider when you plan your 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
Your tools should not make you the designer and maintainer of them. A tool should work for you, not the other way around. Remove or automate "work around work", so you can focus on what really matters.
Simple first, then powerful
Teams have different needs depending on their size. A tool should be simple to get started with and grow more powerful as you scale.
Decide and move on
There isn't always a best answer. Sometimes the most important thing is to make a decision, and move on.
Practices
Set strategic product initiatives
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 product timelines for unplanned work that comes up unexpected and allow your product plans 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 initiative meetings and pull from projects as you plan cycles.
Work in n-week cycles
Cycles create a 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 indefinitely. Important ones will resurface, low priority ones will never get fixed. A more focused backlog makes it easier and faster to plan cycles, and ensures that 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
Every project should have a named owner who's responsible for writing the project brief and delivery. The same rule applies to issues. Even if other people are involved, the 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). Collect user feedback and use it as a research library when developing new features. Try to spot trends. Attach requests and feedback to the relevant issue, to bring the voice of your customers directly into product development. Reading feedback, even complaints, is an opportunity to get to know your users and build exactly what they actually need.
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 challenge thinking around implementation and bring the winning ideas to reality. The best creators often have a talent for both.
Write a changelog
Writing a changelog benefits both internal and external communication. Internally, it helps your team to track progress and reflect on what they have achieved. Externally, it keeps users informed about what’s new and demonstrates your commitment to improving the product.