In today’s rapidly evolving business landscape and with the availability of ready-made technical infrastructure, frameworks, tools and B2B SaaS products, creating products is no longer the biggest challenge. Instead, it’s about ensuring that you’re building the right product which is a product market fit, and with the agility to adapt to ever-changing customer needs. 

In the world of startups, the Lean Startup methodology has fundamentally changed how new businesses are created. But Lean Startup principles are not just for startups—they hold immense potential for established companies seeking to innovate and stay competitive in today’s rapidly changing markets. 

The key to this transformation lies in adopting a more scientific, disciplined and capital efficient method for discovering and building products and services that people love, one that is focused on learning and customer validation at every step.

The term "capital efficient" is very important as we waste tons of time and money in the work we do. Instead of building a feature or a product which nobody uses, we can try to assess the need of it in a more capital efficient way before building it.

This approach can be immensely valuable for the features to be built on an existing product.

In a startup, no facts exist inside the building, only opinions. Get outside the building.

– Steve Blank

This applies to Product Backlog Items of an Agile project as well.  In many cases such backlog items are just a bunch of guesses. Any value of a feature for a product is generated only when someone uses it. If nobody uses a feature, the value is zero and the feature delivered becomes waste. Inside a building we need to be humble that we don't know how users are going to react for any feature or how it's going to work. Only when people start using something, do they get to know the problems they may be facing. We actually need to get outside the building and know facts in the real-world environment from users.

How about if we validate or invalidate our hypothesis (guess) quickly and sometimes without creating full-fledged features or a product.

Here are some examples:

Dropbox: Before building the entire product, Dropbox released a demo video explaining how the service would work. The MVP in this case was the video itself, which helped Dropbox gauge interest and gather early sign ups before writing extensive code.

Zappos: The early version of Zappos was an MVP where the founder took photos of shoes from local stores and posted them online. When someone made a purchase, he would go buy the shoes and ship them. This was a quick and low-cost way to test the idea of selling shoes online.

There are similar examples for extension of an existing product as well.

In one of the insurance companies, relationship managers were categorized in terms of A and B categories based on the amount of revenue they generated for insurance policies and customer feedback scores they received. So category A relationship managers were supposedly better placed compared to category B relationship managers. 

The company had a poor induction rate for new customers for the insurance policies. During one of the product management brainstorming it was decided that it will be good if category A relationship managers serve these new customers, there will be better acquisition rate for new customers. For that purpose, they wanted to change the workflow and the way that application worked for the entire country. It was a very costly affair and would cost the company in millions in the anticipation of earning a lot more from it.

Instead of directly implementing this hypothesis, their team decided to invalidate this hypothesis first in a very cost efficient way. Instead of focusing on the entire country they focus on one state of the United States as that's where they were based. Instead of changing the entire workflow in the application, they made the changes in a very frugal way which required a lot less change in the application and could be done within a sprint. This way, the traffic of new customers reached Category A relationship managers for this one state. Based on the measurements, the team realized that the amount of conversion for new customers didn't change as Category A relationship managers started interacting. In some cases, it even reduced further.

The team went back to the leadership with their measurements and mentioned that there has been no change in terms of new customer conversions. It was evident that there was no factual basis of this hypothesis. Based on the measurements the team came out with, the leadership decided not to go ahead with this idea and in the process saved a lot of time and money.

Build-Measure-Learn Cycle and MVP (or Riskiest Assumption Test - RAT)

The Build-Measure-Learn feedback loop is the cornerstone of the Lean Startup methodology. It allows teams to experiment with small, iterative versions of a product, quickly gather data, and adjust course based on what they’ve learned.

Build

Start with a Minimum Viable Product (MVP). The simplest version of your product that allows you to start the learning process. This might be a basic prototype or even just a landing page. The goal is not to build a perfect product but to quickly test whether your assumptions about the product are correct.

Measure

Once your MVP is out in the market, gather data. Use tools like A/B testing, customer interviews, and analytics to measure how customers are interacting with the product. Are they using it the way you expected? Are they even interested in it?

Learn

The data you collect from your MVP should help you validate or invalidate your assumptions. If your hypothesis is confirmed, you can continue refining the product. If not, it’s time to pivot—change direction and try a new hypothesis.

One of the important points which may confuse people is the term MVP itself. In " The Lean Startup" book as well Eric Ries mentioned it clearly.

"MVP is not necessarily the smallest product imaginable; it is simply the fastest way to get through the Build-Measure-Learn feedback loop with the minimum amount of effort."

The real purpose of an MVP is to reduce risk by testing your most critical assumption quickly. The MVP concept has been used so much that it has lost its original intent. Many times, people think of it as a simplified version of the first product release, but this leads to MVPs becoming far more complicated than intended. As a result, they often end up too complex for a quick test and too poorly made to be considered a finished product.

A Riskiest Assumption Test (RAT) is far more precise. It focuses on testing the most uncertain assumption behind your idea with the bare minimum effort. There’s no need to worry about perfect code or flawless design, and you avoid the risk of turning your test into a premature product.

A RAT emphasizes learning through small, manageable steps. It helps you move forward by validating each critical assumption one at a time. With each test, you gain more confidence in the viability of your idea.

The key to this process is conducting rapid, small experiments. The question to ask yourself is: what’s the smallest test you can do to challenge your biggest assumption? The goal is to “maximize the rate of learning by minimizing the time to try things.” It’s not just about reducing time, but dramatically shortening it.

The example of Dropbox releasing a demo video explaining how the service would work instead of releasing a product is an idea towards validating RAT.

Someone thinking of conducting a unique workshop around Product Management and validating the assumption if people will be interested in the workshop or not, goes ahead with the simple landing page of workshop on Google ads and assessing the response, is another idea of validating RAT.

Every new idea should start with a Riskiest Assumption Test, and this principle isn’t limited to startups. Established companies need it just as much—if not more. When a business has been operating successfully for years, there’s a risk of becoming complacent. This false sense of security can lead to wasted resources on building something that no one really wants.

Customer Development: Get Outside the Building

The Lean Startup approach places a strong emphasis on customer development, a concept I’ve adapted from Steve Blank. In established organizations, it’s easy to fall into the trap of relying on internal assumptions or the loudest voices in the room to guide product development. 

Customer development requires teams to talk to real users. This feedback loop is crucial in understanding what customers truly need, not what we think they need. For existing companies, this might mean conducting more field research, running usability tests, or holding direct conversations with customers to gather insights.

A company like GE, for example, has successfully applied Lean Startup principles in its FastWorks program, where they tested early-stage products with customers before committing to full-scale production. By doing so, they saved millions of dollars that would have been spent on features that customers didn’t actually want or need.

Innovation Accounting: Measuring What Matters

One of the biggest challenges in large organizations is the focus on traditional performance metrics—such as revenue, market share, or feature delivery timelines—that don’t always reflect the true value of innovation. Enter innovation accounting, a framework designed to measure progress in terms of validated learning.

In the Lean Startup approach, innovation accounting helps teams measure the effectiveness of their experiments. Innovation accounting is all about to know if your MVP is any good or not. Rather than tracking vanity metrics like website traffic or app downloads, you track the number of hypotheses tested, the speed of iteration, and learning what works and what doesn’t.

For example, Dropbox used innovation accounting to validate their business model. Before writing a single line of code, they created an MVP in the form of a simple demo video. The overwhelming response from users validated the demand for their service, allowing them to move forward with confidence, knowing they had product-market fit.

Conclusion: Lean Startup for Lasting Innovation

Applying Lean Startup principles in existing product development allows established companies to remain agile and innovative in the face of growing competition and changing markets. By adopting practices like Build-Measure-Learn loops, customer development, and innovation accounting, companies can drastically reduce the risk of product failure while simultaneously improving product-market fit.

At Squads we pride in using Lean Startup principles for both emerging startups and for existing ones as well.

The key to success is maintaining a relentless focus on validated learning. Every decision, every feature, and every iteration should be designed to test a hypothesis, gather real-world data, and refine the product. By continuously learning from customers and iterating rapidly, established companies can create products that not only meet customer needs but do so in a capital-efficient and scalable way.

Lean Startup is not just a methodology for startups – it’s a blueprint for how any organization, regardless of size, can create lasting innovation.