The time it takes for an idea to get to market and add value can make or break an organization. In this two-part series, we look at how to radically reduce idea to market cycle time. First, we take a deep dive into the systemic problems that prevent organizations from being truly responsive to what customers need.
How long does it take your organization to get ideas to market? For organizations using a traditional workflow, new ideas can take as long as 18 to 24 months—or more—to get into a customer’s hands.
Worse, after all this time, effort, and money spent, organizations find that only a select few ideas actually deliver value to customers. Meanwhile, an upstart competitor has come out with a new product that is disrupting the marketplace, and incumbent organizations have to respond. After factoring in redos and rework, the real cycle times for delivering value are much longer.
Optimizing Idea to Market cycle times is much more than just an IT problem. What can organizations do to avoid this trap? First, they must understand what is keeping them from becoming a responsive organization. In this article, we’ll explore key systemic factors that underpin Idea to Market latency at traditional enterprises.
Death by Chevron
An executive flies from her home in New York to a conference venue in Atlanta. Would her door-to-door travel time be dramatically shorter if we only had faster airplanes?
In reality, flying time between these two cities only accounts for about a third of the total travel time she’s likely to experience. Similarly, software development at large enterprises tends to account for only a portion of “door-to-door” times.
For too many medium and large enterprises, the “happy path” to turn a new idea into something that creates value in the market looks like this, also known as death by chevron:
Adding to the misery, is development drag due to a legacy technology ecosystem and siloed communication and collaboration structures.
In recent years, many organizations have adopted agile software delivery methods to improve software quality and time to market. However, such efforts tend to focus attention on a narrow segment of the full value chain (the “Development” and “Testing” chevrons in the diagram), while leaving upfront planning, and downstream release processes intact. This only results in limited local optimization, if any.
This flawed pattern is now so common that Forrester Research gave it a name: Water-Scrum-Fall.
Idea to Market cycle times in this world are affected by specific types of delays: queuing delays, build-out delays, and rework delays. Each one adds its own dysfunction to the process of building value for the customer.
Queuing Delays
These are prolonged wait states between process steps. The most significant types of queuing delays are:
|
Waiting for initial approval and prioritization |
This often takes the form of detailed project charters that need formal sign-off from one or more levels of management, initial sizing (which can itself be a fool’s bargain), and then formal prioritization against existing items in queue. All of this effort, even before any part of the idea is validated with end users. |
|
Waiting for budget approval |
Larger investments typically need to wait for annual budgeting cycles, and smaller ones for quarterly cycles. Organizations lose time waiting for the budget cycle, but the most detrimental effect is the prescriptive solutions and deterministic plans that onerous approval and audit processes seem to require. This does little to improve predictability of results, but is extremely effective in stifling innovation, experimentation, and the desire to learn from customer feedback. |
|
Waiting for release |
The classic last mile problem: working software awaiting scheduled performance test runs, security audits, compliance approvals, and error-prone, manual deployment processes that are only done every few months to contain risk of downtime. |
|
Waiting for the full batch |
Already built, high-value capabilities and features are often intentionally left sitting on the shelf waiting for other features to be built. This is driven by a desire to build a “complete” feature set that meets a wide range of presumed customer needs, to claim feature parity with competitor offerings, or simply out of fear that internal priorities will shift before more features can be built. |
Build-out delays
These are a drag on how quickly software can be designed, built and tested. The most prominent are:
-
Legacy architecture and systems
Even simple features or enhancements turn out to be time-consuming and fraught with the risk of breaking other parts of the system. Common culprits are:
-
large, monolithic legacy applications
-
critical business logic hidden away in database stored procedures with multiple layers of dependencies
-
large unpaid technical debt in application code
-
fragmented, duplicated data spread across multiple systems
-
Handoffs between horizontal functions
Delivering even a single, small feature can easily take ten handoffs, sequentially hopping work queues of functions like product management, user experience, enterprise architecture, database management, services development, app development, QA, security, configuration management, release management, and more, with a PMO team charged with coordinating everything.
Making matters worse are rigid, formal communication patterns designed more for blame avoidance rather than effectiveness or efficiency (“Can you fill out a Database Change Request Form for this and have it approved by my manager?”).
Not only do delivery timelines elongate rapidly, it would take a miracle for solution integrity and fidelity to survive this process and deliver the intended value.
Rework Delays
Any additional time spent fixing, redoing, and reworking ideas and software that fail to deliver value. Of course, this drastically increases value delivery cycle time and cost, but in a digital-first economy, this can also cause significant reputational damage.
Here are common reasons for why enterprises often end up building the wrong thing:
|
Reason |
Problem |
Example |
|
Poorly understood customer needs |
Solving for presumed customer needs, often confusing symptoms for the disease. |
“Customers keep calling for help with completing loan applications on our website, so let’s add searchable help pages.” |
|
Ill-conceived solutions |
Defining solutions without understanding context of use or validating value for end users. |
“Wouldn’t it be cool to have customers get credit score alerts on their Apple Watch?” |
|
Getting feedback too late |
Getting real world feedback only after features are fully built out, while assuming it will result only in incremental changes and small tweaks. |
“Build it and they will come.” |
|
Solving for “project” goals and deliverables instead of business outcomes |
When success is defined as delivering to a specification by a fixed date while staying under budget, innovation and learning are strongly disincentivized. It’s highly improbable that ideas that truly wow customers or elegantly solve complex problems will emerge. |
“The uninstall rate for our new iOS app seems to be high, but it was delivered on time and under-budget, so technically the project was a success.” |
Overarching Structural Challenges
A key consideration for optimizing Idea to Market cycle times is who is invested in the end business outcomes the enterprise is looking to achieve. The overarching challenges here are siloed business and IT organizations, and misplaced incentives.
If you’re an IT executive and you are measured on getting specified requirements implemented in the shortest time possible, that's what you will look to optimize. You may not care how long a product or feature idea sits in queue upstream, or whether building it helps achieve desired business outcomes. In fact, you’re likely to penalize your teams for trying to think creatively about the problem, because it could distract them from the task at hand.
Who in the organization then is charged with ensuring that the ideas that truly address customer need make it through to market, in the shortest possible period of time? If this has to be the CEO, then dysfunction has clearly taken over.
Unless organizations look critically at their entire idea to market value chain, address core structural challenges, and set out to solve for the delays outlined above, they will continue to deliver too little, too late for their customers.
In Part 2 of this short series, we will look at ways in which enterprises can avoid and address the different types of Idea to Market cycle time delays outlined in this post.
Thanks to my colleagues Aaron Sachs, Aneesh Lele, Anupam Kundu, Etienne Roux, Itamar Hassin and Shree Damani for their inputs and edits on draft versions of this post.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.