Imagine sending an important message to a family member just as your internet connection drops. Your messaging app appears to have accepted it, but you cannot tell whether it has reached anyone. If this happens repeatedly, would adding more features improve your experience?
This seemingly simple situation exposes a difficult product design question: how do you build a product that works beyond ideal conditions?
The interview question and what it actually tests
The first question in the 1,000 Product Manager interview series asks:
“Design a product that you use every day for someone with limited access.”
The prompt deliberately leaves several things undefined. It does not specify the product, the user group or even the kind of access limitation involved.
That ambiguity is part of the assessment.
The interviewer wants to see whether you can define a meaningful problem, identify a particular group of users, choose between competing solutions and propose a credible way to evaluate your decision.
A strong answer is not a catalogue of imaginative features. It explains why a particular problem deserves attention, which alternatives have been rejected and what evidence would justify changing course.
First, define what limited access means
A common mistake is to interpret limited access immediately as either disability or unreliable internet.
In practice, several different constraints may be involved.
- Technical constraints: Unreliable connectivity, older devices, limited storage or poor battery life.
- Physical or sensory constraints: Difficulties with vision, hearing, movement or precise motor control.
- Financial constraints: The cost of connectivity, hardware or subscriptions.
- Digital literacy constraints: Limited familiarity with technology or difficulty understanding the interface language.
- Situational constraints: Using a product while travelling, in a noisy environment or with limited access to a device.
These groups do not necessarily need the same solution.
Increasing button sizes may help somebody with reduced dexterity. It will not, by itself, solve a failed message delivery caused by an intermittent connection.
The Product Manager's first decision is therefore not which feature to build. It is which problem to solve.
In an interview, I would clarify what the interviewer means by limited access. If they deliberately leave the definition open, I would state a reasonable assumption and proceed.
Choose one everyday product and one specific group
For this exercise, I will choose a mobile messaging application.
My assumed target group is people using relatively inexpensive smartphones who regularly experience weak or intermittent internet connectivity.
This is not a claim that their needs are more important than those of other groups. It is a deliberate narrowing of the problem so that we can make a testable decision.
The next question is what these users are trying to achieve.
Do they need video calls, file sharing or large group conversations?
For an initial investigation, I would focus on one fundamental job:
Sending a short text message and knowing its actual delivery status.
A preliminary problem statement might be:
“People with unreliable connectivity cannot consistently tell whether a message has been saved, is waiting to send or has genuinely reached its destination.”
That statement is still a hypothesis, not a research finding.
We would need to investigate users' existing behaviour, understand how often the problem occurs and establish whether its consequences are significant enough to justify investment.
Separate the underlying need from a feature request
Suppose users tell us, “We want messaging to work without the internet.”
It would be tempting to interpret this as a request for a fully offline messaging application. But that may be considerably more than they actually need.
Instead, I would ask:
- At which point in the messaging journey does connectivity usually fail?
- Is the main difficulty composing the message, sending it or understanding its status?
- Do people resend messages because they cannot tell whether the first attempt succeeded?
- What workaround do they use today?
- Which delays are acceptable, and which situations require immediate confirmation?
Observing behaviour matters as much as collecting opinions.
If people repeatedly tap Send after losing connectivity, the problem may primarily be unclear feedback.
If messages disappear when the application reconnects, however, better wording will not solve the underlying reliability defect.
Two problems that look similar from the user's perspective may require entirely different product decisions.
Compare credible solutions before choosing one
There are at least three approaches worth considering.
Option one: Build a separate lightweight application
A dedicated version could minimise data consumption, reduce memory requirements and provide a simpler experience for less capable devices.
That offers considerable scope for optimisation.
The drawback is the potential cost of maintaining and testing two applications, alongside the fragmentation of the user experience.
Without strong evidence that the need is sufficiently widespread, this would be a substantial commitment to an unproven solution.
Option two: Improve the existing message-sending journey
Rather than creating another product, we could make the core messaging interaction more dependable.
For example, the application could:
- Save composed messages securely on the device before attempting transmission.
- Clearly distinguish messages waiting for connectivity from those successfully transmitted.
- Retry appropriately once connectivity returns.
- Differentiate between pending, accepted by the server, delivered and failed states.
- Prioritise text and reduce unnecessary automatic downloads of large attachments.
This direction is consistent with offline-first principles described in Android's official architecture guidance. Such systems preserve essential local functionality instead of assuming that a network connection is always available.
However, offline persistence and retries introduce engineering responsibilities. The team must address local data protection, privacy, duplicate prevention, authentication, retry behaviour and error recovery.
Option three: Offer an alternative channel such as SMS
A further possibility is to use text messaging when internet connectivity is unavailable.
This might be valuable in specific circumstances, but it raises questions about user consent, cost, security and operational feasibility.
It would also be inappropriate to imply that a standard messaging application can guarantee emergency or time-critical communications.
Which approach would I recommend?
If the evidence supports our initial hypothesis — that unreliable connections and ambiguous delivery feedback are the main barriers — I would start with option two.
It targets a smaller, more precisely defined problem. It can be tested within the existing product and should provide useful evidence before the organisation commits to a separate application.
If research instead reveals that storage, processing power or the cost of data is the dominant constraint, a lightweight product may become the better investment.
The recommendation depends on the evidence, not a preference for a particular architecture.
A hypothetical software-product scenario
Consider a hypothetical messaging company whose product team notices repeated sending attempts among users in areas with unreliable connectivity.
At this stage, the team does not know what causes the behaviour.
Perhaps messages never reach the server. Perhaps they arrive successfully but their status updates are delayed. Perhaps users do not understand the existing status indicators.
The Product Manager works with a UX designer, mobile and backend engineers, and customer support to investigate three sources of evidence: technical error records, observed task completion and interviews about users' actual experience.
The team then designs a limited prototype that preserves messages through a connection failure and provides clearer feedback.
During testing, network access is deliberately interrupted and restored.
Participants must compose a short message, understand what has happened to it and verify its status after the connection returns.
Automated retries alone would not prove success. If users still cannot distinguish pending from delivered messages, an important part of the original problem remains unresolved.
Accessibility also matters. Critical feedback should not depend exclusively on colour or an ambiguous symbol. W3C's WCAG 2.2 guidance on status messages explains how status changes in web content can be made available to assistive technologies.
This is an illustrative scenario, not a description of an actual company's product results.
Define success around the user's outcome
Another common mistake is to measure success purely through daily active users or the total number of messages sent.
Those numbers may be useful, but they do not establish whether the experience has improved for people with unreliable connectivity.
I would use three levels of measurement.
Outcome metric
The proportion of eligible message-sending attempts in the target cohort that are successfully accepted by the server within a defined period after connectivity returns, with an accurate and understandable status shown to the user.
The denominator should include all eligible attempts in the experiment, not merely those that already succeeded.
The observation period must be agreed before testing. A 24-hour window after reconnection, for instance, might be an initial experimental assumption rather than a universal benchmark.
Diagnostic metrics
Useful diagnostic measures include manual retry frequency, time spent in the sending queue, synchronisation failures and participants' ability to interpret message states correctly during usability testing.
These measures help explain why the outcome changes.
Guardrail metrics
We should also monitor duplicate messages, data and battery consumption, message loss, security defects and any deterioration experienced by users with reliable connectivity.
An increase in the number of messages recorded is not automatically positive; some of that increase could represent accidental duplicates.
We must also distinguish server acceptance from recipient delivery. The interface should never claim a message has been delivered before the relevant confirmation exists.
What if you have only two weeks?
This is one of the original follow-up questions attached to the interview prompt.
With only two weeks available, the objective would be to reduce uncertainty, not to build a complete alternative product.
During the first week, I would define the target cohort, conduct focused interviews and observed task tests, review relevant error data and develop a lightweight prototype of clearer message states.
During the second week, I would test the prototype with people in the target group under unreliable network conditions. I would assess whether they understand message status while engineers investigate the feasibility of local persistence and reliable retries.
The decision at the end of the fortnight should be whether the problem and proposed improvement merit further investment, or whether the team needs more evidence or a different direction.
What evidence would make you reject your solution?
This is the second follow-up question in the source material, and it tests an essential product management skill.
A convincing candidate should be able not only to defend a decision but also to identify the evidence that would invalidate it.
Suppose usability research shows that people already understand delivery states, while their real difficulty is repeated application crashes caused by insufficient storage. Our proposed solution would be incomplete.
If automatic retries create duplicate messages or data loss, improved feedback would not justify shipping the design.
Or suppose research demonstrates that most affected users cannot afford the data needed to launch the application at all. Improving send-state feedback would no longer be the first priority.
Each finding would require us to reconsider the original hypothesis.
An example of a natural interview answer
A candidate could bring these ideas together in a spoken response like this:
“I'd start by clarifying what limited access means, because unreliable internet, an older device and a physical accessibility need would lead me towards different problems.
For this example, I'll choose a messaging app and focus on people who regularly experience poor connectivity.
Rather than immediately building a separate lightweight app, I'd find out which part of their main task is failing. My initial hypothesis is that sending a short message and knowing whether it has actually arrived is a significant problem.
I'd validate that through user observation, interviews and relevant error data. If the evidence supports it, I'd test a smaller improvement: saving messages securely, retrying after reconnection and making delivery states clearer.
I'd measure whether users can complete that task and correctly understand what happened, while monitoring duplicates, data use and security issues.
If the evidence points instead to affordability or device performance as the main barrier, I'd change direction. I'm trying to solve a real user problem with proportionate effort and risk, not simply deliver more features.”
This demonstrates the complete reasoning process, from framing and evidence gathering to prioritisation, experimentation and revision.
What makes an answer weak?
“I'd create a simpler version for everyone.”
This fails to identify a specific user group or access limitation. A simpler interface does not necessarily address unreliable connectivity.
“I'd make every feature work offline.”
This ignores feasibility, cost and the difference between activities that can be performed locally and those requiring remote confirmation or interaction with another person.
“I'd measure success through an increase in active users.”
That metric does not directly demonstrate that the target users can send messages more reliably. Overall activity could increase without any improvement in the problem we set out to solve.
“This is clearly the best solution.”
Excessive certainty before research or testing is not persuasive product judgement. A stronger answer explains its assumptions, limitations and the conditions under which the recommendation would change.
Conclusion
Designing an everyday product for someone with limited access begins with identifying whose access is limited, in what way and during which task. A single solution cannot adequately address every technical, physical, economic or situational constraint. The Product Manager must select a meaningful problem, examine existing behaviour and compare solutions in terms of value, cost, uncertainty and risk.
In our messaging example, improving the existing sending journey is an appropriate first step if the dominant problem is intermittent connectivity and unclear message status. Building a separate application is not automatically justified. If subsequent evidence identifies a different primary barrier, the decision should change accordingly.
The strongest Product Manager is not the person with a ready-made solution for every user. It is the person who can identify which user's problem deserves solving, justify the decision and recognise when the evidence calls for a different approach.
Sources
- Reforge — 7 Product Manager Interview Questions From Top Product Leaders — Context on reasoning and assumptions in scenario-based interviews; not evidence that this precise question came from a particular official interview.
- Android Developers — Build an Offline-first App — Official guidance on local data, operation queues and synchronisation.
- W3C — WCAG 2.2: Understanding Status Messages — Accessibility requirements concerning status announcements in web content.
