Budget and time for ideas that fail 80% of the time: how we set up growth hacking

You change a button colour, draw some new banners, open a chat for fresh ideas and call it all growth hacking. It looks as if the work has gained new scale and a trendy format. Sales, however, may never find out.

Growth hacking helps you find ways to grow through fast, low-cost experiments. We find a problem, form a hypothesis, test it with limited spend in a limited time and decide whether the solution is worth rolling out more widely. You can look for opportunities along the entire customer journey, including lead handling, repeat purchases and referrals. Sometimes unexpected ideas come from old analytics data that had been piling up for years and taking up several gigabytes on servers for nothing.

At an international construction company I ran such a team alongside my main job. It included designers, developers, PPC specialists, brand managers, analysts, call centre staff and CRM specialists. For specific hypotheses, people teamed up in small groups.

Each member saw a different part of the problem. The marketer noticed an expensive lead, the analyst found leaks in the funnel, the sales manager knew why meetings fell through. Working together let us test a solution where departments meet. A solution that worked was then handed over to day-to-day work, with an owner and resources for implementation.

How this differs from regular work

This question caused conflicts between the line managers of our team members. Some of them considered growth hacking unnecessary: employees are supposed to improve ads, websites and sales anyway.

There is some sense in that. A good designer thinks about usability, an analyst looks for leaks, a marketer tests new approaches. But everyone has a department plan, a budget, a task queue, five rounds of approvals (sometimes including the owner's dog) and a boss who needed the result yesterday. So at the start we agreed with the owners on the most important conditions:

• 10-20% of the budget for testing hypotheses;

• no more than 10% of an employee's working time spent on testing hypotheses;

• only the growth hacking team approves hypotheses;

• a failed hypothesis is not a failure;

• speed of testing matters more than perfection;

• a successful hypothesis must move a metric that truly matters to the business and can be measured, not a useless vanity metric.

For example, in normal mode a designer gets a more or less clear task to prepare campaign materials. In the growth group, the designer works with colleagues to find out why people don't get as far as submitting a request, suggests a solution and takes part in testing it. A developer helps find the fastest way to build it, and an analyst decides before launch what to measure and what to compare it with.

If a form is broken, it needs fixing. If we assume that cutting fields will raise conversion without lowering lead quality, we need an experiment. Its outcome is unknown in advance, but it must have an owner, a budget and testing rules.

Regular work can include this process too. If a department regularly sets aside resources for it, arguing about the name makes no sense. Problems start when finding growth opportunities is written into job descriptions, but the whole calendar is filled with urgent tasks. That is why team members' time and the team's authority have to be agreed with their managers.

One metric per quarter

For each quarter we chose an OMTM (One Metric That Matters), a single shared metric that was important for the business in that particular period. The focus could be NPS at the very first stage, callback speed, cost per qualified lead or conversion to a meeting. We started from it when choosing hypotheses: which problem are we solving, and how will we know things got better. The whole team had a shared reference point, so a designer, an analyst and a CRM specialist could work on different tests that affected the same result.

This kept us from drifting into personal metrics, where everything grows in everyone's report while the company somehow doesn't notice. We tracked the other metrics too, so that improving one wouldn't cost too much at the next stage.

Where to look for hypotheses

Most often we started with a specific loss. Enough leads, but few meetings? Then first we look at call connection rates, response speed and reasons for refusal. A new ad channel can wait.

Friction analysis helps: where a person finds things hard, scary or unclear, or doesn't know what to do next. Picture an apartment buyer who wants to check prices and floor plans in the evening. Right away the website asks for a phone number and a three-page form. The person hasn't even chosen a kitchen yet, and they are already being invited into a serious relationship.

That can become a hypothesis: show the information people need and let them choose a time to talk. Then it has to be tested. Our sympathy for the buyer proves nothing on its own.

Examples of tests in real estate development

Creatives. We compare two approaches to the same offer for the same segment: an image of the courtyard versus an explanation of the monthly payment. Or, the other way round, the same message for different segments. We look at which option brings more qualified enquiries under comparable conditions. A cheap click alone is not enough. And we don't forget the long decision cycle in real estate.

Design. We swap blocks around: move prices and floor plans above the story about the project's advantages. Or we test video against a static image. Video can grab attention and slow the page down at the same time. What we care about is whether it helps the next action.

CRM. We test SMS reminders about a meeting: different tone of voice, sending time, way to reschedule and so on. We compare the share of visits that actually happened with the current scenario, taking into account sending costs and complaints.

Forms. We remove optional fields or cut steps. We check the quality of the enquiries we get: the sales managers will have to work with them later.

Personalisation. A visitor who looked at three-bedroom apartments is shown matching floor plans on their next visit. We compare this with the general page and don't declare every change an improvement.

To find ideas, we studied frameworks. AARRR helps you see the stages of the customer journey, JTBD is for understanding the buyer's job to be done, and the "Five Whys" help find the root cause of a problem. We pick the method to fit the task. You can collect a whole set of acronyms without a single useful hypothesis.

Money and speed

We set aside 10% of the budget for hypotheses. This let us test ideas with uncertain outcomes while keeping spending under control. Successful solutions were scaled and handed over to ongoing work. Ten percent was our decision. Another company will need its own calculation.

Before launch we record the expected effect, audience, metric, comparison method, timeframe and owner. Separately, we agree on what must not get worse: for example, lead quality or the workload of sales managers and the call centre. We prioritise tests with a clear rationale, noticeable potential benefit and affordable cost. ICE and RICE help build the queue, but the team's score doesn't yet prove the idea is right.

A hypothesis should explain the expected connection. For example: "If, after booking a viewing, we send the client a map with directions and ask them to confirm the time, the share of meetings that actually happen will grow, because it will be easier for them to plan the visit." The trendy suggestion "let's build an AI Telegram bot" still needs working out: what problem does it solve, and why should it help.

It is important to build an MVP quickly, the minimum version needed for a test. To test reminders, it is sometimes enough to manually send messages to some of the relevant clients, respecting their consent to be contacted. A bot with a personal account can be built once the benefit is confirmed. At the same time, the feature being tested has to work: a broken form tells you little about demand.

For fast tests we introduced Amplitude. Event-based analytics lets you see user actions and drop-offs between funnel steps. But events have to be set up, data checked, and the test given time. Fast development doesn't make a small sample more convincing.

How the team worked

A member could test a hypothesis alone or propose a mini-team. The result of a joint hypothesis was split in KPI terms between the group members. One test didn't turn into five full achievements just because five people worked on it. This reduced the temptation to inflate the team. At the same time, leaving out a specialist you need just to protect your personal score would be odd too.

An experiment must keep a single owner who will see it through to a conclusion. The team needs access to data, dedicated time and the ability to launch a test. Otherwise any speed runs into the development team's answer: "we'll get back to this next quarter."

We met once a week for an hour. For half an hour we discussed ideas, current tests and obstacles. For the other half hour we studied frameworks and cases from large companies: we broke down how it worked, the conditions for success and whether we could apply it ourselves.

At the monthly review meeting, everyone presented three of their hypotheses, not necessarily successful ones, and reflected on them: which one they liked most and what it gave, which turned out more successful, which didn't work and why. A favourite idea and the one most useful for the business can easily be different.

Once a quarter we reviewed all hypotheses. It is worth keeping results in a shared database together with the test conditions and the decision that followed. A well-documented negative result can save you from unnecessary development, but for that the record still has to be found later.

From the outside this work looked easy: you come up with interesting things, get a budget, study cases. In practice we had to see tests through to results and admit our own mistakes, while still doing our main jobs.

By my estimate, about 20% of the original team held on in this mode and consistently hit their KPIs without burning out or leaving. That doesn't make the rest bad specialists. Finding and testing solutions on your own demands a different kind of effort. Here a manager should also check how the work is organised: whether people have enough time, help and support from their direct bosses.

How to evaluate results

In our KPI model the target was 12 hypotheses per quarter. Quantity sets the rhythm, but alongside it you need to evaluate the quality of tests, the effect and whether successful solutions get implemented. If you pay only for the number of tests, the team will learn to run lots of small tests.

For the KPI, it didn't matter whether a hypothesis succeeded or not.

A failed hypothesis is not a mistake, it is a fact proven by numbers about where not to go.

Open, collective discussion of all hypotheses and a team moderator helped keep the list from swelling with obvious ideas and ones already tested.

We look at how much time passes from idea to conclusion, which experiments allow a decision and what changed in the business. Extra sales, savings or contribution to profit are calculated with the costs of testing and implementation taken into account.

A hypothetical example: conversion rose from 2% to 2.4%. That is an increase of 0.4 percentage points, or 20% relative to the starting level. Over 10,000 comparable visits we get 40 extra leads. They still have to turn into extra sales. If those enquiries qualify worse or need bigger discounts, the assessment of the result will change.

Comparing with last month doesn't separate our work from seasonality, price changes and shifts in the audience. Where possible, we use random assignment between comparable groups and decide the amount of data and the stopping rules in advance. If there isn't enough data, we honestly leave the question open. A nice line on a chart doesn't yet make an experiment successful.

After scaling, we check the effect again. We don't mechanically add up the percentages of tests that affected the same people. And we don't demand a preset share of wins: that pushes people to pick safe tests or embellish their conclusions.

It is also worth telling a negative result from a badly organised test. If the comparison is sound and there is no noticeable effect, you can drop the idea. If you forgot to set up events or didn't collect enough data, there are no grounds for that conclusion yet. These are different entries in the report and different next steps for the team.

Who it is for

Growth hacking is useful for a company that needs to understand what limits its growth, test a new channel, improve the customer journey or gauge demand before expensive development. AI speeds up preparing options and prototypes, but choosing useful tasks and evaluating results is still the team's job.

But! If leads are getting lost, the data is unreliable and the product doesn't deliver what it promises, fix the basics first.

If you decide to set up growth hacking in your company, choose one business problem and one shared metric for the quarter. Agree with managers on team members' time, set aside a budget and give the team the ability to launch tests quickly. Decide straight away who will implement successful solutions, otherwise they risk staying in the report.

And most importantly: give people the right to make mistakes, while demanding careful testing and honest conclusions.