A founder sits across from a growth agency on a discovery call. The agency proposes a 2-week user-research sprint before any redesign work begins. The founder pushes back, politely: we already have analytics — Mixpanel, Amplitude, the dashboard tells us where users drop off. Can't you just look at the data?
The objection is reasonable on its face. Analytics is real data, collected at scale, with no recruitment lag. The dashboard never sleeps. But analytics shows what users did, not why they hired your product in the first place — and, more importantly, what they'll fire it for if the redesign misses the job they came to get done. A redesign built on data alone optimises a surface. A redesign built on the right user understanding repositions the surface to do a different job.
This piece exists to make the methodology argument explicit: why user interviews — and Jobs-to-be-Done (JTBD) interviews specifically — belong upstream of any serious redesign, what analytics alone can't tell you, the 5 questions Applica Agency asks in every JTBD interview, when interviews are a bad spend, and how JTBD findings translate into shipped product decisions with named outcomes.
The procurement-stage objection — "can't you just look at the data?"
Three things sit underneath that objection, and naming them upfront usually moves the conversation forward.
The first is budget. User research carries a real cost — recruitment, incentives, interview hours, synthesis time — that doesn't show up on the dashboard the way an experimentation platform subscription does. For an earlier-stage subscription app, every two-week spend has to defend itself against the alternative of shipping something.
The second is speed. Analytics is already there. Interviews take weeks to schedule, conduct, and synthesise. The founder isn't wrong that the path-of-least-resistance answer to "where's the leak?" is to open the funnel chart and start there.
The third — and the one that matters most — is a category confusion. Analytics is the right starting point at the optimisation stage; interviews are the right starting point at the redesign stage. They answer different questions. Optimisation asks which version of this surface performs better? — and analytics, paired with A/B testing, is the validation gate that answers it. Redesign asks what surface should exist here, and what job should it be doing? — and analytics has nothing to say on that question, because the data only describes the current surface, not the one that doesn't yet exist.
When the redesign question gets answered with optimisation-stage tooling, the team optimises the wrong thing precisely.
What user interviews surface that analytics doesn't
4 categories of insight sit outside what any dashboard can capture — and each one routinely changes a redesign decision when surfaced.
What analytics shows vs. what JTBD interviews surface — the 4 categories of insight a dashboard can't deliver.
| Category | What analytics shows | What JTBD interviews surface |
|---|---|---|
| Motivation | A user opened the paywall, hesitated 12 seconds, dismissed it | The specific reason — wrong price, wrong moment, wrong value framing, or no buying intent in the first place |
| Mental models | Drop-off rates on the screen the team calls "the paywall" | The user's own name for the surface and the assumptions that come with it — almost never matching the product taxonomy |
| Switching forces | Install date and source attribution | The push from the old solution, the pull toward the new one, the anxiety holding the decision back, and the habit competing for the user's behaviour |
| Stated vs actual behaviour | What users do, captured at scale | The gap between what users do, what they say they do, and what they say they want — three different things |
Motivation behind the action. Analytics tells you a user opened the paywall, hesitated 12 seconds, and dismissed it. It cannot tell you whether they dismissed it because the price was wrong, the moment was wrong, the value proposition wasn't visible, or because they were checking the app at a stoplight and had no intention of buying anything yet. Qualitative research closes the gap between the what the dashboard shows and the why behind it — and that gap is exactly where redesign decisions get made.
Mental models. Users almost never describe the product the way the product team does. Internally, the team calls a screen "the paywall." The user calls it "the sign-up wall" or "the upgrade page" or doesn't call it anything at all because they think of the whole experience as "the part where it asks me to pay." Mental-model mismatches between the product taxonomy and user vocabulary are the source of most copy and information-architecture missteps. The fix isn't visible in the dashboard.
Switching forces. Bob Moesta's adaptation of Jobs-to-be-Done identifies 4 forces acting on every adoption decision: push from the old solution, pull toward the new one, anxiety about switching, and habit holding the user in place. Analytics can show that a user installed your app on Tuesday. It can't show that the push came from a frustrating conversation with their doctor, the pull came from a TikTok video, the anxiety came from a previous bad experience with a similar app, and the habit they were trying to break was 6 months old. Without naming those forces, the team designs an onboarding flow against the wrong reference frame.
The gap between what users say and what they do. The anthropologist Margaret Mead is often paraphrased as observing that what people say, what people do, and what they say they do are three different things. That gap is the most-cited reason qualitative research methods exist at all, and it's the reason a single well-run JTBD interview routinely outperforms a 200-respondent survey on the questions that matter for redesign.
None of these show up on the dashboard. All of them change the brief.
What is Jobs-to-be-Done?
Jobs-to-be-Done is a theory of innovation built around a single reframe: people don't buy products, they hire products to get a job done. The job is the progress the user is trying to make in a particular situation. The product is one of several possible solutions they could have hired — often including doing nothing at all.
The framework has 3 lineages worth knowing about. Tony Ulwick conceptualised the underlying methodology — Outcome-Driven Innovation — in the early 1990s by applying Six Sigma thinking to the innovation process. Harvard Business School professor Clayton Christensen popularised the framing in his 2003 book The Innovator's Solution, and made it famous with the milkshake story — a fast-food chain trying to sell more milkshakes discovered the product was being "hired" for two very different jobs (boring morning commute vs. afternoon treat for kids), each with its own set of design implications. Bob Moesta — who worked alongside Christensen at Harvard — developed the interview methodology, the Switch Interview, that produces the data the framework runs on.
Most software companies that publish on JTBD frame it the same way Intercom does: replace the question "what features does this customer want?" with "what is the customer hiring this product to do?" The first question produces feature backlogs that grow indefinitely. The second question produces redesigns that change what the product is, not just what it has.
For subscription mobile apps specifically, the framing matters because the job is rarely "use this app." It's make progress on something the app helps with — sleeping better, learning a language, tracking finances, breaking a habit, building one. The job is the destination; the app is a vehicle the user can fire and replace at the cost of a 12-second App Store search.
The 5 questions Applica asks in every JTBD interview
The Moesta Switch Interview maps a user's adoption decision across a 6-stage timeline — first thought, passive looking, active looking, decision, first use, ongoing use. Re-Wired Group, the consultancy Moesta co-founded, runs the canonical version of this interview methodology. Applica Agency's interview script adapts that timeline into 5 questions, tuned for subscription mobile context. The questions look simple. The discipline is in the follow-up probes — the patient why and tell me more about that that surface the forces underneath the surface answers.
Q1 — "Walk me through the day you first thought you needed something like this." Surfaces the trigger event and the push force from the previous solution. The useful answer isn't I downloaded it last March; it's my doctor told me my resting heart rate was up and I cancelled my Apple Health subscription a week before that because I never opened it. The mistake to avoid: accepting a generic recall ("I just wanted to be healthier") without probing for the specific moment.
Q2 — "What were you using before, and what broke down?" Surfaces switching forces and competing solutions, which are usually not other software. A meditation app's real competition is often a glass of wine, not Headspace. Moesta's framing emphasises that we interview customers who already switched, not prospects — because only completed switches let you reconstruct the full causal story.
Q3 — "When you first signed up, what were you hoping would happen in the first few days?" Surfaces the activation event the product team should be designing the onboarding flow around. The answer is almost never learn how to use the app. It's something concrete and outcome-shaped — get to sleep on the first night, sign my first basic phrase by Thursday, cancel the credit card I never use.
Q4 — "Tell me about the first time the app actually delivered on that — what happened?" Surfaces the real Aha moment, often different from the team's hypothesis. The team thinks the Aha is finishing the first lesson; the user describes it as the moment the streak counter hit 3 days. The redesign decision changes accordingly.
Q5 — "What's still frustrating, but not bad enough to make you leave?" Surfaces retention risk and feature-priority signal. The answer is the polite catalogue of things the user has resigned themselves to — and the next time a competitor solves any of them, retention will move.
The interview methodology has decades of practitioner literature behind it, but the part that earns its place isn't the question list. It's the operator's willingness to sit through silence and ask and then what happened? one more time than feels comfortable.
How JTBD findings translate into product decisions
Findings are inert until they change a decision. 3 application areas turn JTBD output into shipped product work.
Onboarding redesign. The most direct translation. JTBD interviews surface the job the user came to do; the first 60 seconds of onboarding can either name that job or list features that have nothing to do with it. ASL Bloom, a sign language learning app, rebuilt its onboarding around the job learners hired the app to do — communicating with a Deaf family member, not "exploring our 1,200-sign library." Trial conversion lifted 15%. The pattern is the same one the onboarding-UX literature has been pointing to for years: the first 60 seconds work when they answer the what's in it for me question in language the user already uses.
Paywall messaging. The paywall is rarely a price problem. It's a value-articulation problem at the moment of friction. JTBD interviews give the team the language users themselves use to describe the job — and pasting that language onto the paywall, almost word-for-word, routinely outperforms agency-written copy on the same surface.
Peech, a text-to-speech reader app, illustrates the pattern at the welcome-screen level. The original copy listed features — what Peech was. JTBD interviews surfaced the gap between the feature list and what users actually needed to hear before signing up: how Peech fit into their day, why it solved the problem they came with. The rewritten welcome screen was nearly twice as long as the original, which conventional best practice says is the wrong direction. A 50/50 split test over 25 days on first-time users in the US lifted lifetime value (LTV) by 30% at 99.8% confidence. The counter-intuitive result is the methodological proof point: a JTBD-informed hypothesis outperformed a best-practice intuition that would have shortened the copy instead of lengthening it.
Feature prioritisation. The hardest translation, and the most valuable. JTBD findings make it possible to defend features that underperform on analytics but surface in interviews as load-bearing, and to cut features that look fine on the dashboard but serve no job anyone hired the product for. The roadmap argument becomes evidence-based instead of opinion-based, which is what the framework was originally built for.
When are user interviews a bad spend?
The counter-intuitive section. JTBD interviews aren't always the right starting point. 3 conditions make them a bad spend.
The 3 conditions where JTBD interviews aren't worth doing — and what to spend the budget on instead.
| Condition | When it applies | What to do instead |
|---|---|---|
| Data-rich, low-stakes decisions | Button-position tests, copy variants with 2 plausible alternatives, notification-time experiments — reversible, A/B testable in days | Analytics-plus-experimentation: run the test, validate in days, ship the winner |
| Anonymity-bound categories | FinTech KYC flows, mental health, prayer apps, women's health, addiction recovery — recruitment friction is high and social desirability bias is structural | Diary studies, anonymised in-app surveys, support-ticket synthesis, App Store review mining |
| Mature products, stable user base | Established discovery muscle in place; recent-purchaser cohort too small to refresh signal; new interviews surface patterns the team already knows | Periodic cohort re-interviews when segmentation shifts; otherwise prioritise the existing backlog over fresh research |
Data-rich, low-stakes decisions. A button-position test, a copy variant with 2 plausible alternatives, a notification-time experiment — these are A/B testable in hours, validated in days, and the cost of a wrong answer is reversible. Spending two weeks on user research to inform a button-position decision is methodology theatre. The right discipline here is analytics-plus-experimentation, not qualitative work upstream of it.
Anonymity-bound categories. FinTech KYC (Know Your Customer) flows operate under recruitment constraints that make representative interviewing structurally difficult — and even with cleared recruitment, social desirability bias around money, debt, and verification spikes the signal-to-noise ratio downward. The same applies to intimate WellTech categories — mental health, prayer apps, women's health, addiction recovery — where users are reluctant to discuss the underlying job candidly in a recorded interview. In these categories, qualitative work isn't avoided — it adapts. Diary studies, anonymised in-app surveys, and support-ticket synthesis often outperform live interviews on the same questions.
Mature products with a stable user base and an established discovery muscle. Interviews surface the same patterns the team already knows; diminishing returns set in around the 50th interview unless segmentation has shifted or a new entrant has reshaped the competitive landscape. Practitioners often recommend limiting interviews to customers who purchased within the last 6 months precisely because recall quality collapses after that — and on a mature product, the recent-customer cohort may not be large enough to support a meaningful interview pass without re-running it constantly.
The judgement call about when not to interview is what separates methodology from ritual.
How Applica integrates JTBD into the first 30 days of an engagement
Discovery sprint runs in weeks 1–2 of an engagement, before any redesign or A/B testing work begins. 5 to 8 interviews on recent purchasers — 30 to 45 minutes each, recorded, transcribed, synthesised. Output is concrete: a switching-forces map, an activation-event hypothesis, a copy-language source bank pulled from the transcripts, and a prioritised hypothesis backlog grounded in real user motivation rather than dashboard pattern-matching. The full operating sequence is covered in our companion piece on how we kick off the first 30 days of an engagement.
This is also where the discovery-phase work compresses the ROI timeline downstream. A sharp hypothesis — the welcome screen needs to name the job, not list features — needs one well-run test to validate. A vague hypothesis — the welcome screen could be improved somehow — needs ten. The compounding effect across the rest of the engagement is significant, which is part of why hypothesis quality is one of the 4 conditions that determine speed-to-impact. Once the interviews have surfaced the right hypotheses, the analytics setup that makes the resulting onboarding tests readable is the foundation underneath every shipped winner that follows.
Frequently asked questions
How many user interviews do you actually need?
5 to 8 interviews give a directional read on a single job for a single segment. 12 to 15 cover cross-segment validation when the app has clearly different user populations. Diminishing returns set in around the 10th interview within a single segment, which is why most JTBD practitioners recommend running short, focused interview passes rather than long open-ended research projects. The discipline is in the synthesis — patterns repeat across the first 5 interviews, not the first 50.
Can we skip interviews if we already have qualitative survey data?
Usually no. Surveys capture what users say at a moment of low cognitive engagement — they're answering quickly, often on a phone, and the format constrains the response to whatever the question already anticipated. Interviews reconstruct the story of a real switching decision in the user's own language, with the interviewer's follow-up probes surfacing things the survey didn't know to ask. The two methods are complementary, not interchangeable.
What if our users won't talk to us?
Three lower-friction adjustments usually move the response rate. Incentives that match the audience — $50–$100 USD for consumer apps in Tier-1 markets, calibrated by segment. Segment selection — recent purchasers within the last 6 months respond at higher rates because the experience is fresh. Alternative recruitment — Userinterviews.com and similar marketplaces, plus support-ticket transcripts and App Store reviews as fallback signal sources when live interviews aren't available.
Three takeaways
First, analytics shows you what users did. JTBD interviews surface why they hired your product — and what they'll fire it for if the redesign misses the job they came to get done. Both layers belong in the operating system; neither replaces the other.
Second, the 5 questions surface things no survey, no dashboard, and no best-practices playbook will tell you. The discipline isn't in the script — it's in the follow-up probes, the patience to sit through silence, and the willingness to ask and then what happened? one more time than feels comfortable.
Third, interviews aren't always the right spend. The judgement call about when not to interview is what separates methodology from ritual — and the agencies worth working with tell you which side a given engagement sits on before the discovery contract gets signed.
If you're about to commission a product redesign and the team is leaning on analytics alone, talk to us before the design work starts — Applica Agency's Subscription App Optimisation engagements open with a discovery phase exactly for this.
