Who Is the Target Audience for My Mobile App?

We worked on a social football platform built for grassroots players, and midway through the project the budget forced a decision. Scope had grown, the design kept changing, and we paused Android development so everything left could go into iOS. The app launched on iOS alone. The players it was built for were young and skewed heavily towards Android, so day one adoption came in at around half of what it should have been. The target audience for a mobile app had been described in the brief. It just hadn't been described in a way that reached the decisions that mattered.

Knowing who your users are only counts when it changes a build decision, like which platform ships first.

Nobody had written down which phones those players were holding. The brief said young, grassroots, five-a-side, and everybody nodded, because that sounds like an audience. It described a type of person and stopped there.

Defining a target market for mobile apps is work you do so later choices get easier. Which platform goes first, which features get cut, what the first screen says, who sits in the focus group, where the first thousand users come from. Every one of those answers runs back to who the product is for and what they're trying to get done. This article covers what that definition has to contain, how we build one, and what it's cost on projects where it stayed thin.

What a Target Audience Definition Actually Needs to Contain

A property developer came to us wanting a concierge app for a high-rise residential scheme. They arrived with a budget and a fixed picture of the product, and what they wanted from us was a validation of it. We talked them into running a proper discovery phase first, with focus groups and user workshops. The product that came out the other side was far simpler than the one they'd described. We dropped a lot of the planned features, put the money into making the app feel human, and they paid less than they'd budgeted.

That only happened because discovery changed who we understood the app to be for. A definition built from age, income and postcode can't tell you which features to cut. It can't tell you what the first notification should say either.

Defining the target audience for a mobile app

Five things, and each one has a thin version that reads perfectly well in a deck.

The right-hand column is harder to write and it's the only column that changes anything.

Starting From Use Cases, Not Demographics

Demographics describe a person. Use cases describe a moment, and the moment is what you're designing for. If we're building an app for managing the flat you live in, with concierge services attached, the first thing we do is list every situation that lands somebody in that building. A first place after leaving home. Somebody going through a divorce. Somebody who's finally been able to afford the home they always wanted. Three people, same age bracket, same income band, walking in with completely different feelings.

Those feelings decide what the app should do in the first week. The person who's just left home needs reassurance and a bit of hand-holding. The person coming out of a divorce needs the admin to disappear quietly. The person who's just reached something they worked years for wants the place to feel like an achievement. One onboarding flow cannot serve all three unless somebody has thought about all three first.

We test that list with focus groups and surveys rather than keeping it as a thought exercise. Some situations turn out to be rare. Others turn out to be the bulk of the market.

Write your use case list before your persona list. If a persona didn't come from a real situation, it's decoration.

Mobile audience targeting gets a lot easier once you have that list, because you can write ad copy for a moment instead of for an age range.

The Device and Platform Question

Back to the social football platform, because the detail matters. The client was bootstrapped and originally wanted both iOS and Android. Scope kept growing, with design changing constantly, driven by one of their own team with no account taken of what each change cost in build time. By the halfway point the budget was under real strain. We made the call to pause Android and move everything left into iOS, so they launched with the most complete iOS product we could get through, and roughly half the potential market unaddressed.

The half we reached was the smaller half. For a young grassroots sports audience the split leans Android, so the polished version went to the minority of the people it was made for.

Choosing a platform is choosing a slice of your audience, and the slice is rarely the one you pictured.

Devices set limits in other ways too. We worked on a product for African communities living abroad, meant to keep people connected to their home communities. The handsets in common use in African countries at that time were limited enough that delivering half of the intended experience on them would have been very hard. That isn't a design problem you solve with a better layout.

So the OS split, the handset age and the connection quality of your actual audience belong in the definition, before anyone scopes a feature.

Finding Your Audience's Real Behaviour, Not Their Stated Preferences

On the concierge app we had to decide when to send each notification to a new resident. The easy version is a fixed delay, two days after move-in for everyone. We ran focus groups and scenario research instead, and asked people what actually happens when you move house. Somebody who arrives in the morning tends to start unpacking that day. Somebody who arrives at seven in the evening won't touch a box until tomorrow. A single person unpacks slower than a household of three.

So we built dynamic timing. The app worked out when to send each message from the time the resident arrived at the property and how many people were moving in. That's a small thing with a direct line back to observed behaviour, and no survey question would have produced it.

People also agree to things they never do. Ask somebody whether they'd use an app and they'll usually say yes, because saying yes is pleasant and costs nothing. AppTweak puts positive responses at 60 to 80 per cent, against real usage that often lands at 10 to 20 per cent.

Ask about last time instead. What did you do, when, on what, and what went wrong.

Who to Recruit for Research Beyond Your Target Customers

On that same concierge project we ran focus groups with two very different sets of people. One was high-net-worth individuals, the target customers for the development. The other was people living in social housing, who were never going to buy a flat in that building.

We brought the second group in because they had the thing we were trying to build. Everybody knowing everybody, doors open, neighbours who notice when you're away. That quality is usually missing in high-rise developments where residents pass each other for years without a word, and the target customers couldn't describe it to us because they'd never had it.

What those sessions gave us was simple. A sense of community grows out of familiarity, and familiarity is just accumulated personal knowledge. Names, jobs, children, pets, what somebody does at the weekend. Everything came down to communication.

So we redesigned the product around that. We automated the mundane tasks to clear space for people to talk, added personalisation so residents could see their neighbours' interests and something of the concierge's personality, and built a social space into the app. It worked really well.

If there's a quality you want your product to carry, find the people who already live it, whether or not they'll ever pay you.

Weighting Feedback When Not Every Participant Counts Equally

Research debriefs often treat every response as one vote. We want to understand the user profiles of the people who answered so we can weight their feedback accordingly, because relevance shifts feature by feature.

On the concierge app that was unavoidable. The social housing group carried real weight on anything to do with community, belonging and how neighbours get to know each other. On questions about resident services and building admin, the people who'd actually live in that development carried the weight, because they were the ones who'd use it every week. Same study, two different weightings, depending on the question.

Reviewing who answered is a deliberate step, and it happens before anyone writes a conclusion.

1. List everyone who took part, with their background and their real behaviour.
2. Mark each person against the use cases you mapped earlier.
3. Decide, feature by feature, whose answer counts most and why.
4. Re-read the findings with those weights applied.
5. Write down who you downweighted, so the decision can be challenged later.

Skipping that step is how a loud minority ends up shaping a roadmap. It's also how a quiet, perfectly representative group gets averaged into silence.

Positioning: Where Your App Sits Against the Alternatives

App positioning starts with what people do today without you. The developer behind the concierge app wanted it to replace a stack of things the building already ran, the desk, the intercoms, the notices, the existing resident systems. Discovery said leave them alone. Those systems worked, residents knew them, and rebuilding them in an app added cost without adding anything a resident would notice.

So we pointed the product at the human connection instead, which is what nothing else in the building was doing.

Your real competition is often the system already in the building, or people carrying on as they are.

The other alternative is doing nothing, and it wins more often than founders expect. AppTweak notes that new apps typically take 0.1 to 1 per cent of their addressable market in the first year, while founders building top-down forecasts tend to assume 5 to 10 per cent.

App positioning against doing nothing

A useful test is to write one sentence a real user would say. For whom, in what moment, instead of what, and better how. If the "instead of what" is blank, you haven't found your position yet.

Matching the Brand Promise to the Product Experience

We worked on a mobile app in the health and wellness genetics sector where the brand and the product were pulling in opposite directions. The packaging and the online presence were luxurious and aspirational, all about becoming a better version of yourself and reaching your full potential. Beautiful stuff, and it set a clear expectation.

The app they'd already built was cold and clinical. The copy was purely functional, the design was purely functional, and nothing in it carried any of the feeling the brand had spent money creating.

Follow the journey a customer actually takes. They see the aspirational marketing, they order a kit, they spit in a tube, they post it off, they wait, and then they open the app to find out what it says about them. That last step is the emotional peak of the whole thing, and it landed like a lab report. A very jarring experience, and the journey broke down entirely at the product touchpoint.

Your audience definition includes the emotional state people arrive in, and marketing is what puts them in it. If the app ignores that state, the brand has effectively mis-sold the product.

Put your packaging, your ads and your first app screen next to each other on one wall. If a stranger can't tell they're from the same company, neither can your customer.

When the Research Says Nobody Wants It

The product for African communities living abroad was meant to help people keep a connection with their home communities. Technically it was viable and fairly straightforward, which is often the point at which a team stops asking questions and starts building.

We ran a lot of focus groups with the target market first. The answer that came back was that there simply wasn't enough desire for that kind of product. People understood it, they were polite about it, and they weren't going to use it.

Alongside that sat the device problem. The handsets in common use in African countries at the time were limited enough that delivering half of the intended experience would have been extremely challenging, so even the people who did want it would have met a cut-down version.

Commercially unvalidated and technically constrained at the same time. The project stopped there, which was the correct outcome and a far cheaper one than finding out after launch.

Research that kills an idea has done its job. The uncomfortable part is that it usually arrives when a team has already fallen in love with the thing, which brings us to the next chapter.

Founder Conviction Versus the Evidence

Two projects, a fitness and wellness app and a grassroots football product, ran into the same pattern. In both, the founder was certain about what they wanted, usually because the product solved a problem they personally had. Research came back, focus groups came back, surveys came back, and the findings were set aside in favour of the original vision.

What you get is a vanity product, shaped by one person's preferences rather than by evidence from the people meant to use it.

There are warning signs, and they show up early.

• A drive to perfect the product before launch that never quite finishes.
• Sign-offs rolled back so another round of changes can go in.
• Decisions that take weeks when they should take days.

We flagged the trajectory on both projects while there was still time to change course. Both spent their entire budget in design and build, and neither ever reached a full live version of the product.

Agree before research starts which findings would make you change the plan. Writing it down in advance makes it much harder to explain away later.

Designing Acquisition Around Who Your Users Already Know

We worked on a travel OTA aimed at people in their early twenties to mid thirties, built around group bookings. After launch we tried most of the standard acquisition tactics. Referral codes with a discount attached, push notifications to pull lapsed users back, social sharing of trips, email campaigns through Mailchimp. All of it did a little. None of it moved the numbers much.

What moved the numbers was inside the booking flow. When somebody organised a group trip, the app prompted them to get every traveller in that group to download it, so the group could talk in one place and each person could submit their own passport details. One person booking a trip for ten gave us nine new users straight away, and any of those nine could then organise their own trip and bring in their own group.

Acquisition worked best where the product needed other people, so inviting them was part of using it.

That only works because the audience definition included who these people travel with. A group of friends booking a villa is a different unit from a single traveller, and the product was designed around the group.

Ask who your user has to involve to get the job done, then make involving them the easiest step in the flow.

What It Costs to Get This Wrong

The social football platform shows the bill arriving after launch. With only iOS live, the user base was too small to make the subscription model work, so the client cancelled it. Advertising went in, a feature they'd specifically said they wouldn't build, and the product carried that financial strain from then on. A platform decision made under budget pressure in month four reshaped the business model in month twelve.

The fitness and wellness app and the grassroots football product show the other version. Money went into design and build, round after round, and neither reached a full live product. Nothing shipped, so nothing could be learned from real users, so the spend produced no evidence at all.

Both outcomes trace back to the same thing, which is a definition of the audience that nobody tested hard enough or early enough. Business of Apps puts 42 per cent of app failures down to launching without prior market research.

Discovery costs a fraction of a build. Rebuilding for a platform you skipped, or rewriting an app whose tone contradicts the brand, costs far more than running focus groups would have.

Conclusion

The target audience for a mobile app is a working document, and it should be specific enough that two people reading it make the same decision about a feature. Who they are, the situation that brought them to you, what they do today instead, the phone in their hand, and the feeling they arrive with. Everything downstream gets easier once those five are settled, and everything downstream gets expensive when they aren't.

The projects in this article split fairly cleanly. Where we did the research first, the product came out simpler, cheaper and warmer than planned. Where the research was skipped, or run and then ignored, the money went into design and build and the market answered afterwards, which is always the most costly moment to hear it.

You don't need a vast study to start. A list of real use cases, a few focus groups with people who actually live the situation, including some who'll never be customers, and an honest look at which devices your audience holds will tell you more than another month of internal debate.

If you're defining a target market for mobile apps and you'd like a second set of eyes on it, let's talk about who your app is really for.

Frequently Asked Questions