The Product Growth Flywheel

“It’s super simple to build the company and the product.” We are yet to hear that from any entrepreneur. “It’s complex, uncertain, and chaotic.” We often hear from them. Indeed dealing with complexity, uncertainty, and chaos is hard. But it doesn’t have to be super hard? In today’s environment, entrepreneurs have many unfair advantages. It has never been more accessible to start a company—but it’s also never been more challenging to scale. This is why we need a new way to describe how technology companies grow. It is also why most people hire coaches and guides who can help them navigate and simplify the hard journey. “Product Growth Flywheel” is the ultimate solution.

At Leapfrog, we make it a bit easier and simpler. We have helped our clients build successful companies and products in the past. From our experience, we codified the experience into the playbooks and principles. We call that the growth flywheel. The growth flywheel makes the journey a bit simpler and easier that creates the difference between succeeding and failing.

The growth flywheel defines clear context, frameworks, and principles to make the right decision trade-offs. The Growth Flywheel is a playbook that harmonizes the Lean startup methodology to building the right product, design thinking method to discovering and solving the problem the right way, and agile method to delivering the right way by creating the virtuous cycle for growth. 

The Growth Flywheel has 3 stages.

  • Discover the product
  • Achieve product-market fit
  • Grow the product

Each of the above stages is deducted down to 3 steps. The faster we iterate these 3 steps of the growth flywheel, the better and sooner we get the results.

  1. Develop the strategy and break down strategy into a testable hypothesis 
  2. Build the minimum viable product to test the hypothesis
  3. Launch the product to the users

Before diving into any kind of business or product ventures you need clarity and answers on certain things. The flywheel answers such 3 very important questions for any product ventures.  

  1. What’s the right product to build?
  2. What’s the right way to build?
  3. What’s the right decision tradeoffs for each stage? 
Fig: Graphical Representation of The Product Growth Flywheel by Leapfrog Technology

We iterate to crystallize not just the product but also the strategy. The strategy is just someone’s opinion if it’s untested. We don’t want to base our product roadmap based on the strategy someone pulls out of thin air. For us, facts matter, opinions don’t. Test results are facts. Untested strategies are just opinions. Strategy crystallizes based on the user and market feedback. Iteration empowers the team to adapt to the feedback. 

A Case Study: The Nurse Management Platform using the Growth Flywheel

A case study on how the growth flywheel helped a real-life product life cycle and the challenges faced along with the growth flywheel’s role in solving them. 

At Leapfrog, we built a productivity platform for frontline leaders in the Healthcare provider industry. At present, its users are nurse managers. It helps nurse managers become 20 times productive at managing the nursing unit and nurses in the unit. The project kicked-off in September of 2017. 

In less than 3 years, the nurse management platform has almost reached the product-market fit. It has many paying customers. Though we are not able to reveal much, one who understands the Healthcare industry will admire the progress and the average sales size generated by the product. The sales cycle in the market is excruciatingly long. The adoption within the institution is long and expensive. The product needs stability and security from the day zero you launch in the market. The question here is how did the nurse managing productivity platform achieve traction in a relatively short period.

Now, let us see how the Growth Flywheel resolves The platform’s challenges, transform an idea to product, and gain traction.

The platform sells to the hospitals. You need a product to sell to the hospital. But you need users to build the product. It’s a conundrum. It’s more of a chicken and egg problem. 

Here is how we resolved the problem.

Challenge 1: Discover the Product

Created a Prototype

We created a clickable design prototype for the sales team for a demo to the prospect. The sales cycle is long anyways. From the demo to a decision, it takes a month to close the deal. For many companies, that may be a disadvantage. But we used that period to our advantage. But the important question is how did we know what to put in the design prototype? 

We identified the core user in the hospital that we are building the product for. For the platform, it was nurse managers. We reached out to nurse managers from different hospitals and conducted interviews to understand their needs and problems. We iterated between creating a design prototype and conducting interviews. It’s the design thinking process for solving problems. We did that for several weeks. For us launching the product is not about coding the product and delivering the product. Creating a design prototype and putting in front of the users is launching the product. The iteration cycle is much faster because the feedback cycle is fast and it doesn’t take that long to change pixels to incorporate the feedback. 

After we reached the point where we could develop the minimum viable product and we developed the minimum viable product. From the date we started working on the idea, we launched our first MVP to our pilot location. Our clickable design prototype helped to accelerate the decision process at the pilot location. 

Pilot the Minimum Viable Product 

Let us circle back to the unfair advantage we listed at the beginning. Founders had the Rolodex and earned respect in the industry to gain access to the pilot. Of course, a clickable prototype that looked great and easy to use.

Triaged the Feedback

There were three types of user groups that helped to discover the product that’s not too specific to the pilot location but generalizable to all hospitals. 

  • The sales team got feedback from potential buyers. That helped to crystallize the story. The initial story was about AI-driven tools to reduce retention. The story evolved into Enable frontline leaders to manage staff engagement.
  • Feedback from the User advisory committee those are outside the pilot location.
  • Feedback from the real users from the pilot location and product analytics data.

There are a few important principles to note during the discovery phase for the product. Those principles are true for other enterprise SaaS companies as well.

Design a product that looks good and easy to use.

The platform’s user interface was beautiful, modern, and intuitive that helped to initiate the conversation and attract the leads. There is a caveat. Filter out the design feedback from the problem validation and solution validation feedback when during user interviews. 

Don’t build the product unless you find out what you are replacing

In another word, don’t invent the solution to discover the people who have invented the solution.

We are not nurse managers. We can’t use the product every day. So, there is no way to figure out what’s important and what’s not. Therefore, we mustn’t invent a solution. We must discover the people who have invented the solution. In our case, during the interview process, our job was to look for the problem and figure how the nurse manager has solved the problem. If they haven’t solved the problem in a hackish way then that problem is not worth solving. We would nurse managers who would have gone out of their way to glue together a solution for their problems.

When you assemble smart people then they want to invent a solution. Inventing a solution can be a curse when you are not the user of the product. You start looking at the problem from that lens of that solution. It’s a predetermined solution. It assumes you know what you don’t know. The platform didn’t make the mistake of inventing the solution. Its approach was to discover the person who invented the solution.

Nurse managers have to manage 80-120 nurses in a unit. Even a small problem can snowball into a huge problem because of the scale. If some problem is acute, important, and urgent then there must be someone who must have glued together with a makeshift solution to the problem. Our job is to discover that person, solution, and process to solve the problem through inquiry. Then we followed up to understand the habit cycle for the problem.

Understand the habit cycle for the problem and solution

We asked a question such as “when was the last time you had the problem?”, “How did you solve the problem?”, “how many times do you have the problem?”. We wanted to understand what triggered the problem, what action they took, and what value they got, how acute, urgent, and important were the problems. Understanding the habit cycle helped us to prioritize the problems, solutions.

The ah-ha moment was when we realized that The platform needs to replace the physical file that nurse managers have to maintain for each nurse they manage. Some awesome nurse managers created a highly organized employee file. That contained many things that she needed to take care of daily. The platform needs to make it 20 times faster to maintain that file and when we have data then we can automate a lot more. That will inherently improve nurse managers’ productivity by multiple folds and free up the time they needed to care for their employees. That ultimately results in great culture in the unit and employee retention. That was the ultimate benefit. Happy employees who stay longer in the institution. 

The first stage answered the first question: What is the right product to build?

It’s a productivity tool for nurse managers that help manage and engage with their staff. 

After we got directionally correct about the product strategy, we kept on adding and removing features based on the real usage data, sales feedback, and user advisory committee. We created and prioritized our roadmap based on acuity, urgency, and value of the feature. Every iteration we optimized and augmented the product. It led closer to the product-market fit. The growth in daily engagement signals product-market fit and that growth is remarkable. 

The virtuous cycle:

The sales team had a tangible product to sell. This helped gain more sales and also ensure a better product with enhanced features and usability. There is real feedback from the users through qualitative interviews and product analytics. There is early feedback about new features from the user advisory committee. Every cycle the product gets stronger and better. The beauty of the following growth flywheel playbook. 

Challenge 2: What is the right product development process?

People talk about agile software development. Let us say even if we follow agile using scrum there are many ways to follow scrum. Some do one week sprint, others do two weeks sprint, and a few others do 6 weeks sprint. Even in the design thinking process for discovery and validation, people use low fidelity prototypes, in-person interviews, design sprints, and so on. The one cadence that fits for one product and company may not fit for another company. We had to factor in various variables such as data ingestion frequency, discovery frequency, and availability of users for interviews. We are working with nurse managers. Their job is not giving feedback. Their job is to do their job. We got to work with their schedule. The early launch through the pilot phase and discovery though the user advisory committee helped us crystallize the process that works backward from user needs. We fit those needs into the agile software development framework. 

At present, we are in a 2 weeks sprint cycle using scrum. Our lead time for the ETL process is weekly. Our development roadmap is 6 weeks out. We follow weekly design sprints. The feedback cycle during the design phase is faster than the feedback cycle post-development phase. Our directional roadmap is 2 quarters. All of these we figured out early because we launched early. Our setup allowed us to recalibrate based on the experiment results. Our user interviews are mostly remote. We augment remote interviews with onsite interviews. But it’s mostly remote. That works for us. We used a low fidelity prototype before the pilot phase. But after we launched the pilot phase we started using a hi-fidelity prototype. 

We imagine the alternate world where we have the untested ironclad strategy that we made out of thin air, the product we invented without working with users, and the process we throat down to the users. That may work for some lucky organizations. But we count on being scientific rather on being lucky. We fit into the users and markets rather than try to throat down our process to the users and market. 

It helped us figure out the kinks of design thinking and agile software development that suits the context of The platform. The right way that works for The platform fits right back into the virtuous cycle and accelerates that cycle. That’s the benefit of the growth flywheel.

Challenge 3: What are the right tradeoffs for making decisions?

What is the right technology architecture?

What should you prioritize more new feature development or infrastructure development? 

Should we scale and automate the ETL process? How much should we invest in the scaling CI/CD? 

How do we structure the team?

The answer is ‘it depends’. At the early stage, there isn’t much to scale and automate. Hence, infrastructure-related tasks are about being scrappy and getting things done.

Having said that there are certain non-negotiable compliance-related things that we must prioritize. For example, the platform requires HIPPA and SOC2 compliance. 

  • Non-negotiables such as security and compliance: HIPPA and SOC2
  • CI/CD and software development hygiene
  • Automation

We started with a framework of 80-20 at the early stage. 80% of effort on finding the product marketing fit and 20% on infrastructure. 20% on the infrastructure was for non-negotiables, CI/CD best practices, and software development hygiene. Progressively as we marched towards the product-market fit, we increased our infrastructure-related development. We were scrappy about infrastructure at the early stage and as we are scaling we are making it shiny. When we had our first paying customer we increased our infrastructure effort to 25%. If we don’t have a product that users use every day then a great infrastructure isn’t going to help. Also, if we have a great product and don’t have scalable, secured, and stable infrastructure the product will fail. At present, our efforts are at 70% new features and 30% infrastructure. We started to automate a few ETL processes. This framework is organic and also signals that we are reaching the product-market fit. The growth flywheel helps us to make the right tradeoff without compromising on the right way to deliver the product.

Furthermore, it helped us identify the technology architecture that’s going to scale with the growth in the number of customers. We will have to recode most of the components we wrote for the early stage. That’s inevitable. We designed the architecture with autonomous units so that we can replace incrementally. We postponed our urge to jump right into premature solution development and led us to take the pragmatic decision. We didn’t lose momentum on customer development nor did we lose momentum on product development. At present, we create microservice for those we need to access repeatedly. For some, microservices are the holy grail. Sometimes we don’t need to create microservices for everything. 

Another important point is about deciding to structure the team. As the team size grew, we needed to break down one team into multiple teams. Our principle to design a team is “Team structure reflects product structure”. The product must have a lego-like structure. Independent and autonomous units that interlinked together to shape the final product. The team structure follows that independent and autonomous unit. It creates the foundation to move fast and agile at scale. Each team has autonomy, authority, and accountability for the part of the product they own. Each team can discover the problem, design the solution, develop, and deploy autonomously. The leader’s role is to synthesize and shape the team effort and outcomes. The growth flywheel reveals the right team structure for the current context and makes the leaders proactive about recalibrating the team structure when the product moves from the early stage to the pre-product-market fit state to the product-market fit stage. 

Tools and Technologies

The team requires the right toolset to become experts. The platform benefits from having a team that already are experts in tools, technologies, and processes that deliver high-quality outcomes. Below are the tools and technologies that enable the product team to execute the Growth Flywheel. 

Fig: Tools and Technologies used for the Product: The Nurse Management Platform


“It makes my work 20 times faster to do my daily work.” When we hear such comments from our users we know that we are onto something. We created a product that makes users more and more productive. We understand the pulse of the product. It’s remarkable progress to achieve that in two and a half years. The platform’s customers start experiencing happy and engaged customers. Nurse managers experience the load taken off their bodies.

Traction is the most important signal for growth. Traction in terms of annual recurring revenue, forecasted revenue, daily user engagement. Though we can’t disclose the numbers in the case study. The delta is high and positive. The platform has seven paying customers and each customer has hundreds of users. Those users use the product several times a day. Increasingly, The platform is becoming the main tool to do the nurse manager’s job.

The platform is on its way to becoming a remarkable company that solves an important productivity and team engagement problem for front line leadership such as nurse managers in the healthcare industry. The platform is in the right market. We credit founders for understanding the secrets of the market, creating the new category, and positioning the product. Leapfrog provides the Growth Flywheel, enabling the platform to execute on their vision by creating a virtuous cycle strategy, development, and operations. Using the Growth flywheel, the founders discovered the right product to build, developed the right way, and decided the right tradeoffs. The founders and Leapfrog’s partnership grows stronger as the product accelerates towards bigger success.

More in Blogs

What Startups Can Learn From Apple Keynote Events InsightsProduct Management

What Startups Can Learn From Apple Keynote Events

Apple Keynote Events are a big deal. They host the special Apple Event a couple of times every year –

Read more
What can Product Managers Learn from Stand-Up Comics? Product Management

What can Product Managers Learn from Stand-Up Comics?

Product Management and stand-up comics may seem like entirely different art forms, but in fact, the parallels in the iteration

Read more
How to Successfully Build New Product Features? Product Management

How to Successfully Build New Product Features?

Many times, product owners can be confused about when and how to launch new product features. They often struggle with

Read more