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.
To understand your current reality, reflect on the following questions:
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:
To illustrate the three scenarios, let’s consider a team of seven people: five software engineers, a product manager, and a product designer.
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:
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.
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:
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.
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:
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.
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:
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:
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.
Featured image source: IconScout
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.
A product specialist (PS) is a person with extensive knowledge about a specific product or product management-related responsibility.
Ben Hackett discusses the balance of revenue and core cultural values and how ruthless prioritization comes from first-principles thinking.
A project baseline acts as a reference point so you can compare project progress against your intended plan.
Kunal Thadani shares necessary qualities of a full-stack PM, including being resourceful, process-driven, and willing to wear many hats.
Learn more →
