The execution series
This is the first of a series of articles on execution. It gives you a framework to think about execution: Through the lens of motion and rituals. In the next articles, we will go in-depth on the most important rituals.
Refinement (coming soon)
Sprint planning (coming soon)
Sprint reviews (coming soon)
It’s January, everyone has a fresh new roadmap and is ready to change the world. But a product does not rise to the level of its strategy, it falls to the level of its execution.
Reliable product development engines
For a product team to execute well it needs to become a reliable product development engine. An engine that has enough power (= product innovation) without using too much gasoline (= waste & burnout).
The best development engines have a cadence that is fast in bringing product innovation to market without putting too much strain on its builders. This is much easier to achieve when you keep things moving. It's simple physics, as Newton's first law of motion describes:
An object at rest stays at rest
An object in motion stays in motion unless acted upon by an unbalanced force.
Once your product engine is moving, it will need an opposing force to get it to stop.
Rituals to keep your team in motion
Keeping a development team in motion is an art. But one overarching principle has helped me build the right conditions for it: Rituals.
Rituals: a way of doing something in which the same actions are done in the same way every time [1]
Rituals help groups stay in motion, as the path of least resistance becomes to carry out the damn ritual. People know what to expect, and what is expected of them. This reduces communication overhead and helps everyone find their rhythm.
Create your own rituals
Release
The most important thing is to get product innovation out of the door. Therefore, the leading ritual should be the release of your product. Every other ritual should only be there if it supports your team in releasing a quality product to your users.
I like to have a weekly release schedule. Every Tuesday morning we push a release. This creates clarity for your team and stakeholders. It also creates constraints that help shape decisions. Everything else is planned around this release.
All the other work
What happens after we ship? We simply need to get ready to ship again!
Define the work
First, we decide what we want to enter our shipping pipeline. This means we need to define new projects and prioritize them. As a PM, you are the one driving that process.Collaborate on specifications
Because we want the best outcomes for our users, we need to use all the brainpower available. This means your team should be involved in defining problems and specifying solutions in a meaningful way. Key players should have enough time and space to collaborate with you on the product specifications.Plan & review sprint
The final thing we need to we can stay in a reliable shipping rhythm is, we need to plan for the next sprint and review our progress in the current one.
So your week might end up looking something like the calendar below. The pink blocks are the team rituals, the blue blocks are the PM rituals.
In this post, we’ll only give a brief description of each of these rituals.
Writing specifications
Translate the high-level projects from your roadmap to concrete plans. Lenny has a useful template for this, or you can use this Notion template from our own Cornelia.
EDIT: Here’s my take on writing great specsRefinement
Discuss concrete plans with your team. Share open questions. Fill in the blanks. Get feedback on things you got wrong (there will be many). You can also use this session to break up the work into smaller chunks if needed (Epic > Story > Task > Subtask).Planning
This is the moment to look ahead. What will you tackle in the next sprint? Who will do what? And what will release everything that we planned for next Tuesday’s release?Weekly review
The weekly review should contain at least the following things:Review of the work - Did we do what we committed to?
Product KPI’s - Did we make progress? Or did our latest release hurt our numbers?
Blockers and discussion topics - Make sure you have all the info
Personally, I like to add in product demos. Demos give people a chance to show their work and are a nice way to celebrate progress.
Recap
The cadence of your development engine determines your team’s success. If you manage to stay in motion, your cadence can be fast without becoming too strenuous. Rituals support this.
Find a cadence that works for your team and build the rituals to support it. Adjust where needed, based on your team’s feedback. Once you get the hang of it, you can try to speed up the cadence to increase your team’s velocity.
Give it a try, and let me know how it goes!