Improve Your Product Team’s Combat Effectiveness (Part 1)
Building new products is an ambiguous and tacit craft. It requires careful collaboration between functional disciplines. A key principle in product management is combat effectiveness — the measure of a team’s capacity to deliver superior product and make an impact.
A team’s combat effectiveness is often binary. Either a team is staffed, equipped, and supported sufficiently to make a difference or the team is hamstrung in at least one critical way that makes it ineffective (best case) or a liability to others (worst case).
A team that is combat effective works as a single unit — mission and plans are in sync, communicating seamlessly, and driving results. A team that is not combat effective spins its wheels — a group of individuals working in different directions, constantly fighting fires, and inconsistent with outcomes and deadlines.
As a product manager, it is your responsibility to improve your team’s overall effectiveness by improving internal and external dynamics. This article is Part 1 of 2 and addresses dynamics within your team.
Focus your team
Exercise Focus Jiu Jitsu to get everyone thinking and acting in the same direction. Ruthlessly prioritize goals and the product backlog. Proactively eliminate distractions, such as low impact work, unnecessary Agile ceremonies, and administrative tasks. Most importantly, make sure that you are not the distraction — by talking too much, micromanaging, and requesting busy work.
Principles, such as Lanchester’s Laws, can be applied to creative work. Concentrating your force makes an exponential difference. This helps explain why focused startups can beat billion-dollar conglomerates, how smaller military forces can surprise superior foes (e.g., Battle of Trafalgar, Battle of Thermopylae), or how a vocal minority can dominate the political agenda.
The principles of focus are especially pronounced in product work. Moving a foot on a hundred fronts has no practical impact on customers and the business, whereas moving 100 feet on one front can.
A feature’s value is 1 or 0 — released or not released. A live feature is an asset — it is constantly working for the user and business, whereas the best feature in the world sitting on the shelf does nothing. Your job is to create assets that compound value over time.
Thus, good teams emphasize small, quick releases. Have the discipline to scope small. A common mistake that PMs make is thinking they’ve reached minimal scope. Challenge yourself to find leaner and leaner solutions — whatever achieves the goal.
Limit Work In-Progress (WIP) to make sure your team is pushing on the one metric that matters. Avoid spreading your team too thin — committing to too many initiatives at the same time, allowing a dev to work on a “God PR” that never seems to ship, or finalizing a design that sits in the drawer for six months. In product management, you only get credit for what’s live and delivering value.
Here are some tips for keeping your team laser-focused:
- Keep everyone focused on the one metric (or key result) that matters: Communicate the goal often, at least once or twice a week. Give constant updates on how the team is doing against the goal.
- Encourage a culture of integrity and discipline: Build a team that says it will do something, then does it.
- Constantly simplify: Simplicity has a massive impact on productivity. Everything should be as simple as possible from making decisions to code. Simplicity is a byproduct of iterative refinement — it is sophistication not naivety.
- Think big, execute small: Develop a clear, moonshot vision. Translate it into execution by breaking problems down into smaller problems.
- Limit WIP to increase velocity: Create natural caps for how many tickets a team member has going on at one time to avoid context-switching tax.
- Protect your team’s time: Do whatever you can to guard your team members from distractions. Push back on administrative overhead, streamline processes, and cancel meetings or go to them and share notes. Be their agent if they need to push back on managers and stakeholders.
- Stop distracting your team: Often, the problem is you — the product manager. Stop talking. Listen to your team and serve their needs. Clear the path and unblock them. Stop scheduling meetings that are for you. Your job is to cut the noise, not add to it. Stop adding opinions and start adding facts.
Build a strong core team
Every great team has a core of indispensable members. To be effective, your team needs to attract, retain, and develop this group. Once a strong core is in place, you can build the rest of the team around it.
For a team to be combat effective, it needs dedicated members. If the team is a loose coalition of part-timers, external freelancers, or physically separated — it will be much harder to get the team in sync and humming.
Frequently replacing team members will also decrease your combat effectiveness. Without continuity, you’ll struggle to progress your goals — resetting momentum each time a key individual walks out the door.
Rotations can be beneficial, but try to protect the core team and minimize personnel switches. The product magic starts to happen only when a team has had enough time to work together.
Avoid taxes
Hidden inefficiencies are eating away at your team’s firepower. Product managers who neglect responsibilities will create taxes for her team.
An example is the Rework Tax — if a product manager does not thoroughly plan upfront, many unnecessary cycles will be created downstream as partners and stakeholders must ask questions or rework assumptions (e.g., dev assumes expected behavior and has to re-implement if it’s caught). The cost increases by multiples as soon as a line of code is written.
Another example is the Status Update Tax —if a product manager does not report sufficiently, people on your team may be constantly asked for updates. This is caused by a lack of proactive and consistent reporting. Streamlined processes can eliminate this tax, such as conditioning people to seek your kanban board for a status update. However, this is only possible if your team has the discipline to document key learnings, decisions, and results.
You must also proactively push weekly reports and provide individual reports to key executives and stakeholders to keep everyone comfortable. You should also develop the habit of constantly taking and sharing meticulous notes. Over time, as you build trust, the Status Update Tax will decrease.
The Meeting Tax can be levied because leaders feel like your team cannot drive quality decisions or results in a timely manner. A motivation for having a meeting is to avoid the back and forth over Slack or email and to hash out issues. If a product manager is not constantly driving thoughtful decisions, more and more meetings will be scheduled to “help.” Develop a clear decision making process — focus on what info is needed to make a good decision, how to gain buy-in, and drive decisions to a close.
Avoid the Meeting Tax by communicating the decision making process, tradeoffs, thought process, proactively getting input and buy-in, and sharing decisions.
The Context-Switching Tax seems to be well understood by builders but less so by business people. Your job is to educate leaders — there are many great articles available (e.g., how context switching demotivates programmers, Maker’s Schedule, Manager’s Schedule).
The Sync Tax is the recurring coordination cost needed to get multiple team members focused on the same feature at the same time. Have you ever experienced the following? Product Manager and Designer are focused on Feature A but Dev gets pulled into Bug B. By the time Dev switches back to Feature A, Designer had switched to Project C. Nine days later, all team members can finally resume on Feature A. Not only does the effort drag out, it takes time and energy to get back in sync with collaborators. The causes are described above (e.g., too much WIP, not enough dedicated people). The Sync Tax is amplified for teams with low combat effectiveness, creating a downward spiral.
If your team is paying a high Sync Tax, consider slowing down to move faster. Decrease the number of features in-flight and decrease the people involved in building the feature (this will increase individual ownership). Do not try to shorten deadlines by getting more people involved (see Brooks’ Law).
To discover hidden taxes, analyze Focus Factor. Focus Factor is the percentage of time a team member spends doing productive work —her core function in moving metrics (e.g., a developer coding). Identify the themes keeping your team members from driving results, then methodically address them.
Example: For your developers, the Focus Factor for the past two weeks may be 50% due to being blocked, waiting for code reviews, too many rework cycles with QA, vacation, sick days, meetings, functional work, social events, etc. Identify activities that need to be minimized. You won’t be able to completely eliminate everything (e.g., taking breaks) but you may be able to identify quick wins (e.g., say no to some requests, assign a clear decision maker, eliminate full-team planning/grooming meetings, invest in tools, simplify processes, automate administrative tasks).
Give your team the space to improve
Many managers think that downtime is bad for productivity. They keep their people over-extended so there is no idling. But if a team is exclusively focused on day-to-day output, it never has time to increase its throughput. Teams should be given a reasonable amount of time to maintain and improve the machine, not just operate it:
A product team can increase its overall productivity by improving practices and building infrastructure:
- Define process improvements throughout the product development lifecycle, including validating problems, prioritizing, validating solutions, and verifying success.
- Coach Agile practices such as grooming, planning, retrospectives. Many teams go through the motions of Agile ceremonies without really understanding why they are doing them. Help your team understand the “why” to gain benefits.
- Invest in tools that will make work faster and easier, or life better.
- Give your team the time to actually work on takeaways from retrospectives and process improvement discussions.
Teams should also make time for functional development. Developers, designers, data scientists, and any other functional members should have regular time per period (e.g., x hours every other week) to build systems, improve tooling, train, share learnings and practices, and pay down debt. Product and Functional Leads should negotiate how this works.
Finally, time should also be invested in personal development. Practices such as one-on-ones, pairing, rotations, and hands-on-coaching should be prioritized. A team member can develop much quicker with multiple mentors — her peers, functional manager, and product manager.
A team member’s manager should help her develop vertically — how to become a master in their functional discipline (e.g., full-stack engineering) and horizontally — how to collaborate, integrate, and leverage the rest of the business (e.g., how engineering intersects with sales). Product managers should take an active role in the latter.
A team member’s manager is accountable for her development. But because the manager is not involved in day-to-day work, there are many teachable moments for a product manager even within her functional discipline.
Example: a product manager who challenges a designer to better communicate thinking encourages her to become a better designer, resulting in better product.
When a team isn’t delivering fast enough, it is tempting for managers to “manage harder” — increasing scrutiny, instructions, and reporting requirements. Counterintuitively, this adds overhead and slows things down more. Quality people can figure out what they need to do to be more productive, just give them a clear definition of success and enough space.
If senior leaders are crowding out the space, it is your responsibility to persuade them to provide it. Also, spend some of this space to improve your team members’ quality of life — daily aggravations that build into demoralizing frustration (e.g., wasteful meetings, flakey tests, long build times, bad tools, onerous release process, administrative overhead).
Address Performance Issues Head-On
Finally, if it feels like you have too many processes (given your organization’s size and life stage), or you find the team “defining process” down to a specific individual (not role) — it may be a sign that there is an individual performance issues.
Exclusively blaming the process is a cop out. It’s tempting to avoid confrontation by transferring issues to process (and away from people). But sometimes, process isn’t the problem.
Process improvement is for improving effectiveness across several people. Personal development is for improving the effectiveness of an individual. You need to do both. I often see teams focus too much on process improvement when the real problem is a team member without task-relevant maturity. If three of your six engineers don’t know how to accurately estimate work, it won’t matter how well defined your estimation process is. Prioritize hands-on coaching.
If you see the potential for performance issues, work with the team member’s manager as soon as possible in a supportive (not punitive) manner. Do everything in your power to help the team member succeed. If there isn’t reasonable progress, have the courage to have conversations with the team member, or if needed, her manager.
Remember, make sure that the underperforming person isn’t you. Constantly seek feedback — ask your manager, users, team members, stakeholders, or other product people about what your development areas are. Watch out for the Dunning–Kruger Effect, which can be common with younger product managers.
An entire team can be hamstrung if someone in a critical role is underperforming, such as a product manager, tech lead, or sole designer. No amount of process definition, meetings, or talks will instantly solve issues of personal effectiveness (particularly a leader). Lean product teams and startups tend to expose the fat quickly.
Read Part 2
Keeping your team combat effective requires playing offense and defense. There are many practices that will increase your team’s firepower, but your first priority should be eliminating factors that prevent your team from acting as an integrated, focused, and autonomous unit.
There are many factors outside your team that can cripple combat effectiveness, regardless of how well you run your team.
