What are some ways you've seen product teams increase their velocity?

A common pitfall that slows teams down is inability to make good decisions quickly, especially if these decisions involve many stakeholders. One of the best-kept team velocity secrets, especially in larger organizations, is having a consistent and efficient decision-making framework that is practiced across teams. With a small initial upfront investment of agreeing on a decision making framework within your organization (or just starting to practice it consistently), you will be able to save many weeks and months by unblocking the team quickly and moving on with your important decisions. There are many frameworks out there, and you can develop your own, too. I absolutely love the Atlassian playbook's DACI which we use religiously, and something I have heard from ALL Atlassian alumni they brought to their new teams. Check it out here: https://www.atlassian.com/team-playbook/plays/daci

That's a great question, and I'm glad you're thinking about it from a Product Manager's perspective. A team's velocity is influenced by many factors and is largely within the team's control. When I've seen teams dramatically increase their velocity, they usually follow a pattern like this:

1. Recognizing the Need for Change: A catalyst emerges that prompts the team to focus on velocity. This could be frustration over a project that lacked impact or dragged on too long, or organizational pressure to increase speed.

2. Measuring Velocity: The team begins discussions and selects a system to measure its velocity. There's no one correct method; the goal is for the team to see improvement relative to itself. Often, teams start measuring how many story points they complete per sprint or the percentage of planned points they actually complete.

3. Conducting Regular Retrospectives: The team holds frequent retrospectives to analyze what's consuming time. They ask questions like: Are tasks taking longer than expected? Are tickets not well-defined? Are we dependent on other teams for answers? Is there too much context switching? Based on these discussions, they propose experiments or process changes to address the issues and observe the impact.

4. Tackling Tech Debt: One major discovery might be a substantial amount of technical debt in a certain area. Addressing this usually requires investment but can greatly enhance velocity by simplifying a category of work. For example, one team I worked with refactored their entire front-end to use React, reducing the time needed for front-end changes from days to hours.

Through this iterative process, teams often significantly improve their velocity. This journey takes time but can be immensely rewarding in terms of boosting the team's confidence, satisfaction, and overall impact.

I've consistently seen the best PMs do a few things to increase velocity, though I think this would be framed better as impact as a PM since the result of that velocity is shipping more product.

1. Be the voice of the customer - this is the most important thing by far. The best PMs employ the help of their team to solve customer problems. If you do this effectively, you get everyone on the team to focus on the customer problem, not the tech or the design or the architecture. This is where great teams live. “If you want to build a ship, don’t drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea.”

2. Aggressively pursue the Pareto Principle - find the 20% of the work that is going to deliver 80% of the impact.

3. Build a great relationship with your technical lead - this will allow you to comfortably challenge each other about the scope of the work, even if you don't have a technical background.

You can increase velocity and drive impact by collaborating with your team and stakeholders to write high quality requirements, and by driving deep alignment on initiatives. As a product manager you should constantly ask yourself where you can realistically jump in to get things done or alleviate pressure on the team. Most importantly - keep your team unblocked. This will ensure that your team is building efficiently and that everyone is bought in on what they are working on.

Here are some of the areas one can look to potentially increase engineering team velocity, i.e. do more over the same period of time.

• Cross-craft collaboration: PM, UX and Engineering. Do you make decisions quickly, or spend a lot of time debating the direction? Do you trust each other? Do people have to go back to PM for clarifications all the time (and stay blocked, while waiting for such clarification)?

• External dependencies: are you sell-sufficient working on your thing, or have to rely on other teams’ deliverables and timelines? Can you either influence priority of your external components, or own all of it end-to-end if it's the latter?

• Motivation: is the entire team bought into a grand idea of your thing? Do they consider it fun to work on it? Or people just “clocking in”?

• Roadmap efficiency: do you frequently have to go back and re-do a thing? (e.g. late requirements or design changes) Is one-off, throw away work common on your team - or you are building with one brick over the other?

• Tech debt: PM nightmare - stopping working on new features for a while. Yet sometimes team may see opportunities to modernize their codebase - unlocking unbelievable velocity for the future. Decide together if it's an "okay" time to do it now (it is never a "good time" from a PM point of view, and always is from Engineering point of view)

• Perceived velocity: is your team working on something behind closed doors for a long time, or is open to share exciting, tangible, easy-to-consume updates every week? The latter would help external stakeholders to appreciate team’s velocity way more. At Atlassian, we foster a culture of micro updates (think of a Tweet-size shareout) shared every week - and we have a platform component Goals & Projects to enable this process at the organization level.

Setting a fast-paced rhythm and providing predictable touch points are the two practices that a product manager can heavily influence that can impact team velocity. 

These two concepts are related: a rhythm gives teams in your organization a common pattern they can align to. Everyone knowing that the team operates on sprints of the same length, with a common calendar, how decisions are made and communicated in a common way, a clear way drivers, approvers, and contributors are determined and documented for projects - all feed into a sense of rhythm and predictability. 

I call out predictable touchpoints specifically because they provide some level of control on the thrashing that organization leadership can inadvertently cause when interfacing with the team. By setting the touchpoints at the various levels of leadership in advance, and providing clarity on what will be reviewed and decided at each touchpoint, its easier for the product manager to isolate which areas of the team may experience change and keep other teams more focused. 

Lastly, it's important to work with your engineering and design counterparts to keep a constant investment in agility operations and tools. The faster each discipline can do their daily tasks, the more agile the overall team will be. This can range from providing time for developers to adopt AI code generation tools, optimizing a CI/CD pipeline, resolve long-standing operations issues that are costing time, and so on.

Before working on developer products I was an technology consultant leading Agile and DevOps transformation and I have seen a lot of slow teams, get faster. Here are the common ways to improve velocity.

1. Deliver less. Deliver the smallest possible thing you can to solve a user problem. Think you made it small, make it smaller. Put it out there and understand whether it had impact and iterate.

2. Pull work in. Keep a flexible backlog and pull work in rather than plan weeks in advance. This ensures the highest priority work is delivered sooner.

3. Create shared understanding. We are slow when we rely on individuals to know or do specific things. By creating a shared understanding anyone on the team can make choices and decisions on what and how to deliver. With shared understanding and ownership, they will rarely be left waiting for someone else to “make the call” and you will deliver more value sooner.