Michael Goitein

Are software developers really the bottleneck to value delivery?

In a recent meeting, a senior executive asked a product manager why they couldn’t deliver more of the features requested for an upcoming quarter. The executive, offering support, said, “I’d be happy to just get you another four developers…”

After 20+ years in Tech consulting, across a wide array of web & mobile front- and back-end technologies, with everything from tiny startups to established, 200-year-old enterprises, I’ve seen this pattern emerge consistently – the underlying assumption that software development is the blocker.

And increasingly over the past 10 years, there’s been this hope that Agile would finally fix that problem.

Twice the work in half the time…?

I believe that software engineering shortages are not a cause but a symptom.

We’ll look into where the real problem lies, why asking Agile to fix the problem has only created more issues. and where I believe the real solution lies. Product teams are tasked with delivering from time-sequenced roadmaps, typically made of a random series of stakeholder commitments. Planning is done in advance either every quarter (if teams are lucky), or up to a year or more in advance. After months of requirements gathering, when the work finally comes to the product team for action, it’s either been elaborated too far in advance in isolation from the team, or cryptically vague.

Stakeholders then decry that teams aren’t moving fast enough because they’re unable to get these requests built and delivered at their arbitrarily-dictated roadmap cadence.

Agile to the rescue?

Agile was tapped by the enterprise for one reason – To fix the development team’s efficiency problem.

Note one of the original Agile Manifesto signees, Jeff Sutherland, gained notoriety a few years back with his book and associated TEDx talk touting Scrum as the way to get your teams to do “Twice the Work in Half the Time.” (i.e., 4X the work…?) This is absolute catnip for executives and stakeholders of all stripes tired of waiting for their pet projects to get delivered.

So the goal of Agile in the Enterprise has really been focused on getting teams super-efficient to pushing out everything on their roadmaps.

Why are teams being asked to build these things?

With this sole focus on efficiency, and building and delivering “stuff,” no one has thought to question-

• How good are these ideas? Are they as good as we think they are?
• Will they really make our clients happy and successful?
• How will they contribute to tangible business value?

Set Up to Fail

Given this dynamic, even when product teams are delivering efficiently, all kinds of worthless things that clients will never use can get quite efficiently pushed out the door.

Worse, the really important things that clients really do need are getting missed because large enterprises tend to organize around internal silo structures, rather than end-to-end client experience value streams. Without that client experience-centricity, it’s only natural that key pieces get over-engineered while other critical gaps occur.

And when things do go off the rails, IT continues to put product teams under the efficiency microscope (burndown), while “the business” plows ahead in isolation on an unending stream of disconnected feature request ideas, stocking roadmaps stretching off into the future. But if the team has just shipped 2-3 features with their latest release, and one of them has not only negated the other two, but beyond that, caused entire critical segments of their user base to get frustrated and churn, what should happen then?

And who’s supposed to be tracking that and take corrective action?

Product focus to the rescue

I’ve become increasingly convinced that enterprise embracement of a product focus, versus a legacy project focus, can provide a clue.

As leading product- and design-driven companies like Netflix, Amazon, and AirBnB demonstrate, the goal of modern software development is first and foremost, on problem-solving over delivery, where the best teams drive a continuous organization-wide learning process, where savvy leaders strive to optimize for effectiveness, build just enough to learn from, and continuously Iterate. 

But prioritizing the Product discipline has to be a conscious choice.

What gets managed in Product Management?

Ironically, Product Managers manage neither the development team, nor their work.

Yet without a Product Management focus, it’s impossible to provide holistic meaning and clarity around what teams should be building, when, and why.

Not Just Competing Stakeholder Requests, but the Unfolding of a Strategy

Instead of efficiently pushing out lists of features in isolation, product-driven teams are focused on the higher-level organizational Mission – how that flows to Vision, which results in strategy, and how can teams continuously deliver on that strategy by delivering on measurable, data-driven changes in user behavior targeted through Outcome-focused Objectives and Key Results (OKRs).

IT Project vs. Product Focus

Now take a step back and remember how IT tends to view their mission – they’re a

• Technology-led 
• Cost center 
• Managing Projects and “Resources” (people) to 
• Deliver Features
• Incentivized for an
• Efficiency-driven
• Binary feature delivery model (ship=1=good)

While the Product Organization seeks to be is teams of 

• Mission-, Vision- and Strategy-led
• Value creators 
• Leading Products and People to
• Deliver Business Outcomes
• Incentivized for an 
• Effectiveness-focused
• Empirically data-driven, 
• Problem solving model (customer behavior change+positive business value impact=good) 

Asking a New Question first

So Agile hasn’t really let us down, so much as been the wrong question to ask the entire time.

Before putting pressure on Agile to optimize delivery at the team level, companies should focus on an enterprise-wide client experience product focus, which will open the door to a strategic product emphasis on delivering more rewarding user experiences as well as better business results.

The Unifying Power of Product

A truly empowered Product Organization starts with a unifying Mission, Vision, and Strategy.

They break that down into a client journey underscored by client-centric success metrics that provide leading indicators of client behavior that equal success for both them and the business. Teams then employ Continuous Discovery to figure how to best Discover and Deliver solutions through autonomous, self-organizing, empowered product teams. With a data-driven focus on the right metrics, the most inspiring vision and insightful business strategy can get transformed into motivated teams building the right things.

When teams are finally empowered to focus on solving the fewer, highest-priority product-driven client challenges that also deliver real business outcomes, rather than the many disjointed feature requests, there will always be enough development cycles.

“Negative – South Melbourne, Victoria, circa 1934” by Kerr Bros Studio is licensed under CC PDM 1.0