Quick Answer
To answer a product improvement question, start by clarifying the goal, then identify the users, map their use cases, assess where the current product falls short, propose prioritised improvements, and wrap up with a clear recommendation. The key is to show structured thinking, not just feature ideas. Interviewers are scoring your process — how you define the problem — not just the quality of your suggestions.
What interviewers are actually scoring in a product improvement question
Most candidates arrive thinking the interviewer wants a clever feature idea. They do not. The interviewer is watching how you think, not what you invent.
Insight
A product improvement question is a structured problem-solving exercise disguised as a brainstorm. The interviewer scores the process, not the output.
This distinction matters especially for non-native English speakers. If you spend your mental energy searching for the 'right' feature in English, you will skip the clarifying questions and user analysis that actually earn the high score. A candidate who says 'I would add a dark mode' in fluent English scores lower than a candidate who says 'Before I suggest anything, I want to make sure I understand who is struggling and why' in imperfect English.
| What the interviewer asks | What they are actually measuring |
|---|---|
| How would you improve Google Maps? | Can you define the problem before jumping to solutions? |
| What would you change about Slack? | Do you think in users and use cases, not just features? |
| How would you improve our onboarding? | Can you prioritise and explain trade-offs? |
| What is your favourite product and why? | Do you think like a PM or like a user? |
Every product question is a test of structured thinking, not product knowledge.
If you want to understand how this framework connects to structuring any story-based answer in English, Mockly's guide on the STAR interview framework is worth reading first — the same principle of leading with context before jumping to action applies directly here.
| Scoring dimension | What a strong answer shows | What a weak answer shows |
|---|---|---|
| Problem definition | Asks clarifying questions before proposing anything | Jumps straight to features |
| User thinking | Names specific user segments and their distinct needs | Talks about 'users' as one undifferentiated group |
| Prioritisation | Explains why one improvement matters more than others | Lists features without ranking or reasoning |
| Communication | Signals transitions: 'Now that I've identified the users, let me look at pain points' | Talks continuously without structure markers |
| Trade-off awareness | Acknowledges what a change might break or cost | Treats every idea as obviously good |
Interviewers use these five dimensions whether or not they say so explicitly.
The 6-step framework for product improvement answers
This framework works for any product improvement question — whether you are asked about a consumer app, an enterprise tool, or a physical product. The steps are not a rigid script; they are a visible structure you announce to the interviewer so they can follow your thinking.
The 6 steps
- Clarify the goal — ask one or two questions before you begin. This signals you do not assume you know what the question is really asking.
- Announce your structure — tell the interviewer what you are about to do. This alone separates you from most candidates.
- Identify the users — name the distinct user segments, not just 'users'. Consider who else interacts with the product beyond the primary user.
- Map use cases — for each user segment, list the specific tasks they need to accomplish and the underlying goal behind each task.
- Identify pain points — go through the use cases and assess where the current product falls short. These gaps are your design space.
- Propose and prioritise improvements — name two or three ideas, tie each one explicitly to a pain point, and explain which you would build first and why.
Interview tip
After step 2, say your structure out loud: 'First I'll identify the users, then I'll look at their main use cases, then I'll find the biggest pain points, and finally I'll propose improvements.' This takes fifteen seconds and tells the interviewer you think in systems.
One thing most articles skip: step 1 is not just polite — it is a trap detector. A question like 'How would you improve a pen?' sounds trivial until you consider that the pen might be for astronauts, for children in a bathtub, or for people writing in permanent marker on fabric. The same logic applies to software. 'How would you improve our search?' could mean the internal search used by support agents, the customer-facing search on a website, or the API used by developers. Clarifying this before you answer is exactly what a good PM does on the job.
Watch Out
Do not ask more than two clarifying questions. One or two focused questions signal good judgment. Five questions signal that you cannot work with ambiguity — which is a PM's daily reality.
How to phrase your clarifying questions (speakable English)
- 'Before I start, I want to make sure I understand the scope — are we focused on the mobile experience or the web experience, or both?'
- 'Is there a particular metric you have in mind — for example, are we trying to improve retention, or is this more about acquisition?'
- 'Is there anything we know about which user segment is most important here, or should I make an assumption and state it?'
Interview tip
Phrase your questions collaboratively, not as requests for the interviewer to solve the problem for you. Compare: 'What should I focus on?' (weak — you are asking them to do your job) versus 'Is there a particular user segment that matters most, or should I choose one and explain my reasoning?' (strong — you are showing you can work with partial information).
Model answer: mid-level PM (consumer mobile app)
This is a complete, speakable answer for a mid-level PM candidate asked: 'How would you improve Google Maps?' Read it aloud before your interview — the transitions between steps are as important as the content.
Full model answer — mid-level PM
- CLARIFY: 'Before I jump in, I want to check one thing — are we focused on the consumer version of Maps, or are we also thinking about the business tools like Google Maps Platform? I'll assume consumer for now, but let me know if you want me to go in a different direction.'
- STRUCTURE: 'Great. Here is how I want to approach this. I'll start by identifying the main user segments, then I'll look at the core use cases for each, then I'll find the biggest pain points, and finally I'll propose two or three improvements and explain which I would prioritise. Does that work for you?'
- USERS: 'For consumer Maps, I see three main segments. First, daily commuters — people using Maps every day to get to work. Second, occasional travellers — people in an unfamiliar city who need to navigate and discover places. Third, local explorers — people who know their city but use Maps to find restaurants, check hours, and read reviews. Each of these groups has quite different needs.'
- USE CASES: 'Let me focus on daily commuters, because I think they represent the highest-frequency use case. Their primary tasks are: checking the fastest route before leaving, getting real-time rerouting during the commute, and understanding how crowded public transport is before they board. The underlying goal is not just to arrive on time — it is to reduce the mental load of commuting.'
- PAIN POINTS: 'Where does Maps fall short for commuters? First, the transit crowding information is often inaccurate or missing for smaller cities. Second, the app does not proactively suggest leaving earlier if it detects a delay — it waits for you to open it. Third, switching between walking and transit legs mid-journey is clunky — if your train is cancelled, the rerouting experience is slow.'
- IMPROVEMENTS: 'I would propose three improvements. One: proactive departure alerts — a push notification that says your usual route has a delay and suggests leaving ten minutes earlier. This directly reduces the commuter's mental load. Two: crowding data sourced from anonymised user speed data, similar to how Maps already does traffic. Three: a faster mid-journey reroute flow — a single tap that shows the two best alternatives when a transit leg is disrupted. I would prioritise the departure alert first because it is high impact, relatively low engineering cost, and directly addresses the core goal of reducing commute stress.'
- WRAP UP: 'So to summarise: I focused on daily commuters, identified that the biggest gap is proactive information rather than reactive navigation, and proposed a departure alert as the highest-priority improvement. Happy to go deeper on any of these, or to look at a different user segment if that would be more useful.'
Key takeaway
Notice that every improvement is explicitly tied to a pain point, and every pain point is tied to a use case. The chain is visible. This is what 'structured thinking' looks like in practice.
Model answer: senior PM (B2B SaaS tool)
At senior level, the interviewer expects you to bring in business goals, trade-offs, and prioritisation reasoning — not just user empathy. This answer is for the question: 'How would you improve Slack?'
Full model answer — senior PM
- CLARIFY: 'A couple of quick questions. Are we optimising for a specific business goal — for example, retention, expansion revenue, or reducing churn? And are we thinking about the core messaging product or also the newer features like Slack Connect or Huddles? I'll assume we are focused on retention for existing teams, and I'll concentrate on the core messaging experience — let me know if you want a different angle.'
- STRUCTURE: 'I want to walk through this systematically. I'll identify the key user segments, map their most critical use cases, identify where the current product creates friction, propose improvements, and then discuss how I would prioritise them given the retention goal. I'll try to keep each step tight so we have time to go deep where it matters.'
- USERS: 'In a B2B context, the users and the customers are not the same person. The customer is typically the IT admin or the department head who purchases and renews the contract. The users are the employees. I want to focus on two user segments that are most relevant to retention: power users — people who live in Slack all day, typically engineers and PMs — and reluctant users — people who are on Slack because their company requires it but find it overwhelming. Reluctant users are the retention risk.'
- USE CASES AND PAIN POINTS: 'For reluctant users, the core use cases are: staying informed about what is relevant to them, responding to direct requests, and not missing important information. The pain points are significant. First, notification overload — they cannot distinguish between what requires a response and what is just noise. Second, information retrieval — finding a decision that was made three weeks ago in a channel they were not in is genuinely difficult. Third, context switching — they are pulled out of deep work repeatedly by low-priority messages.'
- IMPROVEMENTS: 'Three improvements I would propose. First, an AI-powered daily digest — a summary of the decisions and action items that are relevant to each user, delivered once in the morning. This directly addresses information overload without requiring the user to change their behaviour. Second, a smarter notification filter that learns from a user's response patterns — if you consistently ignore messages from a particular channel, the system reduces their priority. Third, a 'focus mode' that is easier to activate and that integrates with calendar blocks. Of these, I would prioritise the digest. It has the highest potential impact on reluctant users, it is a retention lever because it reduces the 'Slack is exhausting' perception that drives churn, and it is technically feasible given Slack's existing AI investments. The risk is that it could reduce engagement metrics like daily active messages — but if we are optimising for retention, that is an acceptable trade-off.'
- WRAP UP: 'To summarise: I focused on reluctant users as the retention risk, identified notification overload and poor information retrieval as the core pain points, and proposed an AI digest as the highest-priority improvement because it addresses the root cause of churn in this segment without requiring behaviour change. I would measure success by tracking 90-day retention for teams with high proportions of reluctant users.'
Interview tip
At senior level, always name the metric you would use to measure success. 'I would measure this by tracking 90-day retention' takes five seconds to say and signals that you think in outcomes, not features.
What a weak answer sounds like — and exactly why it fails
A weak answer is not one with a bad idea — it is one that skips the process. Here is a real pattern that appears in PM interviews, followed by a precise diagnosis.
Weak answer
Interviewer: 'How would you improve Spotify?' Candidate: 'I use Spotify every day, so I have a lot of ideas. I think they should add better playlist management, because right now it's hard to organise your playlists. Also, the social features are not very good — you can't really see what your friends are listening to. And I think the recommendations could be better. Sometimes it recommends songs I don't like at all. So those are my three improvements: better playlist management, better social features, and better recommendations.'
Why it fails
1. No clarifying question — the candidate assumes they know what 'improve' means. 2. No structure announced — the interviewer cannot follow the thinking. 3. No user segmentation — 'I use Spotify' is not user research. 4. No use cases — 'hard to organise playlists' is a vague complaint, not an analysed pain point. 5. No prioritisation reasoning — the three ideas are listed with equal weight, no explanation of which matters most or why. 6. No metric — there is no way to know if any of these improvements would actually help the business. The ideas themselves are fine. The process is invisible, so the interviewer cannot score it.
Watch Out
The most common mistake non-native English speakers make in this question is spending mental energy translating their ideas into English — and skipping the framework entirely. The framework is what earns the score. Practise the framework phrases until they are automatic, so your cognitive load goes to thinking, not translating.
A second common failure: candidates who know the framework but do not say it out loud. They think through the steps internally and then present only the conclusion. The interviewer sees only the output and cannot tell whether the thinking was structured or lucky. Say every step out loud, including transitions. 'Now that I have identified the pain points, let me move on to the improvements' is not obvious to the interviewer unless you say it.
English phrases that signal PM thinking to interviewers
These phrases do two jobs at once: they communicate your thinking clearly, and they signal to the interviewer that you are approaching the problem like a PM. They are not filler — each one marks a specific move in the framework.
Clarifying the scope
- 'Before I start, I want to make sure I understand the goal here — are we trying to improve retention, acquisition, or something else?'
- 'I'll make an assumption and state it clearly — let me know if you want me to go in a different direction.'
- 'Is there a particular user segment that should be my focus, or should I choose one and explain my reasoning?'
Announcing your structure
- 'Here is how I want to approach this: first I'll identify the users, then the use cases, then the pain points, and finally the improvements.'
- 'I'll take a structured approach — starting with the users and working my way to the solution.'
- 'Let me walk through this step by step so my reasoning is clear.'
Signalling transitions between steps
- 'Now that I've identified the main user segments, let me look at their core use cases.'
- 'With those use cases in mind, I want to assess where the current product falls short.'
- 'I've identified three pain points — let me now propose improvements that address each of them.'
- 'Before I move on, let me check — does this level of detail work for you, or would you like me to go deeper on any of these?'
Prioritising improvements
- 'Of these three ideas, I would prioritise the first one because it has the highest impact on the pain point I identified, and the implementation cost is relatively low.'
- 'I would build this first because it directly addresses the retention risk I mentioned, and it does not require a behaviour change from the user.'
- 'The trade-off here is that this improvement might reduce engagement in the short term — but if the goal is retention, I think that is acceptable.'
Wrapping up cleanly
- 'To summarise: I focused on [user segment], identified [pain point] as the biggest gap, and proposed [improvement] as the highest-priority change because [reason].'
- 'I would measure success by tracking [specific metric].'
- 'Happy to go deeper on any of these, or to explore a different user segment if that would be more useful.'
Interview tip
The transition phrases are the most important ones to memorise. They cost almost no cognitive effort to produce, but they make the difference between an answer that sounds structured and one that sounds like a stream of consciousness — even if the underlying ideas are identical.
One note on register: all of these phrases are neutral-professional English. They work equally well in US and UK interviews. Avoid very informal phrases like 'So basically...' or 'The thing is...' at the start of a new step — they undercut the structured impression you are building.
Design questions vs. improvement questions: one key difference
Product design questions ('Design an alarm clock for the blind') and product improvement questions ('How would you improve our onboarding?') use the same framework, but they require one different emphasis.
Insight
In a design question, you are building from scratch — so the pain points come from understanding the user's world. In an improvement question, you are diagnosing an existing product — so the pain points come from comparing the current product against the use cases.
Consider the alarm clock for blind users example. The clarifying questions matter enormously: are we designing for someone who is fully blind, or someone who can detect light? Is this for home use or travel? Is it a physical device or a mobile app? Each answer produces a completely different product. A candidate who dives straight into features — 'I would add a voice interface' — has skipped the problem definition entirely. The right first move is to establish the user's actual context, because a blind adult living alone has different needs from a blind adult who shares a bedroom with a sighted partner. The sighted partner is also a user: an alarm clock that announces the time out loud at 5am will not survive in a shared bedroom.
| Question type | Step 5 focus | Key phrase to use |
|---|---|---|
| Design from scratch | What does the user's current situation lack? What workarounds are they using? | 'Without this product, how does the user currently solve this problem?' |
| Improve existing product | Where does the current product fail against the use cases you identified? | 'Looking at the current product against these use cases, where are the biggest gaps?' |
The framework is the same. The evidence you reach for in step 5 is different.
Interview tip
For design questions, think carefully about secondary users — people who interact with the product but are not the primary user. An alarm clock for blind users still needs to be usable by a sighted partner who wants to turn it off. A children's calculator needs to be understood by the teacher and purchased by the parent. Naming secondary users in step 3 is a signal that you think about the full context of a product, not just the happy path.