Do you know the impact of every feature you’ve developed? Can you tell the difference it made for your company? How much has it improved your business metrics, or how much money has it made? Well, if not, learning about growth development sounds like a plan for you.

Growth development isn’t your typical dev work. It pushes software engineers to work like product managers and validate ideas before perfecting them.
It’s what allows creating a big, measurable impact quickly.

At monday.com’s Growth group, our mission is to accelerate user activation, boost adoption, and retain engagement – all through data-driven iterations.
The features we develop are born from hypotheses we raise after diving into our user data. We later test the features using A/B tests and release them only when we’ve proven their impact.
But behind each success lies a set of challenges: How do we make experiments measurable, scalable, and cost-effective while still making a meaningful impact? 

In this article, I’ll break it down and show you how we use the growth methodology to create impact.

Growth Development Process

At its core, growth development is about spotting impactful opportunities, forming smart hypotheses, and using A/B tests to learn quickly. It’s a continuous loop of: 

We call this the learning loop, because we aim to constantly learn from our tests and apply those learnings in future solutions.  The entire team is involved in this process – product managers, designers, developers, and analysts. Decisions we make are not based on a hunch, but on data and evidence. This process isn’t the easiest method for developers; it forces us to also think like product managers and analysts, and it’s not always easy.

So how do we actually approach this in practice?

Spotting opportunities

In order to find new opportunities, we: 

• Analyze our data to find metrics that we aim to improve.
• Raise hypotheses for why the metrics aren’t where we want them to be.
• Suggest potential solutions.

This part is vital for us to make sure we focus on the best opportunities. Which can be prioritized using RICE or any other method you prefer.

Planning

Once we set our course on a solution we want to develop, we go into the planning and development phases.
We need to plan the development in a way that helps us prove (or disprove) our hypothesis in the quickest, simplest way possible.

Reaching an MVT

We ask ourselves: How crucial is every part of the feature for checking the hypothesis, and what is the development cost? Given that resources (especially developers’ time) are often limited and we can’t afford to chase perfection early on.
That’s why we divide development into phases.
The first step only contains the MVT – minimum viable test – the most crucial parts for testing the hypothesis.

It allows us to validate if an idea has a real impact before investing significant time and effort in polishing it.

Let’s look at a specific example to demonstrate how our planning process saved us a lot of valuable time:
In our user onboarding process, we provide the first user of the account a guided board setup experience for creating their first board. Later on, if users want to add new boards, they can do so without our assistance.

The problem – We noticed that users tend to have lower usage rates on new boards than on their first board.
The opportunity – If users use their new board more, adoption metrics will improve.
The hypothesis – Users need guidance when creating a new board.
The solution – Providing a guided board setup experience.

We already had an existing wizard, designed to guide users with their first board creation in the onboarding flow. For this solution, we thought about creating a new design with several new features. But because we first tested our hypothesis before putting a lot of effort into the solution, we decided to use the existing wizard from the onboarding process and only make minor adjustments. Since the final design touches aren’t the crucial point here, the overall solution is.

That way, we saved crucial development time and were able to test our hypothesis much quicker.

Initial design

Final feature design

In this particular case, we weren’t able to improve board usage among our users, and the feature wasn’t released. So our method proved itself – we saved a lot of valuable time by sticking to the MVT!

Developing

Now that we have found opportunities and planned the execution, we can get to writing some code.

When starting the development process, there are a few important things you have to consider:

1. Keeping the hypothesis in mind
2. Cost effectiveness
3. Adding relevant measurement
4. Planning for the future

Now, let’s break down each of these points and see how they can guide the development process.

1. Keeping the hypothesis in mind
   As growth developers, we are involved in the process from day one. We identify opportunities, suggest hypotheses and possible solutions, and develop them. Naturally, our feelings are involved here; we want our ideas to succeed. But in growth development, we have to set that aside and stay focused on what really matters: impact.
   Our job isn’t to build the version of the feature we hope will work or ultimately want to ship – it’s to build the version that best tests the hypothesis. That means staying disciplined, prioritizing measurable outcomes, and letting the results – not our preferences – guide what comes next.
2. Cost effectiveness
   In growth development, we aim to do more with less, we search for ways to provide the same solution at a lower cost – whether that’s time, complexity or effort. Not every solution needs to be the most robust, scalable or perfect. In fact, aiming for that too early can slow us down. We do this by applying the 80/20 rule: What’s the simplest implementation that achieves 80% of the impact with 20% of the effort?
   As long as the user experience isn’t compromised and we can still reliably test our hypothesis, a leaner solution is not just acceptable – it’s preferred. This mindset helps us move fast, learn quickly, and stay focused on what actually drives results.

   This mindset helped us in a recent experiment that tackled the conversion rates for users joining existing accounts.

   The hypothesis was that offering a free trial to joiners would improve their conversion-to-pay rates. To facilitate this trial, we had to create a new type of user entity on our platform. Creating a new type of entity from scratch is a big effort that involves multiple teams across different departments within the company, from Security to BI and even Billing.But, we knew that as we test this feature, we might be proven wrong about our initial hypothesis or solution, and all this work might not even be released.So we decided to take a simpler approach, just for the test.

   We added a new attribute to our user entity instead of creating a whole new entity.
   
   That allowed us to test the feature quickly and prove our hypothesis.
   The test won! We ended up releasing the feature. And don’t you worry, we created the new trial user entity before releasing it.

3. Adding relevant events
   Developing a generic, cost-effective solution is great, but we have to be able to measure our impact.

   When we design a solution, we need to prepare for the question: Did it work? That means embedding the right events and metrics directly into the code as we build the feature, not afterward. Our goal is to lay the groundwork for meaningful measurement in the future. We don’t just ship code, we ship visibility.

   We need to include any event or metric that might help answer future questions in a variety of categories like user flow & navigation, feature engagement, user intent, performance, etc. Example questions can be: How many users moved from the first page to the second? What was the average load time? How many users interacted with the feature, and how many closed it immediately?
   This part is crucial as we will need some data for the next phases, to determine what to focus on and how to advance.

   To make sure nothing is missed, we involve analysts early in the development process. They can help define what needs to be tracked and ensure we’re capturing what really matters.

4. Planning for the future
   If our test wins, we have to make adjustments to ship the highest standard of code. We must be aware of the compromises we took while developing the MVT and know how we plan to address them when fully releasing a winning test.
   Now you know how taking advantage of the growth methodology can improve your impact. Bring it into the process next time you build a feature and turn your work into measurable value for your team and company.