Five questions to ask before shipping a mobile feature

In February 2018, a tweet from Kylie Jenner accompanied a 6 % drop in Snap’s stock — $1.3 billion in market cap wiped out in a single day (Bloomberg, Feb 22, 2018). Eight words posted from her phone.

Kylie Jenner

@KylieJenner · February 21, 2018

sooo does anyone else not open Snapchat anymore? Or is it just me… ugh this is so sad.

↳ Time, Feb 22, 2018

The tweet didn’t create the problem. Against an already tense market, it made visible the rejection of a redesign shipped a few months earlier. Snap reported 191 million daily active users in Q1 2018 (Snap Inc. — Q1 2018 Results), then 188 million in Q2 2018 (Snap Inc. — Q2 2018 Results).

A Change.org petition against the redesign gathered 1.2 million signatures before Snap issued a partial rollback (TechCrunch, Aug 7, 2018).

There’s no way to know from the outside how Snap actually framed that decision. But the episode is a reminder of one simple rule: before you code, a team should be able to answer five questions.

This isn’t an isolated case. The same mistake plays out in mobile features every week — just without the media attention. One extra button, one screen, one notification. Three months later, the “small feature” has produced its bug tickets, tied up a designer through two iterations, changed the structure of a central module, and nobody can say whether it improved anything.

It’s not the engineering team’s fault. It’s not the product manager’s fault either. It’s what happens when you skip the boring part. The questions below aren’t magic. They simply forbid building something nobody can justify.

Question 1 — What problem are we solving?

The easiest to ask, the hardest to answer honestly.

The difficulty comes from a common trap: describing a solution while thinking you’re describing a problem. “We need to add a chat to the app” is not a problem. It’s a solution. The problem might be: “users can’t find how to reach us when they get stuck on step 3”, or maybe: “support receives 40% identical questions the documentation doesn’t cover.” Two different problems that would call for two different solutions.

The test I apply is simple: I force the phrasing to start with an observation, not an intention.

A trick borrowed from Toyota applies here: ask “why?” five times. A user forgets to log the visit. Why? Because they do it back at the office in the evening. Why? Because the app is too slow in the field. Why? Because it waits for network on every action. Why? Because offline wasn’t designed in from the start. Why? Because the initial brief said “input screen” instead of “sales rep’s day”. By the fifth why, the problem isn’t the one you thought.

Question 2 — For which user, exactly?

The second question keeps the answer to the first from drifting into “everyone.”

The word “user”, left unqualified, silently absorbs very different people. In a typical B2B app, there are at least three categories that share almost nothing: the person who uses the product every day, the person who checks it occasionally for a decision, and the person who pays but doesn’t use it at all. A feature that delights the third and complicates life for the first ends up with 2 stars on the store.

You also need to give up hollow demographics and describe real physical constraints.

A useful persona description sounds more like this:

“The user has 5 minutes on the subway, holds the phone with one hand, and can be interrupted at any moment.”

These constraints don’t say who the person is — they describe the conditions in which they’ll use the product. And those conditions drive the decisions.

These physical constraints then drive very concrete product choices: session length, ability to resume where you stopped, automatic saving, tap-target sizes. A hollow demographic persona (“Marie, 32, Parisian executive, into yoga”) doesn’t suggest any of these choices.

Question 3 — Which behavior should change?

This question is what most distinguishes a mature product team from a feature factory.

An immature roadmap lists what will be built: “chat, push notifications, dark mode.” A mature roadmap lists the behaviors you want to see appear, disappear, or grow in users.

The most useful model for understanding why a behavior happens is BJ Fogg’s (Behavior Design Lab, Stanford). Its current form is B = MAP — Motivation × Ability × Prompt = Behavior (behaviormodel.org). Fogg officially replaced “Trigger” with “Prompt” in late 2017 — you’ll still see the older B = MAT in many resources.

If any of the three is missing, the behavior doesn’t happen. This grid changes the question. Instead of asking “should we add this feature?”, ask: does this feature increase Motivation, Ability, or provide a Prompt — and which of the three is the current limiting factor?

That Fogg lens reshapes the team conversation. Instead of “should we redo the onboarding?”, ask: “do new users have enough M, A, or T to reach the first moment of value? Which one is missing most?”

Question 4 — How do we measure that it works?

The fourth question plays a special role: it turns an opinion conversation into a decision conversation.

A team without a pre-defined metric will always interpret data after the fact to justify what they’d already decided. Classic confirmation bias. A team that defined its criterion before implementation can be wrong — and see it.

The most useful distinction is the one Eric Ries formalizes in The Lean Startup: vanity metric versus actionable metric.

The canonical mobile example is Facebook in 2007. Chamath Palihapitiya has just joined the growth team. He’s looking for what separates users who stay active for life from those who churn after a few days. By comparing active and inactive cohorts, his team identifies a single structuring difference: users who stay active for life all added 7 friends in their first 10 days (Chamath Palihapitiya, Startup Grind, 2013).

That metric then guided Facebook’s entire growth strategy. Not total signups. Not average time on site. A single metric — the percentage of new users who reach 7 friends in 10 days — steered all product decisions that carried the network to a billion users.

There’s also the distinction between leading and lagging indicators, especially useful in mobile products with long cycles. Revenue, annual churn, NPS are lagging indicators: by the time they move, it’s too late to act. Day-two usage, number of actions in the first seven days, onboarding completion rate are leading indicators: they predict the lagging ones by several weeks.

Question 5 — What failure modes should we plan for?

The last question is the most unloved. It feels like putting a damper on things right before you start. In practice, it’s the one that saves the most sprints — and the kind of exercise that could have reduced the risk of the 2018 Snapchat redesign.

Gary Klein, a decision-making researcher, proposed an exercise in the September 2007 Harvard Business Review he calls a pre-mortem (Klein, HBR, Sept. 2007). Before you start, imagine six months have passed and the project is a disaster. Write the story of that failure.

The exercise sidesteps a robust bias: people are much better at spotting risks when they visualize them as already happened, rather than as abstract probabilities.

There’s also a simple rule from Scott Hurff (Designing Products People Love) (scotthurff.com) to make sure nothing gets forgotten at the screen level. Five interface states must always be designed:

• Ideal state — everything is fine, data present.
• Empty state — no data yet.
• Error state — something failed.
• Partial state — incomplete data.
• Loading state — waiting.

A feature that only designs the happy path is incomplete, and it shows in V1.

Finally, a three-question resilience rule to apply systematically before coding:

These three questions cover the majority of field bugs on mobile. Every “I don’t know” left unanswered stands a good chance of resurfacing as a production bug after release.

The grid in practice — a full example

Concrete case. A field sales (SFA) app used by roughly a hundred mobile sales reps. Feature proposed: an “log client visit” button on the home screen.

Q1 — Problem. An internal audit shows reps re-enter their visits in the evening back at the office. 20% are forgotten, 40% are incomplete. This isn’t an ergonomics problem — it’s a moment-of-input problem.

Q2 — User. A mobile rep, often standing, in a noisy store, one hand holding a box of samples. Never has 5 minutes between visits. Doesn’t re-read anything later.

Q3 — Behavior. Move from “delayed entry at the office” to “immediate entry in the field.” Limiting factor: Ability (Fogg’s A). Well-aimed solution: drastically lower the cost of entry via a one-tap voice recording, with automatic geolocation as a contextual trigger.

Q4 — Measure. Metric: percentage of visits logged within 30 minutes of client geolocation. Target: from 15% to 60% in 3 months. Decision: if the metric doesn’t reach 40% by D+45, rethink the approach rather than iterate on details.

Q5 — Failure modes. No network (offline queue), muted microphone (text fallback), user closes the app (immediate auto-save), accidental double tap (server-side idempotency), geolocation off (manual backup button).

This grid fits on one page. It takes 45 minutes to fill in seriously as a team. It generally saves several weeks of misaimed development.

Why this is a seniority marker

One of the most robust lessons mobile development produces is that seniority isn’t limited to technical mastery. It includes the ability to slow down the start.

An intermediate engineer says yes to the requested feature and starts coding. A senior engineer says: “before we start, let’s take 45 minutes to run these five questions.”

That ability to politely but firmly delay the beginning of work — without being seen as an obstacle — is a signal that many CTOs and engineering managers appreciate in their senior hires. Not because they want people who slow things down. Because they know the cost of a poorly framed feature far exceeds the cost of 45 minutes of framing.

The grid distills much older ideas — Marty Cagan (Inspired, 2017), Teresa Torres (Continuous Discovery Habits, 2021), Eric Ries, BJ Fogg, Gary Klein, Alan Cooper. Its value isn’t originality. It’s that it makes explicit what the best teams do intuitively.

Sources — overview

All sources are cited inline in the text. Synthetic view for quick verification:

• Snapchat 2017-2018: Bloomberg (Feb 22, 2018) · TechCrunch (Aug 7, 2018) · Time (Feb 22, 2018) · Change.org petition: 1.2 M signatures.
• Duolingo & Fogg: Duolingo Blog — How Streaks Keep Learners Committed · Deconstructor of Fun · BJ Fogg, Tiny Habits (Houghton Mifflin, 2019) · behaviormodel.org.
• Facebook 7 friends in 10 days: Chamath Palihapitiya — Startup Grind, 2013.
• Cited frameworks: Marty Cagan, Inspired (Wiley, 2nd ed. 2017). Teresa Torres, Continuous Discovery Habits (Product Talk LLC, 2021). Eric Ries, The Lean Startup (Crown Business, 2011). Alan Cooper, The Inmates Are Running the Asylum (Sams, 1998). Gary Klein, Performing a Project Premortem, HBR, September 2007. Scott Hurff, Designing Products People Love (O’Reilly, 2015).
• Eric Meyer on edge cases: Inadvertent Algorithmic Cruelty — A List Apart, 2014.
• Verification: figures and dates verified in August 2026 via the primary sources above.