--- title: What Problem Does My App Solve for Users? description: Learn how to define the problem your app solves before you build anything, covering user frustrations, problem statements and testing ideas early. image: https://weareaffective.com/hubfs/learning-centre-images/what-problem-does-my-app-solve-for-users.webp --- [Skip to content](https://weareaffective.com/learning-centre/what-problem-does-my-app-solve-for-users#main-content) [![we\_are\_affective\_logo\_200](https://weareaffective.com/hs-fs/hubfs/we_are_affective_logo_200.png?width=175&height=48&name=we_are_affective_logo_200.png "we_are_affective_logo_200")](https://weareaffective.com) - [Home](https://weareaffective.com) - About Us - [Our Story](https://weareaffective.com/about) - [How We Work](https://weareaffective.com/how-we-work) - Our Services - [App Planning & Strategy](https://weareaffective.com/app-planning-strategy) - [App Design](https://weareaffective.com/app-design-agency) - [App UX Design](https://weareaffective.com/app-ux-design) - [App UI Design](https://weareaffective.com/app-ui-design) - [App Technical Architecture](https://weareaffective.com/app-architecture) - [Existing App Audits](https://weareaffective.com/app-audit) - [Case Studies](https://weareaffective.com/case-studies) - [Pricing](https://weareaffective.com/pricing) - [Learning Centre](https://weareaffective.com/learning-centre) - [Get Started](https://weareaffective.com/get-started) Expert Guide Series # What Problem Does My App Solve for Users? Table of Contents A pre-launch founder in the football industry came to us with a colour-coded spreadsheet. Every competitor product in his market was mapped out on it, tab by tab, with a plan to merge the best parts of all of them into one app. He was excited, and fairly pleased with himself, and he wanted a build estimate. We started asking about the people who'd use it instead, because the first thing we want to understand is the problem your app solves and who's currently stuck with it. > A product idea is an answer, and nobody checks the answer until someone asks the question out loud and it doesn't quite land. That question sounds simple. It's the hardest one most founders get asked, and the answers tend to arrive as features rather than problems. A lot of clients come to us with a product they want to build when in reality they're solving a problem. Even when someone arrives with a fully formed idea, we [take it a step back and look at what problem](https://weareaffective.com/app-user-research) that product is meant to solve, then work forward from there. This article is about how we do that. It covers how to tell a feature from a problem, how to study what people already do without you, how to find the moment where their current way of coping breaks, and how to write the whole thing down in a few honest sentences before anyone opens a design file. ## Features Are Not Problems When a brief lands, it usually arrives as a list. Push notifications, a dashboard, a chat function, a points system, a camera that scans something. Every item on that list is a decision about how to solve a problem, written before the problem was agreed. We saw this clearly on [a concierge app for a high-rise property development](https://weareaffective.com/learning-centre/what-a-concierge-app-for-new-homeowners-taught-us-about-timing). The developer had a long feature list, and after focus groups and user workshops we dropped most of it. The product ended up far simpler than they'd pictured, because the features were answering a problem nobody had. That matters financially. Nearly 60% of app features are rarely or never used, according to [Futuristic Bug](https://www.futuristicbug.com/mobile-app-features-for-startups), which means a lot of budget goes into things that sit untouched. #### Saying it the other way round Try writing each feature as the problem it's meant to fix. The difference shows up immediately. | Said as a feature | Said as a problem | How you'd check | | --- | --- | --- | | Loyalty wallet | People lose paper stamp cards and stop coming in | Ask staff how many cards get reissued | | Skin scanner | Shoppers can't tell which serum suits them | Watch ten people choose in store | | Pet health dashboard | Owners forget worming dates and feel guilty | Ask owners what they use now | ## How People Cope Without Your App Today Nobody is waiting for your product. Whatever the problem your app solves, people are already handling it somehow, with a notes app, a group chat, a spreadsheet, a phone call to someone who knows, or by putting up with it. We're always taking a step back and thinking about what need the product is going to fill, and then how people feel about the way they meet that need now. There's [no point building a technical solution](https://weareaffective.com/learning-centre/how-to-tell-whether-your-digital-problem-is-a-format-problem-or-a-brief-problem) for something people are quite happy doing manually. Contentment is the signal that kills more ideas than cost does. On the accident reporting app we worked on for BMW, the coping method was paper and typing. If you'd been in a crash, you filled in forms and typed up witness statements, at the roadside, shaken, with other people waiting on you. Nobody was content with that. The frustration was obvious the moment we described it back to them, which is how we knew there was a real product in it. Ask what people did the last time this problem came up. Specific memory beats general opinion, because people describe what they imagine they'd do rather than what they actually did. If the honest answer is that the current method is fine, the product has a hill to climb that no amount of design will flatten. ## Design that understands *your* users We build app experiences around real user behaviour, not assumptions. Research, psychology-driven design and technical specs that turn users into loyal advocates. [See how we work](https://weareaffective.com/how-we-work) [Get started](https://weareaffective.com/get-started) No commitment ## Everyday Frustrations That Make Good App Ideas The ideas that hold up tend to come from small, repeated irritations rather than big visions. We worked on a travel product used by people taking exotic trips and backpacking in remote wilderness. The frustration was simple. Out in rural places there's no internet connection, and an app that opens with a "you're not connected" message and nothing else is a disaster when you're relying on it for maps, saved pins, tickets and itineraries. We retrofitted offline capability so the useful parts worked with no signal at all. > The best ideas start as a small, repeated annoyance, not as a market worth billions. Another one came from how much people hate filling things in. We built a communications platform where recorded conversations replaced forms and surveys. People were asked questions, almost like a reporter would, and answered out loud. Speaking carries thought far more easily than typing, and it holds the nuance that a text box strips out. Daily problems worth looking at tend to share a shape. - Something people do often and dread slightly - Something they currently manage with a workaround - Something that fails at the worst possible moment - Something they ask another human to do for them ## The Problem Behind the Problem The stated problem is usually a symptom. On the concierge app, the developer thought the problem was workload, so the plan was to digitise everything the concierge did. Our focus groups said otherwise. The real issue in the building was communication, with residents simply not knowing each other or talking to each other. That changed the product strategy completely. We stopped trying to move the concierge's whole job into an app. Instead we automated the mundane, routine tasks, which freed up time and energy for the concierge and residents to actually speak. We added personalisation so residents could see who their neighbours were, what they were into, and get to know the concierge as a person rather than a desk. The focus groups also told us where belonging comes from. A sense of community grows out of familiarity, from people accumulating small personal facts about each other, names, jobs, kids, dogs, what they do at weekends. Surfacing chances for those disclosures creates the feeling. Automating the interactions away removes it. When a client describes a problem, ask why it matters three times. The first answer is the symptom, the third is usually the thing worth designing for. ## Finding the Moment Where Things Break Down Problems aren't spread evenly across a product. There's normally one moment where everything falls over, and finding it tells you what to build. On a [map-based fitness social network we worked on](https://weareaffective.com/learning-centre/what-a-fitness-social-app-changed-when-it-realised-precise-location-was-the-wron), which connected people for runs and cycle rides, a lot of people were dropping off at the point where they shared their location. The reason was timing. We were [asking for a high-trust action before they'd had a chance](https://weareaffective.com/learning-centre/what-a-fitness-social-app-changed-when-it-realised-precise-location-was-the-wron) to have a conversation or learn anything about the other person. The feature wasn't wrong, the moment was. #### Designing around the worst moment The BMW work had a harder version of this. The breakdown moment was the accident itself, when nobody is in a state to hunt through menus for a reporting button. We looked at the accelerometer. If the device had been moving and then stopped suddenly, we'd ask first, "have you been in an accident?" That unburdens people of the process at the point they can least handle it. We carried that through the rest of the flow. Voice memos for witness statements, transcribed automatically with the original recording kept so the human nuance in the language survived, and visual diagrams showing exactly which photo angles to take. A step-by-step visual process rather than a memory test during trauma. ## When the Problem Is a Feeling, Not a Task Some problems have no task attached at all. We worked on a financial application where everything about the product was functional and financial, with a great deal of information on screen. The thing people rarely account for is how much anxiety sits around money, depending on the type of account someone has, whether they're saving for something, or what they're about to spend. We used education as the main answer. Framing things properly, making sure people understood what they were looking at, what they were about to see next, and where they were inside the product. None of that is a feature in the usual sense. It moved the product from a purely functional experience to a far more emotional one, and the anxiety came down. The concierge app had the same quality. Residents weren't asking for a task to be completed. They wanted to feel like they lived somewhere, with people they half knew. If users describe your problem area with feeling words, worried, embarrassed, guilty, lost, design for the emotional state first and the task second. Feelings are harder to write in a brief than tasks, and they're often the whole reason someone opens the app. ## Discovery Before Budget The property developer behind the concierge app came to us with a budget already set and a clear picture of what they wanted. What they were really after was a validation of that picture rather than a proper scoping exercise. We talked them into discovery first, with focus groups and user workshops. What we found was that the product was going to be a lot simpler than they'd imagined. [Many planned features never made it in](https://weareaffective.com/learning-centre/why-your-best-feature-idea-might-be-your-worst-business-decision). We focused instead on creating a human connection with the product rather than replacing a pile of systems the building already had. Better product, lower cost, and the discovery paid for itself inside the build. > Setting the budget before the problem is agreed means buying the answer before anyone has checked the question. Spending ahead of understanding is one of the more reliable ways to run out of road. Around 74% of high-growth internet startups fail through premature scaling, hiring hard, expanding infrastructure or buying marketing before product-market fit, per [cisin.com](https://www.cisin.com/coffee-break/reasons-for-mobile-app-startup-failure.html), though that figure comes with no named methodology behind it. Our view is simpler. Discovery costs a fraction of a build, and it regularly removes more from the build than it costs. ## Testing the Problem Before You Build the Product You can test a problem without a single screen. Describe the situation to ten people who match your audience and watch whether they recognise it or politely agree with it. Recognition sounds different. People interrupt you, finish the sentence, and tell you their own version. The voice-recording platform we built came out of exactly that kind of observation. People would skip a written survey and talk happily for four minutes if you asked them a question out loud. We didn't need a prototype to know typing was the barrier. #### A sensible order of work 1. Write the problem in one plain sentence 2. Find ten people who should have it 3. Ask what they did last time it came up 4. Ask how they felt about that 5. Build the smallest thing that fixes the worst moment 6. Watch where they stop using it Around 35% of startups fail through not finding product-market fit, having gone without an MVP, according to [Harvard Business School Online](https://online.hbs.edu/blog/post/how-to-find-product-market-fit). The smallest thing you can put in front of someone is worth more than the most detailed plan. ## When Honest Answers Kill the Idea Back to the football founder and his spreadsheet. We asked why somebody would pick an all-in-one product over the specialised apps they already used, and whether merging everything risked dumbing down the individual features that made those apps worth having. He didn't have answers, and he was visibly deflated by the end of the conversation. That was the right conversation to have. It's our job to be very honest about a product and what's going to make it succeed, because [building on vanity metrics alone serves nobody](https://weareaffective.com/learning-centre/why-your-best-feature-idea-might-be-your-worst-business-decision), least of all the person paying for it. We've also turned work away. One potential client knew what they wanted built but couldn't say why or what problem it addressed, and they didn't know enough yet to make good use of us. We suggested they go and look at other products, work out what fits their target customer, and come back when the idea had more shape. Then we can help with the why. The question Simon puts to founders deciding whether to carry on is this one. Are you solving a real problem people will pay for, or are you yourself in love with the solution? It filters the market-ready products from the vanity ones quickly. ## Writing Your Problem Statement Once you've done the asking, write it down in a form someone else can argue with. A good statement is boring, specific and checkable, and it names a person rather than a market. #### Stating the problem your app solves Five parts cover it. Who has the problem, what they do about it now, where that breaks down, how they feel at that moment, and what changes if you fix it. Keep it to a few sentences. Ours for the travel product read roughly as follows. People backpacking in remote places rely on saved maps, tickets and itineraries, they lose connection for days at a time, the app becomes a blank error screen at the exact point they need it, they feel stranded, and offline access turns the app back into something they trust in the field. Read your problem statement to someone in your target audience without mentioning the app. If they shrug, keep looking. If you're sat with a blank page asking what problem does my app solve, start from the last time you watched someone struggle with it, and write what you saw rather than what you hope is true. ## Conclusion Every piece of work in this article followed the same route. We asked what need the product was filling, how people met that need already, and how they felt about doing it that way. The concierge app got smaller and warmer. The BMW accident flow started asking the question before the user had to. The travel app worked with no signal. The financial product taught instead of simply reporting. The fitness network moved its trust request to a later point in the conversation. None of that came from a feature list. It came from spending time on the problem first, which is slower at the start and faster everywhere afterwards. If you're holding an idea and the problem behind it still feels fuzzy, that's a good place to be, as long as you don't skip past it. Write the problem down, test it on ten people, and let their answers change the plan. The product gets simpler, and the budget tends to go further. If you'd like a second opinion on what your idea is really solving, [let's talk about the problem your app solves](https://weareaffective.com/get-started). ## Frequently Asked Questions What is the difference between a feature and a problem? A feature is a decision about how to solve something, like a loyalty wallet or a dashboard. A problem is the thing people are struggling with, such as losing paper stamp cards and drifting away from a shop. If you write each feature as the problem it is meant to fix, you quickly see which ideas have no real need behind them. I already have a fully formed app idea. Do I still need to go back to the problem? Yes, and it usually saves money rather than costing it. Even with a complete idea, taking a step back to agree what problem the product solves lets you work forward with confidence instead of building features that answer a question nobody asked. Why does it matter that nearly 60% of app features are rarely used? Because every unused feature was paid for, designed, built and tested with budget that could have gone elsewhere. Starting from the problem rather than a feature list is the most reliable way to keep that waste down. How do I find out what my users currently do instead of using my app? Ask them, and watch them. People are already coping somehow, with a notes app, a group chat, a spreadsheet or a phone call to someone who knows, and those workarounds tell you exactly where the real friction sits. What if people seem perfectly happy with their current method? That is a genuine warning sign, and contentment kills more ideas than cost does. There is little point building a technical solution for something people are quite happy doing manually, so it is better to find that out before you commit to a build. How do I spot the moment a workaround actually breaks down? Look for the point where the current method stops coping, for example when someone has to retype information, chase a person for an answer or apologise for a mistake. That breaking point is usually where your product earns its place, and it is far more useful than a general sense that something could be better. Should I map out my competitors before anything else? Competitor research is useful context, but merging the best parts of several products is not a strategy. A better starting point is understanding the people who will use your app and what they are currently stuck with, then deciding what your product needs to do differently. What should I have written down before design work starts? A few honest sentences describing the problem, who has it, how they cope today and where that coping fails. If you cannot write that clearly, it is a sign the research is not finished, and opening a design file will only hide the gap. ## Related Articles [![How to Tell Whether Your Digital Problem Is a Format Problem or a Brief Problem](https://weareaffective.com/hubfs/learning-centre-images/how-to-tell-whether-your-digital-problem-is-a-format-problem-or-a-brief-problem.webp)](https://weareaffective.com/learning-centre/how-to-tell-whether-your-digital-problem-is-a-format-problem-or-a-brief-problem) ### [How to Tell Whether Your Digital Problem Is a Format Problem or a Brief Problem](https://weareaffective.com/learning-centre/how-to-tell-whether-your-digital-problem-is-a-format-problem-or-a-brief-problem) A client came to us after spending three months briefing, revising, and re-briefing a digital... by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee) [![How to Write a One-Page Behavioural Thesis Before You Commit to a Format](https://weareaffective.com/hubfs/learning-centre-images/how-to-write-a-one-page-behavioural-thesis-before-you-commit-to-a-format.webp)](https://weareaffective.com/learning-centre/how-to-write-a-one-page-behavioural-thesis-before-you-commit-to-a-format) ### [How to Write a One-Page Behavioural Thesis Before You Commit to a Format](https://weareaffective.com/learning-centre/how-to-write-a-one-page-behavioural-thesis-before-you-commit-to-a-format) A team spends three weeks debating whether to build a native app or a progressive web app. Another... by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee) [![What's the Difference Between Voice Commands and Voice Assistants?](https://weareaffective.com/hubfs/learning-centre-images/whats-the-difference-between-voice-commands-and-voice-assistants.webp)](https://weareaffective.com/learning-centre/whats-the-difference-between-voice-commands-and-voice-assistants) ### [What's the Difference Between Voice Commands and Voice Assistants?](https://weareaffective.com/learning-centre/whats-the-difference-between-voice-commands-and-voice-assistants) Ask a phone to set a timer for ten minutes and it sets a timer. Ask it why your order hasn't turned... by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee) [![We Are Affective](https://weareaffective.com/hubfs/we_are_affective_logo_mark.svg)](https://weareaffective.com) 20-22 Wenlock Road London, N1 7GU United Kingdom +44 20 4572 8062 [hello@weareaffective.com](mailto:hello@weareaffective.com) Services [App planning & strategy](https://weareaffective.com/app-planning-strategy) [App design](https://weareaffective.com/app-design-agency) [App UX design](https://weareaffective.com/app-ux-design) [App UI design](https://weareaffective.com/app-ui-design) [App technical architecture](https://weareaffective.com/app-architecture) [Existing app audits](https://weareaffective.com/app-audit) Legal [Privacy policy](https://app.termly.io/policy-viewer/policy.html?policyUUID=b8fa9921-7518-4fb5-8ddd-9dc7f5977ed2) [Terms](https://app.termly.io/policy-viewer/policy.html?policyUUID=8b6a6ad5-91bd-4176-a5f7-6d36b0398f70) Case studies [TravAI](https://weareaffective.com/case-studies/travai) [Meditech](https://weareaffective.com/case-studies/harley) [WorkingWeight](https://weareaffective.com/case-studies/workingweight) [SkinSync](https://weareaffective.com/case-studies/skinsync) [Three Lochs](https://weareaffective.com/case-studies/three-lochs) [Drift](https://weareaffective.com/case-studies/drift) About us [Our Story](https://weareaffective.com/about) [How We Work](https://weareaffective.com/how-we-work) Guides [Creating an app](https://weareaffective.com/how-to-create-an-app) [Building an MVP](https://weareaffective.com/building-an-mvp) [Cost and budgeting](https://weareaffective.com/app-development-cost) [App technology](https://weareaffective.com/app-development) [Planning and strategy](https://weareaffective.com/app-planning-strategy) [User research](https://weareaffective.com/app-user-research) [Onboarding design](https://weareaffective.com/app-onboarding-design) [User psychology](https://weareaffective.com/user-psychology-app-design) [Launch and growth](https://weareaffective.com/app-launch-growth) Copyright © 2026, weareaffective.com. All rights reserved.