---
title: How do you research what technologies your app users want?
description: Learn how to research which technologies your app users want, using interviews, surveys, analytics and findings to build a prioritised roadmap.
image: https://weareaffective.com/hubfs/learning-centre-images/how-do-you-research-what-technologies-your-app-users-want.webp
---

[Skip to content](https://weareaffective.com/learning-centre/how-do-you-research-what-technologies-your-app-users-want#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

# How do you research what technologies your app users want?

 Table of Contents

A founder once came to us with a colour-coded spreadsheet. It mapped every feature their three main competitors had built, column by column, with gaps highlighted in red. The logic was clear: find the gaps, fill them, launch. The problem was that nobody had spoken to a single potential user. The spreadsheet told them what existed. It told them nothing about what people actually needed, or whether those gaps were gaps at all.

> Researching what users want is really about understanding what they need to do and how they feel doing it now.

This is one of the most common ways product teams go wrong before they've written a line of code. The question of which technologies to build inside an app feels like a technical one, so the response is often to look at other products rather than at people. But technology decisions are really behaviour decisions. They answer the question of what a person will do, and why, and how often. You cannot read that off a competitor's feature list.

The good news is that the research methods for answering these questions are not exotic. Interviews, surveys, focus groups, and usage data are all available to any product team. The harder part is knowing how to run them well, who to recruit, what questions to ask, and what to do when the findings challenge the assumptions everyone in the room has quietly committed to.

## Why Guessing Which Technologies to Build Is So Costly

Building the wrong thing is expensive in a way that only becomes visible later. Development time, design time, and testing time all get consumed by a feature before anyone outside the team has tried it. By the time users confirm it does not solve a real problem, the budget has already moved on.

The scale of this is worth understanding. According to [The Standish Group's CHAOS Report](https://www.studocu.com/da/document/erhvervsakademi-aarhus/systemudvikling/chaos-report-2015-the-standish-group/19026719), 45% of features in software projects are never used. That is not a rounding error. That is close to half of everything a product team builds sitting idle after launch.

For lifestyle app founders specifically, the cost runs deeper than wasted development spend. A cluttered app with features nobody wanted creates a worse experience for the people using the features that do work. Cognitive load rises. The product feels heavy. Users drop off, and the team spends the next cycle trying to understand why retention is soft, when the answer was written into the product from the start.

The underlying cause is almost always the same. Decisions about what to build got made by people inside the product rather than by the people who would use it. Sometimes that happens because research felt too slow or too expensive. Sometimes it happens because a founder had strong personal conviction and did not want anything to complicate it. Both paths lead to the same place.

## Start With the Problem, Not the Feature

One of the most reliable mistakes in product research is asking users which features they want. Users are not product designers. When asked directly, they will describe what they have already seen somewhere else, or they will name the symptom rather than the cause. Neither answer tells you what to build.

The better question is always about the problem. What are you trying to do right now? How are you doing it? How does that feel? The follow-up to that last question matters more than teams typically realise. If someone is managing a task manually and is broadly content with how it works, there is no strong reason to build a technical solution. The effort of learning and adopting something new has to be worth it, and if the current approach is fine, it probably is not.

Where research becomes genuinely useful is in identifying where the current process is failing people, and specifically how it is failing them emotionally, not just functionally. A user might describe a process as "annoying" or "slow" without being able to say exactly what would fix it. The researcher's job is to dig into that friction and understand what sits underneath it. That is where the real product insight lives.

Before writing a research script, write out every assumption your team currently holds about why users struggle with a problem. Those assumptions are your actual research questions, and they are the ones most likely to be wrong.

## 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

## Qualitative Methods: Interviews, Focus Groups, and What They Surface

One-to-one interviews and focus groups are the two qualitative methods product teams reach for most often, and they serve different purposes. An interview gives you depth. A focus group gives you texture and social dynamics that no individual session can produce.

On a concierge app we worked on for a high-end property development, we ran focus groups with two groups that had no overlap in profile. The first was the actual target audience: high-net-worth residents. The second was people from social housing, who would never be customers. We brought the second group in because they had something we were trying to build into the product: a genuine sense of community, where people knew their neighbours and talked to each other. That quality is almost entirely absent in high-rise premium developments.

What the sessions revealed was that the core problem had nothing to do with what the concierge could or could not do. It came down to communication. Residents simply did not know each other. So we stopped designing around concierge task-management and redesigned around social connection. We automated the routine, mundane tasks so the concierge had more time for actual human interaction. We added personalisation so residents could see who their neighbours were and what they were interested in. The social housing focus group gave us the benchmark for what "good" looked like, and the high-net-worth sessions told us what was currently missing.

> The most useful research participant is sometimes the one who will never become a customer.

That is the kind of finding that only comes from qualitative work. No survey would have surfaced it.

## Recruiting the Right Participants (Including Unexpected Ones)

Recruiting for user research tends to follow the path of least resistance: find people who match the target customer profile and talk to them. This is sensible but incomplete. The concierge app project is a direct example of why [recruiting outside your assumed audience](https://weareaffective.com/learning-centre/why-your-best-users-are-often-your-worst-source-of-product-direction) can be the most productive decision in the whole research process.

The practical question is how to find the right people. For existing products, your own user base is the first place to look. Segment by behaviour, by usage frequency, or by the specific part of the product you are researching. Not every user is equally relevant to every question, and a heavy user of one feature will give you different feedback from someone who tried it once and never returned. Both perspectives matter, but they need to be weighted accordingly when you review what you heard.

#### Recruiting Beyond the Obvious

For pre-launch products, where there are no existing users, recruitment requires more creative thinking. Communities, forums, social groups, and professional networks can all surface people who have the problem you are trying to solve, even if they would not immediately describe themselves as your target audience. The goal is to find people who have lived experience of the friction you are trying to address.

When a stakeholder later challenges findings on sample size grounds, the answer is not to defend the number of participants. Accept that more voices are always better, and then assess whether the findings pointing to significant changes are specific enough to be tabled for quantitative validation. If the concern persists, move from exploratory qualitative sessions into [predefined surveys that can reach far more respondents](https://weareaffective.com/learning-centre/5-user-testing-methods-that-will-save-your-app-from-failure) than any interview programme can.

## Quantitative Methods: Surveys, Analytics, and Usage Data

Surveys and analytics answer different questions from interviews. Where interviews tell you why something is happening, quantitative methods tell you how often, how many, and where in the product. Both are needed, and neither is sufficient alone.

Surveys work best when the [hypothesis is already formed and you need to test it](https://weareaffective.com/learning-centre/how-to-write-a-product-hypothesis-a-development-team-can-actually-test-against) at scale. A well-constructed survey with predefined answer options can reach hundreds of respondents and tell you whether a pattern identified in qualitative sessions holds across a broader population. The design of the questions matters enormously here. Leading questions, or questions that assume the problem your team already believes is the problem, will produce data that confirms what you already thought.

#### Reading Analytics Honestly

Analytics data is particularly susceptible to misinterpretation. A drop-off at a particular screen might mean the screen is confusing, or it might mean users have completed what they came to do and are leaving satisfied. A low dwell time might indicate disengagement, or it might indicate that a screen is so clear users process it immediately. The data does not explain itself. Before drawing conclusions, check whether the interpretation holds up against what qualitative sessions have already suggested.

Behavioural patterns within the product, including dwell time, speed of movement, return visit frequency, and task completion patterns, can indicate the emotional state users are in when they arrive. A user who moves through a product very slowly and revisits the same screens is telling you something different from one who completes a task cleanly and closes the app. These patterns shape which technology investments are worth making and which features are actually being used rather than just existing.

Cross-reference your survey findings against your analytics data before presenting them. Where the two sources contradict each other, that tension is the most interesting thing in the room and deserves its own investigation.

## How to Run a Research Debrief That Actually Influences Decisions

Research that does not change anything is just an exercise. According to [Maze's Research Maturity Report](https://maze.co/resources/research-maturity-report/), organisations that use research at its highest potential see 2.3 times better business outcomes, including faster routes to market and measurable revenue increases. The gap between organisations that achieve that and those that do not is rarely about research quality. It is about what happens after the sessions end.

A debrief needs a structure if it is going to move from findings to decisions. The sequence we use starts by restating [what was being tested and what the research was trying to achieve](https://weareaffective.com/learning-centre/how-to-run-a-concept-test-that-doesnt-just-confirm-what-the-team-already-believe). This sounds obvious, but a room full of stakeholders often arrives with different memories of what the original question was, and without agreement on that, the conversation goes in circles.

From there, the debrief reviews the user profiles of the participants so their feedback can be weighted appropriately. A finding that came exclusively from heavy users means something different from one that appeared across both new and established users. The next step maps the business value and potential uptake of each feature under discussion, followed by an effort versus impact assessment that produces a clear view of what to prioritise, what to defer, and what to drop entirely.

The critical condition for all of this is that [the people in the room have genuine openness](https://weareaffective.com/learning-centre/what-a-development-team-actually-needs-to-know-about-the-user-before-sprint-one) to what the data shows. Without that, the structure does not matter.

## When Founders Ignore the Research They Commissioned

We have seen this pattern clearly enough across two specific projects to describe it in detail. One was a fitness and wellness app. The other was a grassroots football product. In both cases, the founder came to the work with strong personal conviction about what the product needed to be, and in both cases the research that emerged from focus groups, surveys, and user sessions pointed in a different direction.

The early warning signs were the same in both projects. An excessive drive to perfect the product before launch. Sign-offs that got rolled back to request further changes. Decision-making that stretched longer than the budget allowed for. Both products became what we would describe as vanity products: shaped by what the founder wanted to see rather than [what the evidence suggested users needed](https://weareaffective.com/learning-centre/how-to-test-a-product-concept-with-behavioural-realism-rather-than-interview-ent).

Both projects exhausted their budgets in the design and build phases without ever reaching a fully live product. The research had been commissioned and had produced real findings. The problem was never the quality of the work. It was the gap between what the data said and what the founder was prepared to act on.

According to Dovetail's State of User Research report from 2022 to 2023, around 60% of researchers said their work was sometimes or rarely acted upon. Of those, roughly 40% cited lack of stakeholder engagement as the primary reason. That pattern is not unique to small teams. It describes a systemic failure to treat research as input rather than decoration.

## Turning Research Findings Into a Prioritised Technology Roadmap

Research findings on their own are raw material. The work of turning them into a sequence of technology decisions requires a separate, deliberate step that many product teams skip.

The most useful frame for this step is an honest assessment of two variables for each potential technology feature: how much effort it requires to build, and how much impact it is likely to have on the users who would use it. These two variables produce four categories that are far more actionable than any ranking by user enthusiasm alone.

| Effort | Impact | Decision |
| --- | --- | --- |
| Low | High | Build first |
| Low | Low | Deprioritise |
| High | High | Plan carefully, build later |
| High | Low | Drop entirely |

The business value of a feature to the organisation sits alongside potential user uptake in this assessment. A feature with high user demand but no commercial logic is just as problematic as one with commercial logic and no user demand. Both variables need to be visible in the same conversation, which is why the debrief and the roadmap process belong together rather than in separate meetings.

When presenting a technology roadmap to stakeholders, show the research finding that drove each decision. A roadmap without its evidence attached is just a list of opinions, and it is much easier to override.

## Making Research a Habit, Not a One-Off Exercise

One round of research before a launch tells you something about what users need at that point in time. It does not tell you anything about what they will need six months later, or how their behaviour will change once they have been using the product for a while. A single research exercise, however well designed, has a short shelf life.

The support queue is one of the most underused research inputs available to product teams. Patterns in support requests point directly at the parts of the product where users are confused or stuck. A cluster of questions about the same feature, or the same step in a journey, is a signal that something in that area is not working as intended. Tracking those themes over time gives you a low-cost, continuous feed of real user difficulty that no quarterly survey can replicate.

Building research into the product development cycle, rather than treating it as a standalone pre-launch activity, changes the relationship between the team and their users. Decisions get made with more confidence because the evidence is more recent. Assumptions get tested before they become commitments. And the cost of being wrong drops considerably when findings surface early, before a technology choice has already been built and shipped.

1. Review support request themes monthly and map them back to specific product areas
2. Run short feedback surveys after meaningful in-app moments, not at the point of opening
3. Schedule a qualitative session with a small group of users every quarter
4. Treat analytics anomalies as research questions, not just performance issues
5. Document what each research round changes in the product, so the team can see the connection between input and decision

## Conclusion

The question of which technologies to build in an app is really a question about people, and it is best answered through [app user research](https://weareaffective.com/app-user-research). What problem are they trying to solve? How are they solving it now? Where does that process break down for them, practically and emotionally? The technology decision follows from those answers, not the other way round.

The methods for finding those answers are not complicated. Interviews, focus groups, surveys, analytics, and support data are all accessible to any product team. The harder discipline is running them with genuine openness, recruiting participants who challenge your assumptions rather than just confirm them, and then treating what you find as the actual input to the roadmap rather than as something to set aside when it gets inconvenient.

The two projects we described above, the fitness app and the grassroots football product, both had access to real research. The findings were there. What those projects needed was a team prepared to act on what the research said, even when it complicated the founder's existing vision. That gap between commissioning research and being changed by it is where most product decisions go wrong.

Researching what users want is an ongoing process of listening carefully, testing assumptions, and adjusting course. The products that get it right tend to get it right consistently, not just at launch.

If you are trying to work out which technologies are worth building into your app and want a research process that actually shapes the roadmap, [let's talk about your product](https://weareaffective.com/get-started).

## Frequently Asked Questions

Why is looking at competitor features not enough when deciding what to build?

Competitor analysis tells you what already exists, but it cannot tell you whether those features solve real problems for real people. Technology decisions are fundamentally behaviour decisions, and you cannot read human behaviour off a feature list.

What is the most common mistake product teams make when researching user needs?

The most common mistake is asking users which features they want, rather than asking about the problems they face. Users tend to describe features they have already seen elsewhere, or name symptoms rather than root causes, neither of which gives you reliable direction.

How much of what product teams build typically goes unused?

According to The Standish Group's CHAOS Report, 45% of features in software projects are never used after launch. That is close to half of all development effort producing nothing of value to the people the product was built for.

What research methods are available for understanding what app users actually need?

Interviews, surveys, focus groups, and usage data are all accessible to any product team. The challenge is not finding exotic tools but rather running these methods well, recruiting the right people, and asking the right questions.

What kinds of questions should you ask users during research?

The most useful questions focus on what users are trying to do, how they currently do it, and how that experience feels. Follow-up questions about their emotional response to the current process are particularly valuable, as they reveal where genuine friction exists.

Why does building unwanted features harm the overall user experience?

Features nobody uses add clutter and increase the cognitive load placed on people who are using the product for the things that do work. The app starts to feel heavy, users disengage, and retention suffers in ways that can be difficult to trace back to the original cause.

When is it not worth building a technical solution for a user task?

If users are managing a task manually and are broadly content with how it works, there is often no strong case for building a feature to replace it. The effort of learning and adopting something new has to justify itself, and if the current approach is working well enough, it usually does not.

What are the main reasons product teams skip user research?

Research is often skipped because it feels too slow or too expensive relative to the pace a team wants to move at. In other cases, a founder has strong personal conviction about what to build and does not want findings that might complicate or challenge that view.

## 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)

<https://linkedin.com/company/weareaffective> <https://instagram.com/weareaffective> <https://facebook.com/weareaffective>

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.