Performance and Battery Budgets: The Non-Functional Requirements Mobile PMs Must Own

Cold-start time, frame jank, and battery drain are product decisions, not just engineering concerns — they shape retention and reviews as much as any feature. Mobile PMs should write explicit, numeric performance and battery budgets into the spec, treat budget violations as bugs, and review them at every release the same way they review functional acceptance criteria.

Quick Answer: Set numeric budgets for cold start (under 2s), warm start (under 1s), frame rate (under 1% janky frames), battery drain (under 2-3%/hour active use), and ANR rate (under 0.47%). Put them in the PRD, gate releases on them, and treat regressions as release-blocking bugs.

Why Performance Is a Product Requirement, Not an Engineering Nice-to-Have

Performance determines whether users experience the feature you shipped at all. A beautifully designed flow that takes four seconds to load or drains 15% battery per hour will get uninstalled before anyone judges its design. PMs who leave performance to "whatever the team can manage" are quietly outsourcing a product decision to whoever has the most sprint capacity.

Non-functional requirements (NFRs) like startup time, responsiveness, and energy use are just as much part of the user experience as button placement. Google's own research team has published that as page/app load time increases from 1 to 3 seconds, the probability of a user bouncing rises sharply — the same pattern holds for mobile app launches. Users don't file a bug report about slowness; they just leave, and often 1-star the app on the way out.

The fix is structural: define performance budgets during spec-writing, not after a beta tester complains. This means a mobile PM needs working literacy in the handful of metrics that actually predict user-perceived quality, and the discipline to write them down as acceptance criteria alongside functional requirements — the same discipline covered in the mobile PM role complete guide.

Performance Budgets Are Just Another Acceptance Criterion

Think of a performance budget the way you'd think of a functional spec: "search results must return in under 500ms" is no different in kind from "search results must be sorted by relevance." Both are testable, both are things a QA engineer or CI pipeline can verify, and both belong in the same document.

The Core Metrics Every Mobile PM Should Know

Five metric families cover almost every performance complaint a mobile team will encounter: startup time, frame rendering, energy impact, network efficiency, and stability under load. You don't need to be able to profile a trace yourself, but you do need to know what "good" looks like for each one and why it matters to users.

Cold Start and Warm Start

Cold start is the time from tapping the icon (with the app not in memory) to interactive content on screen. Warm start is the same measurement when the app process is already alive but the activity/view needs recreating. Android's own engineering guidance treats cold start above roughly 5 seconds as a critical failure and flags anything above 2 seconds for optimization; iOS enforces this more bluntly by having the OS kill and log any launch that takes longer than 20 seconds ("watchdog" termination), which shows up as a crash in your dashboards even though nothing crashed.

• Cold start is what a new user experiences on first open — it directly affects activation and first impressions.
• Warm start dominates once you have engaged users switching back into your app dozens of times a day.
• Both should be measured on a mid-tier device, not the PM's flagship test phone — the median user's hardware is usually two to three years older.

Frame Rate and Jank

Modern phones render at 60, 90, or 120 frames per second, meaning each frame has a budget of roughly 16.7ms (at 60fps) to compute and draw. A janky frame is one that misses its deadline, causing visible stutter during scrolling or animation. Android's performance documentation defines the practical target as fewer than 1% of frames taking longer than the frame budget, with a harder ceiling on frames that take more than 700ms (perceived as a freeze).

Jank is disproportionately noticeable in exactly the moments that matter most for retention: onboarding animations, list scrolling, and transitions. It's also one of the easiest metrics to regress silently — a single unoptimized image decode or a synchronous database call added deep in a feature can tank scroll performance without anyone noticing until a user complains.

Energy Impact and Battery Drain

Battery drain is usually measured as percentage of battery consumed per hour of active use, plus — critically — drain while the app is backgrounded. Apple's App Store guidelines explicitly reserve the right to reject or flag apps with excessive background battery or data use, and both platforms surface per-app battery usage directly to users in system settings, making this a visible, comparison-shopping metric.

The sneaky version of this problem is background work: sync jobs, location polling, and push-triggered wake-ups that run when the user isn't even looking at the app. These rarely show up in a QA pass because testers actively use the app during testing — they need dedicated instrumentation to catch.

Network Efficiency

Every unnecessary network call costs battery (radio wake-up is one of the most energy-expensive operations a phone performs), data (relevant on metered or international plans), and latency. Network efficiency budgets typically track total bytes transferred per session, number of discrete network requests, and whether requests are batched versus fired individually.

App-Not-Responding (ANR) and Crash Rates

An ANR (App Not Responding) fires on Android when the main thread is blocked for 5+ seconds during input handling, or 10+ seconds during a broadcast receiver. Google's Play Console vitals dashboard flags apps whose ANR rate exceeds roughly 0.47% of daily active users as "poor behavior," which can affect store visibility and search ranking. iOS has an analogous "hang rate" surfaced in Xcode Organizer and MetricKit reports.

Unlike a crash, an ANR is often not implicated in the offending code path itself — it's a symptom of something upstream blocking the thread the UI needs. That makes it a good proxy metric for overall app health rather than a single bug.

A Concrete Performance Budget Table

Numbers anchor conversations that otherwise stay vague ("make it feel fast"). Below is a starting-point budget table; treat the exact thresholds as a baseline to adjust per app category, not gospel.

Budgets Should Vary by App Category

A photo-editing app doing on-device ML inference will legitimately consume more battery and CPU than a to-do list app — don't force one universal budget across an unrelated product portfolio. Set the budget relative to your closest competitive benchmark and your own historical baseline, then hold the line once it's set.

Writing a "Performance Regression Is a Bug" Policy

The single highest-leverage move a mobile PM can make is turning performance budgets from aspirational documentation into a release gate. A performance regression is a bug — full stop — with the same severity classification, the same triage process, and the same ability to block a release as a functional defect.

1. Baseline every budget metric in CI or a nightly build against a fixed reference device before any feature work starts.
2. Fail the build (or flag the PR) when a change moves cold start, jank rate, ANR rate, or battery drain beyond the budget threshold.
3. Attribute the regression to the specific commit or feature, not a vague "performance got worse this sprint."
4. Triage it in the same backlog as functional bugs, with severity tied to user impact, not engineering convenience.
5. Report budget status in every release readiness review, next to crash-free rate and functional test pass rate.

Without this policy, performance decays through a thousand small, individually-justified additions — one more analytics SDK, one more background listener, one more synchronous layout pass — until the app feels sluggish and nobody can point to a single change that caused it.

The Background-Sync Cautionary Tale

Imagine a team ships a feature that syncs user content in the background every 15 minutes to make the app feel "always fresh." Individually reasonable. In testing, nobody notices anything — testers have the app open, phones on chargers, and short test sessions.

In production, aggregated telemetry shows background battery drain has tripled and a wave of 1-star reviews mentions battery specifically. The feature works exactly as designed and is quietly the single biggest driver of uninstalls that quarter, because nobody wrote a battery budget into the spec and nobody instrumented background energy use before launch. This is precisely the kind of NFR that a living spec with readiness gates exists to catch — which is the direction Prodinja's Spec Studio takes: it lets you write explicit performance and battery budget sections as first-class parts of the PRD, alongside functional acceptance criteria, rather than leaving them as tribal knowledge one engineer remembers to check.

Instrumenting and Communicating Budgets Across the Team

Budgets are worthless if only the PM knows they exist. Make them visible where engineering, QA, and design already look: dashboards, PR templates, and the spec itself.

• Dashboards: Surface cold start, jank rate, ANR rate, and battery drain from Android Vitals / Xcode Organizer / MetricKit in a shared, always-on dashboard — not a report someone runs manually before a release.
• PR templates: Add a checklist item asking whether the change touches background work, network calls, or rendering paths, and whether budget impact was measured.
• Spec documents: Write the budget as a numbered acceptance criterion, not a footnote — "Feature must not increase cold start by more than 50ms" is testable; "should be fast" is not.
• Design reviews: Loop performance into the same conversation as platform conventions, the way teams already weigh iOS HIG versus Material Design tradeoffs — a heavy custom animation has both a design cost and a jank cost.
• Release readiness: Include budget status alongside App Store review timing in the release checklist, since a rejected or flagged build over battery use can delay the whole release train.

How Performance Budgets Connect to the Rest of the Product

Performance isn't an isolated engineering silo — it interacts with permissions, retention, and the broader user journey. A background-sync feature that drains battery is often the same feature that also needs a permission prompt, which ties directly into how you frame push notification permission requests and user trust — asking for background access without demonstrating restraint on battery use erodes the same trust budget.

Similarly, performance budgets should map to the moments that matter most in the customer journey — cold start matters most at first open, jank matters most during core-loop interactions, and background battery drain matters most in the quiet moments when trust is either reinforced or quietly broken. Understanding which job the user is hiring your app to do, per Jobs to Be Done, also tells you which performance dimension to protect most fiercely — a navigation app cannot compromise on GPS/battery efficiency the way a note-taking app can.

Key Takeaways

• Treat cold start, warm start, jank, battery drain, network efficiency, and ANR rate as product requirements with numeric budgets, not vague engineering aspirations.
• Target roughly: cold start under 2s, jank under 1% of frames, active battery drain under 2-3%/hour, background drain under 1%/hour, and ANR rate under 0.47% of daily active users.
• Adopt a "performance regression is a bug" policy — budget violations should block releases the same way functional defects do.
• Instrument background work specifically; it's the most common source of silent battery drain that testers miss because they actively use the app during QA.
• Write performance and battery budgets directly into the spec as testable acceptance criteria, and review them at every release readiness gate alongside crash-free rate.