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.