14 Squad Commandments
Being a product manager in a hungry, cross-functional, talented squad is exciting and satisfying.
At the same time, it can also be stressful, confusing, and frustrating.
When company priorities shift, squad structures and objectives change, and when the temperature rises across the organization to deliver results faster (never happens..), these feelings can quickly compound.
So how can a product manager keep their head above water?
Below are my own commandments — learned the hard way, often — that I have written up about how to manage that squad life.
I’d be lying if I said I did everything perfectly, even half of the time. Having said that, I always find it useful to review the points below when I am in an objective state of mind in order to ensure the team is on the right track.
Let’s jump into it.
Be clear about what the squad’s area of ownership is.
There will be times when your squad might be “influenced” to pick up work that doesn’t fit the primary objectives of the squad as defined by the organization earlier.
Push back when necessary. This isn’t for the sake of being stubborn. It helps the squad remain disciplined and focused on the work which is most impactful for the objectives of the squad. You are the gatekeeper of the backlog and items in the sprint. Executing work that is not core to the squad objectives is a dangerous habit to fall into that gives a false sense of being busy on priorities.
Having said that, all teams need to be flexible every once in a while — all team members in the company are in the same boat at the end of the day — but when that is the case, it is good to highlight this appropriately. It might be a reflection that another squad is overloaded and needs more support, that a squad restructuring might need to happen, or that there are areas of the business that don’t have clear ownership and slip through the cracks.
Clear priorities. Clear focus.
Be concise about what the squad objectives are and how they align with the company vision. It’s your job to communicate this regularly and to tailor the roadmap accordingly.
Your squad will also thank you. Nobody likes spending the majority of their time on busywork, constantly context switching, and tracking poorly against their goals.
It will allow the team to focus more efficiently on execution and coming up with ideas to meet objectives.
If it takes more than one hand to count the number of categories your squad is putting significant effort into in order to meet team objectives, it is probably time to refocus and narrow the scope of the squad.
Minimize disruption to the sprint.
Try to minimize slipping in additional tickets halfway through a sprint, unless it’s something like a production bug, security concern, etc. This pisses off engineering, messes up planning, and all types of fancy tracking and reporting.
In reality, things come up from time to time and need to be dealt with — which is OK — but enforce a rule, e.g. “If this 5 point ticket is entering the sprint, 5 points have to be deprioritized”.
Never be the blocker.
Never be the person the squad points at as being the blocker.
Hearing “the tickets weren’t ready!’’ or ‘’there is nothing ready in the backlog!’’ sucks.
Have a solid backlog fleshed out in JIRA, or whatever tool you use to track development work, as best you can. Rule of thumb; try to have at least 2 sprints (assuming 2-week sprint cycles) worth of work in a “ready to be groomed” state in the backlog.
I’ve always found it more challenging to maintain this level of depth when juggling too many projects and context switching constantly. I find myself only being able to get into detail on the surface level and missing details that should not be missed. When I have a narrower focus and clear priorities, I find it much easier to go into the details and end up naturally having a deeper, more impactful backlog.
Find a way of writing requirements that works best for the team.
Writing requirements is like a language. There are many different ways to communicate.
Some teams like having stories written up in a BDD format and then breaking it down into front and back end tickets. Some teams like having clearly separated tickets from the start. Some QA’s prefer having their own sub tickets. Sometimes, design teams have their own board and like to link their tickets to the engineering board.
As you spend more time writing requirements, you’ll have your own preferences as well.
Find a happy place with your team about how requirements are communicated. This might take a few iterations, especially when starting off, but you should not be afraid to ask for this type of feedback. Your life will be a lot simpler when it comes time to grooming sessions.
Get team members involved early.
Get different squad members to help review wireframes, new feature ideas, growth hacks, etc, as early as possible so that they can highlight complexities and give feedback to product and design early on.
The reason for this is because a good amount of ideas come directly from different parts of the squad. E.g. a good engineer will be able to give insightful feedback at the wireframe and design stages, especially on the complexity of building said designs. This can influence your designs (especially if only building an MVP) massively. A marketer can help identify initial growth channels to test your MVP. A data analyst can help ensure you structure and store data correctly, etc.
Do not forget about technical debt.
There is always technical debt.
Ensure your technical team lead highlights the important areas that need to be addressed and plan for it.
Help them highlight the impact of addressing that technical debt so you can prioritize accordingly. Plan your sprints to include tech debt and make sure it’s part of the squad roadmap when communicated.
A roadmap does not only consist of new features.
Never be the one to dictate timeframes and estimates.
Engineers build. You don’t.
Leave estimates and timeframes to engineers and TPM’s. It’s not your job to tell people how fast something is to build or to estimate the complexity of something. Obviously, if something needs to be delivered by a certain date, e.g. to meet a contractual deadline, highlight this as a requirement to be taken into account.
Constantly align with your tech lead.
The tech lead should be just as familiar with the upcoming roadmap as you are. Make sure you are communicating frequently on things that are going on and that are coming up. This is an important relationship.
Constantly align with your business stakeholders.
Same as the above. Keep your business stakeholders in the loop and constantly communicate. This is an important relationship. Take their feedback often and thoughtfully.
Know your shit.
If it’s in your roadmap, you better know why it’s there, why it is prioritized the way it is, and everything in between. It’s not a good feeling getting called out on something and not having a good answer.
If it’s something your team just delivered, be sure you know how it is performing and what people are saying.
Respect the process.
Put in the effort into each scrum ceremony, whether it’s a retrospective or a grooming session.
Whilst this can sometimes seem like meeting-overkill (which it can be unless managed correctly), they keep the team on track and constantly improving.
Tip: don’t try and improve on everything all at once raised from retrospectives. Try and improve just one thing at a time.
Tailor your roadmap according to the viewer.
You need a few versions of your roadmap for different target audiences.
Would you talk about individual JIRA tickets as part of a leadership presentation about the upcoming work in quarter 3? I hope not.
Make it easy for people to locate the appropriate roadmap for your team so you don’t keep getting asked for it either.
Make analytics a requirement.
You can’t tell how well you are doing unless you can measure it, right? This generally means having your KPI’s in order. They don’t populate themselves with data, though.
It is easy to forget to include triggering a Mixpanel event on a new UI component or tweaking a dashboard to track an updated user journey.
Make it a habit by treating analytics as a requirement. What works for me is including it as part of the acceptance criteria when writing up a JIRA ticket. Even if it requires setting up a new ticket and assigning it to yourself, do it!
Last, but certainly not least, is having a good relationship with your squad. Having that goodwill will save your ass when you slip up from time to time.
Trust me on this one.
