By Remi · · 4 min read
How to make a long answer clearer
You finish explaining a project and realize you’ve spent most of the answer setting it up. The decision you wanted to talk about came near the end, when you were already rushing.
When you know a project well, it’s easy to include details because you remember them. But the interviewer is hearing it for the first time. They need enough background to understand what you did, without having to work out which parts matter.
Here’s how to edit an answer while keeping the substance.
Examples are fictional illustrations, not testimonials or Remi’s in-product prompts. Use your own experience and leave out confidential information.
In this guide
Start closer to the problem
Suppose you’re asked about a time you had to reduce scope.
You could start with how the project began, who requested it, and what happened in the first few planning meetings. Or you could start here:
“We had six weeks to improve onboarding, but the full redesign would take longer. I needed to recommend what we could deliver first.”
That gives the interviewer the problem, the constraint, and your responsibility. You can now explain the choice.
Look at the opening of your own answer. How much does someone have to hear before they know what you were trying to solve?
Try starting at that point. Add earlier background only if it’s needed.
Keep the details that explain your decision
Shortening an answer can go too far. You might end up with:
“I reviewed the data, reduced scope, and we launched on time.”
It’s brief, but the interviewer can’t tell what you learned or why you chose that scope.
The useful details are the ones that connect the problem to your actions. In this example, those might be:
- Where customers were getting stuck.
- Why you chose to fix that step first.
- What you agreed to postpone.
- What happened after the smaller release.
You can usually leave out the names of internal meetings, the full team structure, and every step in the project timeline.
A simple check helps: If I remove this detail, can someone still understand why I did what I did?
Compare these two versions
Here’s an illustrative first draft:
“Onboarding had been on our roadmap for a while. Sales had raised it, support had feedback, and we’d discussed several ideas. We had six weeks before a customer rollout. The designer explored a full redesign, but engineering said it would take longer. I looked at support tickets and setup data, and the import step kept coming up. I spoke with customers who’d got stuck there. They couldn’t tell how to fix errors in their files. We discussed it in planning, and I recommended focusing on those errors and leaving the rest of the redesign for later. We shipped before the rollout. In the customer sessions afterward, people could fix the file errors and continue.”
A clearer version:
“We had six weeks to improve onboarding before a customer rollout, but the full redesign would take longer. I reviewed setup data and spoke with customers who’d got stuck. The import step was a recurring problem: people couldn’t tell how to fix errors in their files.
“I recommended improving the error messages first and postponing the wider redesign. We shipped that change before the rollout. In the customer sessions afterward, people could fix the errors and continue.”
The shorter version keeps the reason for the deadline, the customer problem, the recommendation, and the observed result.
It removes the history of how onboarding reached the roadmap and the mention of the planning meeting. Those details weren’t needed to understand the choice.
Say each important thing once
Sometimes an answer is long because you keep explaining the same point:
“We had limited time.”
“The deadline was tight.”
“We needed to move quickly.”
Choose the clearest version and move on. Use the space to explain what the constraint made you do.
Watch for repeated conclusions too. After describing what changed, you probably don’t need to add that the project was successful, had a positive impact, and delivered value. Let the specific result carry that point.
Keep extra detail ready for questions
Cutting something from your opening answer doesn’t mean it has no value.
The interviewer might want to know what else you considered, how engineering estimated the work, or whether anyone disagreed. Keep those details in your notes so you can go deeper when asked.
You don’t have to answer every possible follow-up before it comes.
Try one edit, then say it aloud
Choose an answer that tends to run long.
First, underline the sentence where you explain your main action or decision. If it appears late, move the essential setup closer to it.
Then remove one piece of unnecessary background and one repeated point. Say the revised answer aloud from bullet points.
Ask a listener to tell you what you did and why. If they can follow the decision but need one missing detail, add that detail back. You’re aiming for an answer they can understand on the first hearing.
For help putting the parts in order, use this guide to structuring an answer. Keep the fuller answer in Remi and practise explaining the main points in your own words.
This guide covers past-experience PM interview preparation. Interview expectations vary by employer; additional product, analytical, or technical preparation may be needed.