Imagine someone listening to a podcast on their daily commute. Their internet connection drops for a few seconds, playback stops, and the app fails to resume properly when connectivity returns. After several attempts, they give up and close it.
The product team decides to improve the experience for users with unreliable connections. One colleague suggests offline downloads, another proposes lowering streaming quality, and the designer recommends making the home screen lighter.
All three ideas could be useful. But which one actually solves the user's most important problem?
That is the product judgement behind the eleventh question in this interview series.
What Is the Interview Question?
Which part of a content app would you redesign for users who have unstable internet?
On the surface, this looks like a user interface design question. In practice, the interviewer is testing whether a candidate can make a defensible product decision under uncertainty.
A strong answer should demonstrate the ability to:
- Distinguish the underlying user problem from proposed features.
- Identify a particular user segment and its most important need.
- Compare possible solutions against value, cost and risk.
- Make a decision that can be tested and revised.
- Measure success through meaningful user behaviour rather than feature delivery.
A weak candidate starts by listing features. A stronger candidate first asks where, why and how users are prevented from accomplishing their intended task.
1. Understand What Unreliable Internet Actually Prevents
An unstable connection does not create the same problem for every content consumer.
Someone reading an article might struggle with missing images or a page that repeatedly reloads. A video viewer may experience constant buffering. For a podcast listener, losing playback position or being unable to resume may be more frustrating than waiting a few extra seconds.
The network conditions themselves also vary. Some users have consistently low bandwidth, some experience brief interruptions, and others appear to be connected despite making almost no progress downloading data.
Before deciding what to redesign, I would establish four things.
Who are the users? Are they frequent listeners, first-time visitors or people who primarily use the product while travelling?
What are they trying to accomplish? Reading an article, listening to an episode, watching a video or saving something for later?
Where does their journey break down? During discovery, search, initial loading, playback, navigation or returning to the app?
What constraints apply? Development capacity, device storage, data costs, content licensing and the product's existing technical architecture?
Without answers to these questions, selecting a screen to redesign is largely guesswork.
2. Choose a Specific User Segment Rather Than Designing for Everyone
Suppose we are working on an app offering podcasts and video content, with a substantial proportion of listening taking place over mobile networks.
I would initially focus on active listeners who consume audio during their commute and regularly experience intermittent connectivity.
This does not mean other users are unimportant. It means we are selecting a clearly defined problem that can be investigated and addressed.
Three criteria help establish whether this segment deserves priority.
Severity: Does the connection issue cause a minor delay, or does it prevent the listener from completing their task?
Frequency: How often does it happen during a session or across a typical week?
Existing workarounds: Do people wait, restart playback, change quality settings or abandon the app altogether?
To understand these behaviours, I would combine product analytics with observation and user interviews.
Playback interruptions, retries and exits are useful signals, but they do not automatically explain why someone stopped listening.
A person might leave because their train has reached its destination or because they deliberately want to finish the episode later.
That distinction matters. Not every abandoned session represents a technical failure.
3. Which Part of the Product Should We Redesign?
If early evidence indicates that interruptions are concentrated during content consumption, I would prioritise the playback and content-resumption experience, rather than redesigning the entire home screen.
There are three credible approaches to consider.
Option A: Reduce Interface Weight and Loading Requirements
We could defer non-essential images, reduce network requests and prioritise essential text or previously stored content.
This would be particularly useful if people encounter blank screens, unsuccessful searches or excessive waiting before reaching the content.
However, if the principal frustration is an interruption halfway through a podcast, making the home screen lighter may have little effect on the core problem.
Option B: Make Playback More Resilient
This approach concentrates on continuity when the network becomes unreliable.
Possible improvements include:
- Reliably preserving playback position and resuming from the correct point.
- Retrying failed requests in a controlled manner without creating endless loops.
- Explaining whether the player is reconnecting, waiting or using previously stored content.
- Adjusting media quality where the streaming format supports it.
- Preserving the current playback state when users navigate between screens.
This is especially relevant when connectivity fluctuates but is not absent for extended periods.
Apple's official documentation explains that HTTP Live Streaming (HLS) supports alternative media streams at different bitrates, allowing compatible players to respond to changing network conditions.
However, this capability depends on suitable media preparation, distribution infrastructure and player implementation. It is not something a designer can enable simply by changing a button.
Option C: Introduce an Offline Consumption Experience
If users regularly travel through areas without coverage, making online playback more reliable may not be enough.
In that case, I would consider selective downloads, saved-content management, download progress indicators and the ability to resume interrupted transfers.
Nevertheless, offline functionality involves considerably more than adding a download button.
The team must decide how long downloaded content remains available, how incomplete files are handled, what storage limits apply, whether licensing permits downloads and how playback progress is synchronised when connectivity returns.
An offline-first architecture does not necessarily mean every feature must function without internet access. Rather, the product should preserve its most important functions whenever practical.
The official Android offline-first guidance and Google's documentation on offline data storage describe the technical considerations behind this approach.
My Initial Decision
Assuming the main problem is short network interruptions during playback, I would prioritise Option B.
I would first make playback recovery reliable. If subsequent evidence showed that users were regularly disconnected for long periods, offline downloads would become a stronger candidate for the next investment.
This strikes a reasonable balance between immediate user value, engineering complexity and speed of learning.
However, if investigation revealed that users could not discover or open content in the first place, I would change the priority to content discovery, search or initial loading.
The choice depends on the evidence, not on a universal rule about which screen matters most.
4. A Hypothetical Software Product Example
Hypothetical scenario: Consider an audio-content application called Ava.
The support team receives complaints that listeners lose part of their podcast experience when travelling through tunnels or switching between mobile networks.
These reports do not yet prove that poor connectivity is the root cause. Player defects, server-side issues or unreliable playback-position storage could produce similar symptoms.
The Product Manager works with an analyst, designer and engineers to examine the journey from episode selection through playback, interruption, recovery and potential abandonment.
Customer support categorises recurring problems, while engineers reproduce slow connections and temporary outages in a controlled environment.
For this example, assume the preliminary investigation finds that brief interruptions sometimes lead to prolonged playback failures and lost listening positions.
The team now has two realistic approaches.
Approach A: Improve playback behaviour by preserving listening position, introducing controlled retries, restoring player state and displaying clear recovery messages.
Approach B: Build an offline download system, including file management, storage controls and synchronisation.
Approach B could deliver greater value to people who remain disconnected for extended periods. However, it would probably require more engineering and maintenance effort. The team would also need to consider distribution rights, stored-file security and device storage consumption.
For the specific assumptions in this scenario, Approach A is a better starting point.
The team tests a limited implementation under simulated network conditions before exposing it to a small group of real users.
If playback recovery improves but people still fail to consume content because they spend long periods offline, investment in downloads becomes easier to justify.
The initial decision is not a permanent commitment to one solution.
5. How Would We Measure Success?
Counting downloads or visits to the player screen could create a misleading impression of improvement.
For this problem, I would define three types of measures.
Outcome Metric: Successful Content Consumption
We could measure the proportion of eligible playback sessions in which listeners consume a meaningful amount of their intended content without technical failure.
For example, a team might provisionally define success for a particular episode type as reaching 80% of its duration.
That threshold would need justification and validation. It is not a universal standard.
The denominator should be eligible sessions in which playback actually started, rather than every user who installed the application.
Results should also be segmented by connectivity conditions so improvements for stable-network users do not hide continuing failures elsewhere.
Diagnostic Metrics: Understanding Interruptions
Useful measures include involuntary playback stalls, time to recovery after an interruption and the proportion of recoveries that succeed.
Where possible, the team should distinguish deliberate pauses from technically induced interruptions.
This helps explain whether changes in the outcome metric genuinely reflect a better experience.
Guardrail Metrics: Cost and Quality
An improvement is questionable if it introduces substantial harm elsewhere.
Relevant guardrails might include mobile data consumption per successfully played minute, battery usage, device storage, application errors and the business's data-delivery costs.
For instance, a player might recover more reliably while generating repeated network requests that significantly increase users' data consumption.
That would require further investigation rather than an automatic declaration of success.
Before running an experiment, I would agree the baseline, observation window, decision criteria and rollback conditions. A possible approach would be to compare eligible sessions in a controlled rollout against a comparison group over a two-week period.
The measurement plan must be established before interpreting the results.
6. An Overlooked Risk: Synchronisation and User Trust
Imagine someone listens to part of an episode offline while a different playback position is recorded on another device.
When connectivity returns, which position should the application preserve?
If the system blindly replaces one record with another, the user may lose their place.
Similar conflicts can occur with bookmarks, incomplete downloads and listened-status updates.
This makes local storage and synchronisation product concerns, not merely implementation details.
The Product Manager and engineering team must agree how the product should resolve conflicts, which state matters to the user and how any uncertainty should be communicated.
The Android offline-first guidance discusses local data sources, synchronisation and conflict-resolution strategies.
For web applications, we must also avoid assuming that every background synchronisation feature is universally available.
MDN identifies the Background Synchronization API as having limited browser availability. A dependable web solution therefore needs an alternative, such as synchronising when the application is opened again.
7. A Natural Interview Answer
Example spoken answer from a candidate:
"Before choosing a particular area to redesign, I'd want to understand exactly where users are struggling. An unstable connection can affect search, page loading and content playback in very different ways.
"If we assume this is a podcast app and the main problem is brief interruptions during commuting, I'd start with the playback experience.
"I'd look at how often playback stops unexpectedly, how long recovery takes and whether users lose their listening position.
"Then I'd compare a few possible solutions, such as automatic playback recovery, adaptive quality and offline downloads.
"Given those assumptions, I'd probably start with a small improvement to playback-state preservation and recovery, then test it with a limited group.
"My main success measure would be successful content consumption, supported by interruption duration, data usage and error rates.
"If the evidence showed that users were mostly offline for long periods, or that most failures happened before playback started, I'd change my priority.
"I wouldn't want to commit to a particular feature before understanding which problem it actually solves."
This response makes a decision without pretending that the available information is complete. It also explains what evidence would justify changing direction.
8. Interview Follow-up Questions
What Would You Do if You Had Only Two Weeks to Figure It Out?
This is one of the two follow-up questions in the original Q0011 reference.
With two weeks available, I would not attempt to build a comprehensive offline platform.
Instead, I would aim to reduce the most consequential uncertainty at the lowest reasonable cost.
During the opening days, I would review playback events and support reports, speak to a small number of affected users and reproduce failures under poor network conditions.
Next, I would prototype or implement one narrowly scoped improvement, such as reliable playback-position preservation and recovery after a brief disconnection.
At the end of the period, the team would compare its observations with the baseline and decide whether to continue, revise or reject the proposed approach.
The most valuable output of those two weeks may be a better-supported decision, not a fully released feature.
What Evidence Would Make You Reject Your Proposed Solution?
This is the second follow-up in the original reference.
If most affected users abandoned the product before reaching the player, playback redesign would be the wrong priority.
If the predominant problem were extended periods without connectivity, short-interruption recovery would not adequately address their needs.
I would also reconsider the approach if an experiment showed no meaningful improvement in successful consumption, or if data usage and technical errors increased unacceptably.
Being prepared to reject one's own proposal is an important part of sound product judgement.
9. Common Mistakes to Avoid
Starting with features instead of the problem. Saying "I'd add offline downloads" without establishing where the user journey fails demonstrates premature solution selection.
Designing for everybody. An article reader, podcast listener and live-video viewer have different needs. A strong response identifies which group should come first and why.
Confusing connectivity with successful usage. A device showing an internet connection does not guarantee that media can load or play reliably.
Relying on vanity metrics. More downloads or playback starts do not establish that users are successfully consuming content or having a better experience.
Ignoring costs and constraints. Offline storage introduces licensing, storage and synchronisation issues. Automatic retries can also increase data consumption.
Displaying unjustified certainty. A Product Manager should state the assumptions behind a recommendation and what would change it, rather than treating an untested feature as the obvious answer.
It is also useful to distinguish responsibilities. The Product Manager focuses on the user problem, desired outcomes and product decision, working with designers and engineers on feasible solutions. In Scrum, the Product Owner is accountable for maximising product value and effective Product Backlog management. A Project Manager, where the organisation uses that role, is more concerned with coordinating delivery within agreed project constraints. Exact responsibilities depend on the organisation.
Conclusion
If I had to select one part of a content application to redesign for users with unstable internet, I would initially choose playback and content resumption, provided the evidence showed that interruptions occurred primarily during consumption.
Preserving playback position, recovering gracefully after disconnections and communicating system status clearly would offer a focused, testable starting point.
That decision would change if users could not reach their content in the first place, in which case discovery and loading would deserve priority. If users spent extended periods disconnected, offline downloads would become more important.
The strength of a Product Manager's interview answer does not lie in how many features they can suggest. It lies in showing whose problem they are solving, why they chose it, what evidence supports the decision and which trade-offs they are prepared to accept.
Sources
- Android Developers — Build an offline-first app
- Apple Developer — HTTP Live Streaming
- web.dev — Offline data
- MDN — Background Synchronization API
- Reforge — Product Manager Interview Questions
The main question and two follow-ups are taken from Q0011 in the educational 1,000 Product Manager interview-question collection.
Ava is a hypothetical example. The technical references support the discussion of implementation options.
The Reforge article addresses Product Manager interview assessment practices; it does not establish that this exact question was asked by any particular company.
