To Cover: Everything That You Think Will Change Our App Growth
To cover everything you think will change our app growth, map how the right people find the app, reach a useful result, and decide whether to return or recommend it. Then use observed behavior to find the biggest obstacle and test one specific change. You can’t know in advance which change will work; the method is how you find out.
Start with one group and one job
“People who might use this” is too broad to guide a growth plan. Choose a group with a shared situation and a problem your app solves. For a household expense app, that might be three flatmates who regularly buy shared groceries and need to work out who owes whom.
Write down the moment that makes them look for help, then describe the result they want in ordinary words. For example: “When we share household bills, we want to see who paid and what each person owes.” This gives you something concrete to test in your page, demo, and product.
A common mistake is trying to appeal to every possible household at once. A student house, a couple, and a group of friends may split costs differently. Start with one group; broaden the message when you have evidence that another group has the same problem and responds to your solution.
Map each step from discovery to repeat use
Write down the actions someone needs to take before they get value. Keep each step specific enough that you could observe whether it happened.
- Discovery: A person with the problem finds your page or app.
- Understanding: They can tell who it’s for and what it helps them do.
- First useful result: They complete the main task and see an answer they can use.
- Return: They come back when the problem happens again.
- Recommendation: They tell someone else who has the same problem.
Choose a measure that matches each action. For example, count relevant page visits, people who start a demo, people who complete the main task, and people who return later. A signup alone doesn’t show that someone got value. If your current product doesn’t save work or support repeat use, don’t treat return use as something you can already judge.
Find the biggest observed drop-off
Don’t begin by adding features or buying more traffic. First find which step is losing the people you’ve reached. If visitors leave before they understand the product, test the explanation. If they start but don’t finish the main task, watch where it becomes confusing. If they finish but don’t return, find out whether the problem comes up again and whether the product helps when it does.
Here’s a made-up example, not a forecast or benchmark. Imagine 100 people from a flatmate-focused page visit a household expense demo. Thirty start it, 18 add a bill, and six join an early-access list. The biggest visible loss is before the demo starts: 70 visitors don’t begin. That suggests testing whether the page makes the audience and first result clear before investing time in new demo features.
Those counts don’t explain why people left. Ask a few people who fit the target group to try the page while you observe, or ask departing visitors a short, optional question. Look for a concrete obstacle: perhaps they can’t tell whether the demo saves bills, or they don’t know whether the result applies to their household. Don’t assume the reason from the numbers alone.
Test one change, then decide what to keep
Turn the suspected obstacle into a small test. State what you’ll change, who it’s for, what behavior you expect to change, and what result would make you keep or undo the change.
For instance: “Flatmates may not start because they can’t picture the result. We’ll put a worked shared-bill example beside the demo. We’ll compare how often relevant visitors start the demo before and after the change, and check with users whether the example answered their question.”
Change one main thing at a time where you can. If you rewrite the page, replace the demo, and change the audience all at once, a better result won’t tell you which change helped. If traffic is low, don’t call a small difference a win. Keep the test running until you see a consistent pattern, or treat the result as uncertain and ask users directly.
A useful rule of thumb is to review the funnel weekly while you’re learning, but make decisions from enough real interactions to avoid reacting to one unusual visit. There’s no universal number of visits that makes a test conclusive; it depends on how much traffic you get and how large a change you’re trying to detect.
Check that growth means people get lasting value
More clicks or signups can look like growth while people still fail to solve the problem. Follow up on what happens after the first result: do people return when another shared expense comes up, and can they explain the balance to the other household members? If they don’t return, ask whether the need was one-off, the result was unclear, or the product didn’t support the next step.
For a household tool, trust and clarity matter when the numbers appear. A person should be able to tell who paid, how the share was calculated, and who owes whom. If someone disputes the result, investigate the product rather than pushing harder for more signups.
Referrals may fit a product used by a group, but don’t assume they’ll happen just because several people share a household. First learn whether one person can explain the value clearly enough to get the others involved. Then test a specific way to help them do that, if your product supports it.
To cover everything that you think will change our app growth
At the end of each review, write down the step with the clearest problem, the evidence for it, and the smallest change that could address it. Keep a short list of other ideas, but don’t work on all of them together. A page change fits when people don’t understand the offer; a task change fits when they get stuck before seeing value; a return-use question matters when people complete the task but don’t come back.
For SplitNest, a useful first test is whether a household can understand a shared-bill result before entering its own numbers. The SplitNest household expense demo lets visitors enter household members, add a bill and its payer, and see equal-share balances update in their browser. The demo doesn’t save those entries, so use it to assess the first-use experience, not repeat use.
Common questions
Should I add features or focus on getting more users?
Find the first step where people who fit your target group get stuck. If they don’t understand the offer, improve the explanation before seeking more traffic. If they reach the offer but can’t complete the main task, fix that task first.
How long should I run a growth test?
Run it long enough to collect repeated observations from the kind of people you’re trying to reach. The right amount of time depends on your traffic and the change you’re testing. If the evidence stays thin, report that the result is unclear rather than calling it a win.
What should I measure before my app is fully launched?
Measure what people can actually do now, such as understanding the page, starting a demo, or joining an early-access list. Don’t claim to know retention or repeat use until people can use the product in a way that lets you observe those behaviors.
What to do first
Write down your target group, the problem they want solved, and the first useful result your app should give them. Then map the steps to that result and gather observations at the step where people stop. Make your first growth change address that specific problem.