Imagine a hypothetical working morning. One parent's meeting overruns, their child's after-school activity finishes earlier than expected, and neither parent is entirely sure who is responsible for collection.
Both parents already have calendars, messaging apps and reminders. Yet the family's schedule is still difficult to coordinate.
Perhaps another calendar is not what they need.
The real problem may be that information is scattered across different people and tools, leaving nobody with a reliable picture of responsibilities and last-minute changes.
That leads to a more interesting product decision: Should we build another planning tool, or make it easier for family members to coordinate their everyday responsibilities?
The third Product Manager interview question
Define a product to help working parents with daily planning.
This is a product sense and design question. It tests more than your ability to propose an app.
An interviewer wants to understand whether you can identify a meaningful user problem, select a sensible target segment, evaluate possible solutions and explain how you would validate your recommendation.
A strong answer demonstrates that you can:
- Identify a particular group of users rather than treating all working parents as identical.
- Distinguish underlying needs from requested features.
- Compare options using value, effort, risk and evidence.
- Propose a small, testable first version.
- Measure meaningful improvements rather than feature usage alone.
A weak answer often begins with a feature list: shared calendars, reminders, AI assistants, task management and integrations.
The difficulty is that none of those features tells us what problem we are actually solving.
1. Start by narrowing the problem
Working parents are not a single homogeneous user group.
A single parent working shifts may face different challenges from a household where two adults have regular working hours. The child's age, availability of other carers, working arrangements and access to technology also matter.
Before designing anything, I would clarify five questions:
- Which working parents are we designing for?
- Is their main difficulty individual time management or coordinating family responsibilities?
- What tools and workarounds do they currently use?
- Which situations cause the most disruption?
- What outcome matters most: less planning time, fewer missed commitments or reduced mental effort?
If the interviewer provides no additional constraints, I would state a working assumption.
Working assumption: We are designing for households with two working parents and at least one primary-school-aged child, where coordinating shared responsibilities and unexpected changes is difficult.
This does not imply that other families are less important. It simply gives us a specific starting point for discovery and an initial product.
2. Discover the need through actual behaviour
Instead of asking parents which features they would like, I would investigate situations they have already experienced.
Useful questions include:
- When was the last time your family schedule went wrong?
- How did you discover that something had been missed?
- Who was responsible for coordinating the change?
- How many messages or calls were needed to resolve it?
- Which part required the most effort?
We should look beyond forgotten tasks to the mental load of coordination: remembering commitments, anticipating problems, checking responsibilities and ensuring other people have the right information.
A task may be completed on time while still requiring repeated follow-ups from one parent.
Measuring only whether the task was completed would miss that burden.
The GOV.UK user research guidance offers a useful general principle: understand how people currently achieve their goals and what difficulties they encounter before deciding what to build.
How would I conduct the research?
I would combine interviews with a short diary study.
For an initial exploratory exercise, I might interview around eight to twelve households from the target segment, asking some participants to keep brief records of coordination difficulties over a week.
Those numbers are a proposed research design, not a statistically representative sample or a universal research rule.
A diary study is particularly useful because planning problems emerge over time. Last-minute changes, repeated reminders and informal workarounds may be difficult to reconstruct accurately in a single interview.
I would also explore existing solutions: shared calendars, messaging groups, paper notes and people's own memory.
If existing tools already solve the problem satisfactorily, a standalone app may not be justified.
3. What product should we design?
Suppose our early research suggests that the principal difficulty is not recording events, but assigning responsibility and coordinating changes.
We could consider three approaches.
Option A: A comprehensive family calendar
Each family member enters their commitments into a shared calendar.
This has a familiar interaction model and may improve visibility.
However, families may already use calendars. Another one could create duplicate work without making responsibility any clearer.
Option B: An AI-powered planning assistant
An assistant could identify scheduling conflicts, suggest changes and recommend how responsibilities might be allocated.
This could be valuable if the necessary information is available and the recommendations are trustworthy.
However, it introduces integration complexity, personal-data risks, the possibility of incorrect suggestions and a greater need for user trust.
We have not yet established that sophisticated automation is necessary.
Option C: A lightweight shared daily plan
This approach focuses on three questions:
What needs to happen today? Who owns each responsibility? Who needs to know when something changes?
For our stated assumption, I would begin with this third option.
It addresses an identifiable coordination problem without attempting to replace every existing calendar or productivity tool.
Importantly, it is a provisional recommendation. If research identifies a different primary need, the product direction should change.
4. Define a focused minimum viable product
The MVP should test the central value proposition with as little unnecessary complexity as possible.
I would prioritise five capabilities.
A shared view of today: Family members can see essential commitments, relevant times and the responsible adult.
Clear ownership: Responsibilities can be assigned, acknowledged or reassigned when circumstances change.
Quick changes: Users can update a commitment or request that somebody else takes responsibility.
Relevant notifications: Only meaningful changes requiring awareness or action trigger an alert.
A brief daily check-in: Family members can review essential plans without navigating several complicated screens.
I would deliberately postpone advanced AI recommendations, extensive integrations, household budgeting and continuous location tracking.
Those features might eventually become useful, but including them immediately would increase development cost and obscure the question we are trying to answer.
Avoid creating another chore
There is an important design constraint.
If entering each family commitment requires several forms and repeated manual updates, the product intended to reduce mental effort could instead increase it.
Quick entry, simple editing and minimal duplication are therefore core product requirements, not merely interface refinements.
The design also needs to accommodate households where only one parent initially manages the plan, without automatically transferring every coordination responsibility to that person.
5. A hypothetical software-product example
Hypothetical scenario:
A product team is exploring a daily coordination service for working parents with primary-school-aged children.
Suppose exploratory interviews suggest that difficulties most often arise when school arrangements or working schedules change unexpectedly.
For example, one parent agrees to take their child to an activity, but a work meeting overruns. They send a message to the other parent, who does not notice it amongst unrelated conversations.
The team creates two prototypes.
- Prototype A offers a shared calendar displaying family events.
- Prototype B offers a daily plan with an assigned owner and a simple responsibility-transfer action.
During moderated usability testing, participants must handle a simulated last-minute change.
The team observes whether both adults understand who is now responsible, whether the change has been acknowledged and how much effort the interaction requires.
This test cannot establish long-term product success. It can only indicate which design better supports a specific task under test conditions.
The preferred approach would therefore need a further trial in everyday family life.
If families continue to coordinate more effectively through their existing messaging apps, we should investigate why rather than assuming they need stronger encouragement to adopt our product.
6. How would we measure success?
Downloads, daily active users and the number of recorded tasks are not sufficient measures of success.
A household might record dozens of activities and still experience the same coordination difficulties.
We need an outcome metric, diagnostic measures and guardrails.
Primary outcome: Successful coordination
Successful coordination rate = Planned shared responsibilities completed at the expected time without unresolved coordination problems ÷ All planned shared responsibilities.
Before using this measure, we need consistent definitions of a shared responsibility, successful completion and an unresolved coordination problem.
In a proposed four-week pilot, we could combine product event data with lightweight household feedback.
Product analytics alone cannot verify that a real-world task was actually completed, so some self-reporting or other appropriate validation would be necessary.
Supporting measures could include:
- Time required to prepare the daily plan.
- Proportion of households in which more than one adult participates.
- Number of changes resolved without further calls or repeated follow-ups.
- Reported mental effort and satisfaction with coordination.
Guardrail metrics
We must also watch for unintended consequences.
Excessive notifications might increase apparent engagement whilst making the experience worse.
Other useful guardrails include abandonment, time spent entering information, perceived inequality in responsibility sharing, and unauthorised access incidents.
Without these checks, we could optimise product activity while delivering little improvement to families' everyday lives.
7. Risks and practical constraints
The first significant risk is multi-person adoption.
The product becomes less useful if only one family member participates. Worse, that person could end up managing another system on behalf of everyone else.
Inviting another adult should therefore be easy, and limited participation should not require complicated configuration.
The second risk concerns privacy.
Family schedules can reveal sensitive information about household routines, children's activities and when people are away from home.
For the first version, I would avoid child accounts and continuous location monitoring. Adults should understand what information is shared, with whom, and how to adjust permissions.
This approach aligns with the data minimisation principle explained by the UK's Information Commissioner's Office, although the actual legal obligations must be assessed for each target market.
The third risk is behavioural rather than technical.
Families may be comfortable with their existing messaging and calendar habits. A new product must deliver enough additional value to justify changing those habits.
8. Product Manager, Project Manager and Product Owner responsibilities
In this scenario, the Product Manager focuses on the user problem, target segment, product priorities, trade-offs and outcomes.
A Project Manager, where the role exists, typically concentrates on delivery planning, coordination, schedules and project constraints.
In a Scrum team, the Product Owner is accountable for maximising product value and effectively managing the Product Backlog, as described in the Scrum Guide.
These responsibilities can overlap or be held by one person in practice, but they are not conceptually identical.
For this interview, explaining how many sprints the MVP will take is not enough. We also need to explain why that MVP is worth building.
9. A natural interview answer
Here is how I would answer the question aloud:
"I'd start by narrowing down which working parents we're designing for and what part of daily planning is causing the most difficulty.
"For an initial assumption, I'd focus on households where both parents work and need to coordinate responsibilities around their children.
"I'd investigate how they manage things today, where coordination breaks down and what workarounds they use. Interviews and a short diary study would help me distinguish frequent problems from occasional frustrations.
"If the evidence suggests that unclear ownership and last-minute changes are the biggest problems, I'd propose a lightweight shared daily plan. Each important task would have a clear owner, with an easy way to acknowledge or change responsibility.
"I wouldn't start with advanced AI or a complicated set of integrations. I'd test a simple prototype first and then run a limited real-world trial.
"I'd judge success by whether families experience fewer coordination problems and spend less time and mental effort organising their day, rather than by the number of tasks they enter.
"If the evidence shows that existing tools work better, or that our product creates extra work, I'd change direction. That might mean building a complementary feature rather than another standalone app."
10. Two important interview follow-ups
What if you had only two weeks to investigate?
I would prioritise learning over delivery.
During the first few days, I would interview a small, relevant group of parents and collect examples of actual coordination difficulties.
I would then test two simple approaches using clickable prototypes or even a manually operated coordination process.
In the final days, I would evaluate task completion, effort and the practical barriers to adopting each approach.
The output would be an evidence-based decision to continue, revise or reject the hypothesis.
Two weeks would not be enough to demonstrate sustained retention or long-term outcomes, so I would avoid claiming that it was.
What evidence would make you reject your solution?
I would reconsider if coordination difficulties were infrequent or relatively unimportant to the target users.
I would also reject or substantially redesign the approach if families were unwilling to maintain a shared plan, if participation from both adults was impractical, or if the effort of using the product outweighed its benefits.
Finally, if usability tests looked promising but everyday trials failed to reduce coordination problems or mental effort, that would be a strong reason to revise the solution.
Changing direction in response to evidence is good product judgement, not inconsistency.
11. Common mistakes in answering this question
Designing for every family: This ignores meaningful differences in users' circumstances and makes the initial product unnecessarily broad.
Starting with features: A shared calendar or AI assistant is an untested solution until we understand the underlying need.
Treating engagement as the outcome: High usage does not prove that coordination has improved.
Ignoring existing habits: A system requiring duplicate entries may struggle to displace simple, familiar workarounds.
Expressing unjustified certainty: Declaring one design universally superior without evidence does not demonstrate strong product thinking. A credible answer explains when the recommendation is appropriate and what would change it.
Conclusion
To design a product that helps working parents with daily planning, I would begin with a clearly defined household segment and investigate the real causes of coordination difficulties, rather than immediately building another calendar.
If the evidence points to unclear responsibilities and last-minute changes, a lightweight shared daily plan with explicit ownership and targeted notifications is a sensible MVP.
Its value must then be demonstrated through improved coordination, reduced planning effort and manageable privacy and adoption risks. If the evidence contradicts the initial hypothesis, the right decision is to revise the solution rather than defend the feature set.
Good product management begins by understanding which problem is worth solving, not by deciding which features to build.
