“What would you change about our product?” is a trap only if you treat it as an invitation to criticise. Interviewers ask it to see three things: whether you actually used the product before the interview, whether you think about the people who use it, and whether you can suggest an improvement without dismissing the work of the people who built it.
The answer that works is one specific change, explained from a user’s point of view, offered as a hypothesis rather than a verdict, with an idea of how you would test it. The seven steps below build that answer, whether “the product” is an app, a banking service, a hotel stay or an industrial part.
Step 1: Use the product as a customer would
Nothing replaces first-hand use. Download the app, sign up for the free tier, walk into the branch, order from the menu, phone the helpline, read the returns policy. Take notes as you go, with times and screenshots where you can. Interviewers can often tell quickly whether a candidate has used the product or only read about it.
Use it at least twice: once as a newcomer, paying attention to the first five minutes, and once trying to complete a real task, such as booking, paying, cancelling or finding help. Problems often hide in the second visit.
If the product is not available to you (enterprise software, a medical device, a business-to-business service), use what is public: demo videos, documentation, published case studies, public reviews and the company’s own help pages. Say in your answer that this is what you used. Being clear about the limits of your evidence is part of a good answer.
Step 2: Decide who the change is for
A product has different users with different needs. A food delivery app serves customers, restaurants and riders. A bank account serves the customer, but also the staff who handle its queries. Name the user before you name the problem.
The UK government’s Service Standard for public services makes the point well. Its guidance on understanding users notes that “the real problem might not be the one you originally thought needed solving”, and asks teams to focus on the user and the problem rather than a particular solution. Borrow that discipline: start your answer with the user and their problem, not with the feature you want to add.
Step 3: Pick one change, not a list
Candidates who arrive with eight suggestions tend to recite all of them, and the answer turns into a complaints list. Prepare two or three, then lead with one. Choose it using these filters:
- It affects a real task. Signing up, paying, finding information, getting help. Colour schemes and logos rarely make good answers.
- It connects to the job. A customer service candidate should talk about support; a sales candidate about the buying journey; an engineer about reliability or speed.
- It is fixable. “Make it cheaper” is not a product insight.
- You can explain it in a minute. If it needs a diagram, simplify it.
Step 4: Describe what you observed, then what you suspect
Separate evidence from interpretation. “When I tried to change my delivery address after ordering, I could not find the option and had to use live chat” is an observation. “I suspect many customers contact support for this” is a hypothesis. Keep them in that order and label the second one as a guess. You do not have the company’s data, and pretending you do is the fastest way to lose credibility.
The same Service Standard guidance says that testing assumptions early and often reduces the risk of building the wrong thing. Using that framing in an interview shows that you know your idea might be wrong.
Step 5: Acknowledge why it might be this way
Most product decisions that look odd from outside have a reason: regulation, fraud prevention, cost, a technical constraint, or a trade-off for a different group of users. Show that you have considered this. One sentence is enough: “There may be a fraud reason for not allowing address changes after payment, so I would want to understand that first.”
This step is what separates a thoughtful answer from a complaint. It also protects you if someone on the panel built the feature you are discussing.
Step 6: Say how you would test or measure it
Close the loop with a practical next step. You do not need a full research plan. Pick one of these and adapt it to the role:
- Check support records for how often customers ask about the issue.
- Watch five new users attempt the task and note where they stop.
- Try the change with a small group before rolling it out.
- Compare the completion rate for the task before and after.
The Service Standard’s guidance on simplicity asks that users can complete their task “first time, with the minimum of help”. That is a useful success measure to borrow for almost any product.
Step 7: Link it back to the role
End with one sentence about why this matters for the job you are applying for. Starting from the customer and working back to the change is a habit most employers value, whatever they call it, and this is your moment to show it in the context of their work.
The seven steps in one illustrative answer
Illustrative answer (customer support role at a subscription app): “I used the app for two weeks before this interview, so this is from my own experience. The thing I would look at first is cancelling a subscription. When I tried, the option was three menus deep, under Account rather than Subscription, and I ended up using the help chat. My guess is that a fair share of support contacts are about this, but you would know from your ticket data and I don’t. There may be a reason it is placed where it is, for example a retention offer the business wants people to see first, so I would want to understand that. If I joined the support team, I would start by tagging cancellation contacts for a month to see how big the issue really is, and share that with the product team. A clearer path would probably mean fewer frustrated contacts and better reviews, even from people who leave.”
It is about 170 words, takes a little over a minute to say, and covers every step: first-hand use, a named user and task, one change, evidence separated from guesswork, a possible reason, a test, and a link to the role.
Adjusting for different kinds of employer
| Employer | What “the product” usually means | Where to look for your change |
|---|---|---|
| Software or app company | The app, website or platform | Sign-up, first use, payment, settings, cancellation |
| Bank or insurer | Accounts, cards, claims, the app and the branch | Opening an account, document requests, claim updates |
| Hotel, restaurant or retailer | The visit, the booking and the after-sale service | Booking flow, check-in, queueing, returns, loyalty schemes |
| Manufacturer or supplier | A physical product and the support around it | Documentation, ordering, lead-time information, spare parts |
| Public body or non-profit | A service the public uses | Forms, eligibility information, accessibility, languages offered |
In the UAE and other multilingual markets, language support is often a fair and useful area to examine: whether Arabic and English versions match, whether forms accept names written in different formats, and whether help is available in the languages customers actually use. Base any such point on what you observed, not on assumptions about the company.
Answers that go wrong
- “I wouldn’t change anything.” It sounds polite but suggests you did not look closely, or that you avoid giving feedback.
- A redesign of everything. Ambition is fine; dismissing the whole product is not.
- Quoting numbers you cannot know. “Your churn must be very high” is a claim about their data, not an observation.
- Copying a competitor. “Make it more like [competitor]” gives no reasoning. If a competitor does something well, explain what the user gains from it.
- Criticising staff. “The person on the phone didn’t know anything” is about a colleague you might soon work with. Describe the process gap instead, for example that the information was hard to find.
Use the research twice
The time you spend using the product also improves your application. If your notes show the company cares about a particular part of the customer journey, make sure your CV gives evidence of related work, such as reducing repeat contacts or simplifying a sign-up form. For support roles, the customer service resume builder page shows how to phrase that kind of result, and the resume questions hub answers common questions about tailoring a CV to a specific employer.
Frequently asked questions
What if the interviewer built the feature I criticise?
That is why Steps 4 and 5 matter. If you have separated what you saw from what you suspect, and acknowledged there may be a reason for the current design, the conversation becomes a discussion rather than a defence. Ask what the reasoning was; the answer usually tells you a lot about the team.
Should I prepare slides or mock-ups?
Only if the employer asks for them, which is common for design and product management roles. For most jobs, a clear spoken answer is enough. Bringing unrequested materials can come across as presumptuous.
Can I say something positive first?
Yes, briefly. One sentence about what works well shows balance and that you used the product properly. Then move to your change; don’t let the praise take over the answer.
What if I could not access the product at all?
Say so, explain what public material you studied instead, and base your suggestion on that. You can also turn it into a question: ask how customers usually first experience the product. Honesty about your evidence is better than an invented critique.
Sources
- Service Standard, point 1: Understand users and their needs, GOV.UK Service Manual
- Service Standard, point 4: Make the service simple to use, GOV.UK Service Manual