Customer Experience

Customer Experience

Opinions expressed on this blog reflect the writer’s views and not the position of the Capgemini Group

Lean startup: the need for speed [Part 2 of 5]

This blog is the second part of a five-part series. Click to read Part 1, Part 3, Part 4 and Part 5.

In Part 1 of this series, we laid out the imperative for businesses to innovate and adapt or risk extinction. We proposed that adopting lean startup principles can help large companies do this. In this blog, we’ll begin investigating the specific challenges related to the “Build” phase of the “Build-Measure-Learn” cycle for lean startups.

General Electric and British Telecom (BT) are both large and complex organizations. They generally don’t conjure mental associations with agility, adaptability, and speed. Perception aside, most large companies have a difficult time making quick changes to their products or business models. They are not “agile”.

The agile framework

Small firms tend to adopt “agile” as they seek to create a sustainable and efficient engine for growth. Large firms are beginning to embrace it to maintain growth.

The agile framework is a modern-day anchor for companies to refocus on development speed and profitability. For a “lean startup”, it is a core tool within the “Build” phase of the “Build-Measure-Learn” cycle. Its aim is to deliver a product or service to a customer in the shortest time.

To which side of the agile manifesto scale does your company align?



Lean startups favor the left-hand principles, those that deliver speed and flexibility. Large organizations can struggle with aligning the above to their core value proposition. Let us consider the common waterfall development approach to an iterative one.

Waterfall methodologies prevail in most large organizations. This method created deep roots in organizations that now struggle to change to update their methods to match the market. British Telecom (BT) was able to change. BT focused on a few clear decisions, supported by executive management and backed by clear incentives.

All delivery programs were required to adopt a standard 90-day delivery cycle. This represented a seismic shift from the 12+ month delivery cycles that were previously commonplace.



Early in each delivery cycle, the program sets out clear targets for what it expects to achieve for the business during that cycle. These targets included a strong emphasis on the end-customer experience (a key component of the Lean Startup Principles).

At the end of the cycle, the program is assessed against these targets, and the outcome of this assessment will influence the timing of bonus payments for the program team members.

Delivering successful programs

Programs failing to deliver business value over a series of cycles face being closed down altogether. This places ownership on the (internal) customer to be clear about the business priorities and the features that would provide the greatest return on investment.

Successful programs require a strong collaborative approach between the business customers and the development community. Within BT, close collaboration is established at the outset of each project with required collaborative sessions. The onus rests on program teams to ensure this continues throughout the delivery cycle.

Given a choice, teams and organizations will pursue the traditional and comfortable methods that they know. At BT, a strong mandate ensured that all programs put the new practices to the test whether this seemed logical or not. This gave Agile a chance to take hold.

Implementing agile methodology, as BT did, highlights how large organizations can restructure a large workforce to a new way of thinking. It represents how a company that is neither lean nor a startup can adopt collaborative and innovative practices indicative of a “Lean Startup”.

Agile isn’t the only key ingredient for the Build phase of “Build-Measure-Learn” in Lean Startup, there is also an emphasis on producing a Minimal Viable Product (MVP).

In Part 3, we’ll explore some challenges large companies face in deploying MVPs that could risk brand equity or customer expectations.

About the author

Pragya Pandey
Pragya Pandey
Pragya is a Consultant at Capgemini Consulting based out of New York. She has experience in Technology M&A, Financial Media, and Management Consulting. She loves understanding the many meanings that “transformation” takes in the business environment today.

Leave a comment

Your email address will not be published. Required fields are marked *.