--- title: What data sources strengthen app feasibility research description: Discover which data sources truly strengthen app feasibility research, from platform signals to qualitative findings that shape better product decisions. image: https://weareaffective.com/hubfs/learning-centre-images/what-data-sources-strengthen-app-feasibility-research.webp --- [Skip to content](https://weareaffective.com/learning-centre/what-data-sources-strengthen-app-feasibility-research#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 data sources strengthen app feasibility research Table of Contents A founder walks into the room with a colour-coded spreadsheet. Every competitor product is mapped across a grid, with features ticked and gaps circled in red. They have spent weeks on it. The energy in the room is high. And then we start asking questions about the people who will actually use this product, and the spreadsheet, however detailed, cannot answer a single one of them. > The spreadsheet maps the competitive landscape, but says nothing about the people who will actually use it. This is the most common starting point we see in app feasibility research. The competitive landscape has been documented. The market opportunity has been noted. But the data that would tell a founder [whether real users, on real devices](https://weareaffective.com/app-user-research), in real situations, will actually choose and keep using this product, that part is thin or missing entirely. Feasibility research is not just about whether an app can be built, or whether a market exists in aggregate. It is about whether the specific product, for the specific audience, on the platforms they actually use, in the contexts they live in, has a real chance of surviving contact with real users. Getting that right means knowing which data sources to trust, which to interrogate, and which to put down. ## Why the Wrong Data Sources Create False Confidence The problem with relying on the wrong data is not that you end up with no information. The problem is that you end up with information that feels solid, and you build decisions on top of it. A market sizing report tells you the global opportunity is large. An app store ranking tells you competitors are getting downloads. A friends-and-family survey tells you people love the idea. None of these tell you whether a real stranger, with no prior investment in the product, will open the app, understand it within sixty seconds, and come back the next day. According to [AppTweak](https://www.apptweak.com/en/aso-blog/app-market-research), when users are asked whether they would use an app, 60 to 80 percent typically say yes. Actual usage settles at 10 to 20 percent. That gap is the distance between stated intent and real behaviour, and most feasibility research lives entirely on the stated-intent side of it. We have seen this play out directly. On two separate projects, a fitness and wellness app and a grassroots football platform, founders held strong personal conviction about their products. Each had done research of a kind. But when findings from focus groups and surveys pointed in a different direction than the founder expected, the data was set aside rather than acted on. In both cases, budget ran out in the design and build phase. Neither product reached a fully live state. What they had was not bad data. What they had was data that confirmed what they already believed, and a gap where the uncomfortable signals should have been. ## Competitor Analysis as a Starting Point, Not a Conclusion Competitor analysis is the natural first step, and founders who have done it properly arrive with genuine knowledge of the space. The football industry founder who came to us with that colour-coded spreadsheet understood the competitive landscape in real detail. The intention was to merge several existing products into one. The spreadsheet showed the features. What it could not show was [whether users actually wanted consolidation](https://weareaffective.com/learning-centre/how-to-pressure-test-a-product-concept-with-people-who-arent-your-target-users-y), or whether combining functions would water each one down to the point of being less useful than the specialist tools it replaced. When we started asking those questions, the energy in the room changed. The founder became deflated. That is not a comfortable moment, but it is a necessary one. The job of feasibility research is to be honest about what will make a product succeed. A spreadsheet of competitor features answers the question of what exists. It does not answer the question of why a user would switch, or what they would give up to do so. Treat competitor analysis as your map of the territory, not your evidence that the territory is worth entering. Use it to frame your research questions, then go and ask real users those questions directly. There is substantial evidence that [feature parity does not drive adoption](https://weareaffective.com/learning-centre/how-to-spot-a-product-vision-that-wont-survive-first-contact-with-users). Having the same capabilities as a competitor, or even better ones, does not guarantee that users will choose your product. What determines choice is how users feel, what their specific use case is, and whether your product fits the context of their life. None of that is visible in a competitor feature matrix. ## 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 ## Platform and Device Data for Your Actual Audience One of the clearest examples of what happens when platform data is ignored comes from the social football platform we worked on. The decision was made to launch iOS first, which is a common and often defensible choice. The problem was that the target audience was younger, and that demographic skewed disproportionately towards Android. Launching on iOS first meant building the more polished version of the product for the smaller portion of the intended market. The practical consequence was that day-one adoption rates were roughly half what they could have been. And because the user base was too small to sustain a subscription model, the client had to introduce advertising, a feature they had specifically said they would not include. The subscription model was abandoned. The financial pressure that followed had a lasting effect on the product's ability to grow. That outcome was not inevitable. It followed directly from a platform decision made without sufficient demographic data about the actual user base. > Platform decisions made without demographic data about your actual users can cut day-one adoption in half. Platform data worth gathering includes device distribution within your target demographic, operating system split by age group and geography, screen size norms for your audience, and how your category performs across Android and iOS in your specific market. These are not abstract technical questions. They determine who can access your product on the day it launches. Before committing to a single-platform launch, map your target demographic against device ownership data for your category and region. The savings on build cost may be smaller than the cost of a reduced addressable audience on day one. ## Demographic and Behavioural Research That Reflects Real Users Demographic research at the feasibility stage is often treated as background context, something to note and move past. In practice, it is one of the most decision-shaping inputs in the process, provided the demographics you are researching reflect users who will actually engage with the product rather than users you hope to attract. On the fitness social app we worked on, the initial product concept centred on map-based location sharing, allowing users to see where nearby people were working out and arrange to join them. The demographic research revealed that a high proportion of the expected user base would be female. That single finding fundamentally changed the product. [Precise real-time location sharing became a significant safety concern](https://weareaffective.com/learning-centre/what-a-fitness-social-app-changed-when-it-realised-precise-location-was-the-wron), not a minor caveat. The team redesigned the feature entirely. Rather than showing exact locations, the redesigned version introduced randomised location offsets. Users could see the general area where a potential workout partner was located, close enough to judge whether a meetup was practical, but not precise enough to identify where someone was. They could then review each other's profiles and converse before choosing whether to share their exact location. The core value of the feature remained. The safety risk was removed. That redesign only happened because the demographic data was taken seriously early enough to act on it. Behavioural research adds another layer that demographic data alone cannot provide. Knowing who your users are tells you about their context and constraints. Knowing how they behave tells you what they actually do, as opposed to what they say they will do. ## Security, Safety, and Contextual Signals Competitors Won't Surface Competitor analysis will not surface safety and security concerns. No app store listing explains why a competitor made a specific design decision, or what user research led them there. The fitness app location redesign is a clear example: there is no way to look at a competitor's privacy settings and understand the demographic insight that drove them. You have to do your own research to surface those signals. Security and safety concerns are contextual. They depend on who your users are, where they use the product, and [what they are doing when they use it](https://weareaffective.com/learning-centre/what-makes-users-trust-a-product-enough-to-enter-their-card-details). A feature that works safely for one demographic may create real risk for another. A location-sharing tool, a community forum, a direct messaging function, and a profile-display system all carry different risk profiles depending on who is in the room. And you do not know who is in the room until you have done the demographic and behavioural research. Support request data is one of the more underused sources for surfacing these signals. When users encounter something that does not feel right, or something that makes them uncomfortable, they often reach out. Patterns in support requests, common themes in what users ask about or complain about, can point directly to specific friction points or concerns within the product. This is especially true post-launch, but at the feasibility stage it is worth examining competitor reviews and public forum discussions to look for the themes that competitor users raise about safety, trust, and comfort. Review your target competitors' one and two-star ratings before you finalise your product spec. The patterns in those reviews often surface the safety, trust, and usability concerns your own feasibility research should be addressing. ## When Founder Conviction Overrides Research Findings The two projects where budget ran out without a live product, the fitness and wellness app and the grassroots football platform, shared a recognisable pattern. In both cases, the founder had strong personal conviction about the product, often because the problem they were solving was a problem they personally experienced. That conviction is genuinely valuable at the start. It is what gets a project moving. The difficulty arises when the conviction becomes a filter that the research findings cannot get through. Early warning signs include an excessive drive to perfect the product before launch, returning to previously signed-off decisions to request further changes, and extended periods of decision-making that do not resolve. The product starts to be shaped by the founder's preferences rather than by user evidence. We have a name for the destination that process reaches: a vanity product. Built with care, built with cost, but built for the founder rather than the user. We flag this trajectory when we see it. On both projects, we raised concerns. Flagging it does not always change the outcome, because [conviction is not easily argued out of](https://weareaffective.com/learning-centre/why-your-best-users-are-often-your-worst-source-of-product-direction). According to [Nielsen Norman Group](https://www.nngroup.com/), in lower-maturity organisations such as startups and smaller companies, fewer than 20 percent of research findings result in a documented product change. The research gets done. The findings come back. And then, more often than not, the product continues largely unchanged. The data sources are not the problem in those cases. The relationship between the founder and the data is the problem. ## Quantitative vs Qualitative Sources and When to Use Each Qualitative and quantitative research answer different questions, and feasibility research needs both. The mistake is treating one as a superior version of the other, or using scale as a proxy for insight. | Source type | Best for | Limitations | | --- | --- | --- | | Qualitative (interviews, focus groups) | Understanding why users behave as they do, surfacing unexpected concerns, exploring emotional responses | Small sample, not statistically representative, harder to generalise | | Quantitative (surveys, analytics) | Confirming whether a pattern holds across a larger group, validating directional findings at scale | Cannot explain motivation or context, relies on question design | | Behavioural data | Revealing what users actually do rather than what they report | Requires an existing product or prototype, needs correct interpretation | | Self-reported data (NPS, surveys) | Capturing conscious, stated perceptions of the product | Does not reflect subconscious or in-context behaviour | Self-reported data gives you the conscious, stated view. Behavioural data gives you the revealed, in-context view. Neither replaces the other. Together they give you a complete picture of how a product is actually perceived. A product with strong NPS scores and declining session times needs both data sets to understand what is happening. One without the other leaves the picture incomplete. When stakeholders raise concerns about sample size in qualitative research, the move is to accept that any number of real participants adds value over none, and then, if the findings point to significant changes, to [validate those specific points through predefined surveys](https://weareaffective.com/learning-centre/how-to-run-a-concept-test-that-doesnt-just-confirm-what-the-team-already-believe) that can reach far more respondents than one-to-one sessions allow. ## How to Distinguish Signal from Noise Across Data Sources Not all findings carry equal weight, and treating them as though they do produces research that is technically thorough but practically useless. The first filter is the source itself: is the finding coming from a subjective feeling in the room, from concrete analytics, or from user research? Each carries different risks of bias and requires different handling. Stakeholder opinion needs to be checked for insider bias, because those who know a product deeply often find flows intuitive that new users find confusing. The second filter is who provided the finding. Not every participant in a research session carries equal weight. Before drawing conclusions, it is worth reviewing who answered, their background, their behaviour, and how well they fit the target demographic. Feedback should be weighted according to the user profiles of those who participated, because relevance varies on a per-feature basis. A finding that comes entirely from participants who are not representative of the target audience is weaker than one that comes from users who match it closely. The third filter is whether the finding recurs. A single data point in one session is a prompt to look further. The same finding across qualitative sessions, confirmed by a quantitative survey, and corroborated by support request patterns, is a signal worth acting on. Noise tends not to survive contact with multiple sources. Signal tends to show up repeatedly, across different methods, from different angles. 1. Identify the source: feeling, analytics, or user research. 2. Check who the finding came from and how representative they are. 3. Look for the same signal across multiple data sources before treating it as actionable. ## The Research Findings That Must Actually Change the Product A 2022 survey by [UserZoom and Ipsos](https://www.thegrowthsyndicate.com/resources/competitor-analysis-framework) found that approximately 72 percent of product decisions were made without user research informing them. That is a figure about the scale of decision-making that happens with no user data involved at all. And in the cases where research is done, the Nielsen Norman Group data suggests fewer than 20 percent of findings in lower-maturity organisations result in a documented product change. This is the gap that determines whether feasibility research is worth doing. The data sources matter. The methodology matters. But the test of whether feasibility research served its purpose is whether the product that gets built is different from the product that would have been built without it. There are five findings that, if they emerge from feasibility research, must change the product. First, evidence that the user need is not validated beyond the founder's own experience. Second, [evidence that the onboarding flow is not understood](https://weareaffective.com/learning-centre/what-a-development-team-actually-needs-to-know-about-the-user-before-sprint-one) by real users within a reasonable time. Third, absence of a clear value proposition within the first sixty seconds. Fourth, friction that prevents a user from completing their first meaningful action. Fifth, any safety or security concern that arises from the demographic profile of the expected user base, as happened with the fitness app's location feature. These are the findings that do not belong in a research report that nobody reads. They belong in the product spec, with a documented response to each. ## Conclusion Strong feasibility research does not guarantee a successful product. But weak feasibility research, or research built from the wrong sources, creates a specific kind of false confidence that is harder to correct the further along the build you get. By the time the budget is spent, the decisions have already been made. The sources that matter most are not always the most visible ones. Competitor spreadsheets are visible. Platform demographic data takes more work. User behaviour under real conditions takes more work still. Safety concerns that emerge from knowing who your actual audience is are invisible until someone goes looking for them. The football platform's Android problem, the fitness app's location redesign: both of those outcomes were determined by data that was available before a single line of code was written. The question was whether anyone went looking for it in time. When we challenge founders on the depth of their user research, the intention is not to dismiss what they have already done. The competitive analysis, the market sizing, the feature mapping: all of it has value. User research adds the dimension that gives the existing data a different and more complete edge. The two things together produce something neither produces alone. If you are preparing for a product launch and want to understand which data sources should be informing your decisions, [let's talk about your feasibility research](https://weareaffective.com/get-started). ## Frequently Asked Questions What is app feasibility research and why does it matter? App feasibility research is the process of determining whether a specific product, for a specific audience, on the platforms they actually use, has a real chance of succeeding with real users. It goes beyond simply asking whether an app can be built or whether a market exists, focusing instead on whether genuine strangers will choose to use and return to the product. Why is competitor analysis alone not enough for feasibility research? Competitor analysis can map out the landscape of existing products and their features, but it cannot tell you whether users actually want what you are planning to build. In the case of a product designed to consolidate several existing tools, a spreadsheet cannot reveal whether combining those functions would make each one less useful than the specialist alternatives. What is the difference between stated intent and real user behaviour? Stated intent is what people say they will do when asked, whilst real behaviour is what they actually do once a product is in their hands. Research from AppTweak shows that 60 to 80 percent of users say they would use an app, yet actual usage settles at just 10 to 20 percent, which is a significant gap that many feasibility studies fail to account for. Why can friends-and-family surveys give founders a false sense of confidence? People who already know and support a founder are unlikely to give the kind of critical, unbiased feedback that reflects how a real stranger would respond to the product. This type of research tends to confirm what the founder already believes, leaving out the uncomfortable signals that could prevent costly mistakes later on. What are the risks of building on unreliable data sources during feasibility research? The danger is not a lack of information but an abundance of information that feels credible yet points in the wrong direction. Founders who build decisions on market sizing reports, app store rankings, or favourable surveys can run out of budget in the design and build phase before the product ever reaches real users. What should founders do when research findings contradict their expectations? Founders should treat unexpected findings as valuable signals rather than setting them aside in favour of data that confirms their original thinking. Ignoring contradictory evidence is one of the most common reasons products fail to reach a fully live state, as the article illustrates with two real project examples. How quickly do real users judge whether an app is worth keeping? Real users make rapid judgements, and a product needs to be understood within approximately sixty seconds of being opened for the first time. If a new user cannot grasp the value quickly, the likelihood of them returning the following day drops considerably, which is why testing with genuine strangers is so important. At what stage of the process should feasibility research be carried out? Feasibility research should inform the direction of a product before significant budget is committed to design and build. Leaving it too late means that by the time real user behaviour is observed, the cost of making meaningful changes has already become prohibitive. ## Related Articles [![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.