Balancing velocity and long-term planning

What matters most, delivering output or creating value?

The answer might seem obvious: creating value, of course! But then why do companies pay more attention to output than outcomes?

Accelerating velocity doesn’t mean creating more value. Meanwhile, failing to deliver output fast enough disables value creation. How can we balance this equation?

Over the years, I struggled to balance the present and future. No matter the role I had, high pressure was my only certainty. Everyone wanted something done by yesterday, and it’d never be enough. But that mindset is misleading because an extreme focus on the present will compromise the future.

Sadly I don’t have a magic-bullet solution. However, in this guide, I’ll attempt to help you differentiate what’s sustainable and what’s not in terms of velocity and long-term planning.

Understanding the status quo

To understand your current reality, reflect on the following questions:

• Do teams receive output or outcome roadmaps?
• Does the product strategy focus on short-term or long-term goals?
• What defines success, increasing velocity or maximizing outcome?
• Do teams need to define and conquer or can they focus on one goal at a time?
• Are teams encouraged to create more features or run more experiments?

The items on the left side of those questions (e.g., output as opposed to outcome roadmaps) indicate that your team is focused on short-term goals, while the items on the right (e.g., maximizing outcome as opposed to increasing velocity) suggest your team is empowered to create the future.

It’s fundamental to understand your status quo so you can act. Over the years, I’ve learned that, ironically, accelerating velocity will slow down value creation. The way of working has a significant impact on your team’s results.

In general, I see three common ways of working:

1. Velocity-driven
2. Research-driven
3. Value-driven

To illustrate the three scenarios, let’s consider a team of seven people: five software engineers, a product manager, and a product designer.

Over 200k developers and product managers use LogRocket to create better digital experiences

Learn more →

1. Velocity-driven

When output means success, teams will excessively focus on creating more features. As a result, they will focus about 90 percent of their attention on delivery and 10 percent on discovery.

In essence, the whole team works to create output as fast as possible. As a result:

• Product managers strive to write clear backlog items and get them estimated as precisely as possible with the team
• Product designers create well-thought-out and highly-defined prototypes so software engineers can easily follow them
• Software engineers code based on backlog items and high-fidelity prototypes

The work mode is efficient, and the team can accelerate delivery. At first glance, it looks like everything is perfect, but there’s a danger: when you put all your energy into the present, somebody else builds the future because you’re blind to it.

The short-term results may be good, but that compromises the future.

2. Research-driven

The other extreme is to have an absolute focus on the future. This leads the team to ignore velocity because they envision uncovering hidden opportunities to create outstanding solutions. The intention is genuine, but the results are questionable because the team resists committing to delivery.

The team uses 70 percent of its time to discover the future and the remaining to deliver features. When that happens, you will observe the following:

• Product managers are obsessed with validation; they don’t want to commit to a solution without running dozens of experiments to ensure it’s right
• Product designers continuously explore different ways of creating value for customers; they strive to empathize with customers and understand what matters to them
• Software engineers focus on creating low-level solutions to learn what works and what doesn’t. Yet, the experiments are lengthy because collecting strong evidence takes time

With an extreme focus on research, management will mistrust the team because velocity is unsatisfactory. That’s not sustainable.

When teams live in the future, somebody else will create the present.

3. Value-driven

The most sustainable way of working, in my experience, is what I call value-driven. It’s a combination of the best sides of velocity and research-driven — a meaningful balance between present and future. That said, it’s a more complicated way of working because it requires a dual-track approach.

Part of the team will work around 70 percent in the future and 30 percent in the present, while the other part will work 70 percent in the present and 30 percent in the future.

You may wonder, how does that happen? Wouldn’t it be easier to separate the teams? Separating the teams isn’t an option because it’d create handovers and lack of accountability, which I cannot recommend.

A value-driven team has the following:

• Future — A product trio or equivalent (product manager, software engineer, and designer) explores the future, embarking on a discovery journey that paves the way for the product vision while aligned with the strategy. They run multiple experiments, drop bad ideas as fast as possible, and bring the good ones to the wider team
• Present — The team members, except the product trio, focus on the now and strive to create quality features as fast as possible. They make delivery efficient while measuring outcomes to ensure their output is valuable
• Together — When the product trio realizes something is worth pursuing, they unite with the whole team to craft the future. They ideate on multiple solutions and run experiments to choose which solution is worth building

Working as a value-driven team is different for most organizations; it requires getting comfortable with the uncomfortable. Teams must step into the unknown, try ideas, fail, drop bad ones, try again, and so on. It takes a lot of energy, but the results are promising.

With the balance between the present and the future, teams can create the present while paving the way for the future.

Getting support from management

Becoming a value-driven team is easier said than done. If you’re in a velocity-driven scenario, management won’t support a massive change from one day to another. But you can do something to get them to listen to you.

I used to think management would listen to reason because they are highly qualified. But most adults don’t like being lectured. Don’t try giving lessons or being dogmatic on ways of working.

Here’s what worked for me:

• Create a report comparing output vs. outcome over the last six months
• Compare how often customers use recently created features
• Share the analysis with management

These reports might help you identify that many features are never used and the value created is lower than expected. That would be all you need to ask the magic question, “Do you want us to continue working this way?”

No intelligent business leader wants to see the team creating features nobody uses or that create little business value. But they also resist massive chances.

You can suggest one of the following solutions, depending on your situation:

• Adapt one team to work as a value-driven team
• Suggest that the roadmap have a 20 percent focus on outcomes

The goal is to help management open their minds to try something different. Then, it’s your responsibility to deliver results and gain trust to move toward value-driven teams gradually.

Key takeaways

• Increasing velocity doesn’t necessarily mean maximizing value
• An extreme focus on the present will compromise future opportunities, leaving you vulnerable to competition
• An obsession with research may uncover opportunities, but it will disable you from creating value fast enough
• Balancing the present and future within teams enables creating value today while discovering what matters tomorrow
• Help management see reality and offer a hand to transform it

Featured image source: IconScout

LogRocket generates product insights that lead to meaningful action

LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.

With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.

Get your teams on the same page — try LogRocket today.