Ladder of Feedback

Four rungs, climbed in order: ask about what you don't understand, say what works, name what worries you, and only then suggest changes. Used on a demo, a design or a proposal, it gives the author feedback they can act on instead of a pile of opinions.

Clarify

Ask neutral questions to ensure shared understanding

Value

Call out what you appreciate and why it works

Concerns

Name worries respectfully and specifically

Suggestions

Offer concrete ideas to improve

Use this template — it's free

What the Ladder of Feedback is

The Ladder of Feedback is a way to review one piece of work — a demo, a prototype, a design, a technical proposal — in four steps that always come in the same order. Reviewers first clarify what they don't understand. Then they say what they value in it. Only after that do they raise concerns, and they finish with suggestions. The protocol comes from education — it is usually credited to David Perkins and Harvard's Project Zero — and product teams have picked it up for demos and design reviews.

The order does the work. Each rung blocks a common way feedback sessions go wrong:

• Questions before opinions. A lot of criticism is a misunderstanding. "Why does the table stop at 500 rows?" may have a good answer, and once it's answered, nobody needs to raise it as a concern.
• Value before concerns. This is not about softening the blow. When the author reworks the piece, they need to know which parts to keep. A review that lists only problems invites a rewrite that throws out the good parts as well.
• Concerns apart from suggestions. A concern names a problem; a suggestion proposes one fix. Kept apart, the author can accept the problem and still choose a different fix, and the room agrees that a problem is real before it argues about solutions.
• Everyone climbs the same rungs. The senior engineer who usually opens with "this won't scale" has to ask and appreciate first, and the quiet newcomer gets a column where a question is exactly the right contribution.

When to use it, and when not to

Use the ladder when there is something concrete on the table and the author is still free to change it:

• an internal dry run of the sprint review, before stakeholders see the demo;
• a design review of a prototype or a new user flow;
• a technical proposal or architecture document the whole team will have to live with;
• a beta feature shown to support, sales or customer success, who notice different problems from the people who built it;
• a newer teammate's first large piece of work, when you want feedback that teaches rather than flattens;
• any review where one loud voice usually sets the tone, or where nobody speaks until the meeting is over.

Pick something else when:

• There is no artifact. If the subject is "how did the sprint go", you need a retrospective: KPT for a fast one, the 4Ls for a more reflective one.
• The work has shipped and won't change. Suggestions nobody can act on only frustrate people. Look at what you learned instead, and save the ladder for the next version.
• The feedback is about a person. The ladder judges the work, not the colleague who made it. Feedback on someone's performance belongs in a one-to-one.
• The real problem is between people. If reviews keep turning tense for reasons that have nothing to do with the design, name that first with Elephant in the Room.

The four rungs

The template opens with four columns: Clarify, Value, Concerns and Suggestions. To show how the rungs fit together, every example below is about the same demo: a redesigned search page in the admin panel that the support team uses every day, with new filters, saved searches and a new results table.

Clarify: questions for shared understanding

Neutral questions about what the work is, who it's for and what is still undecided. The test for this column: could the author answer it with a fact? "Who is this for?" is a clarifying question. "Wouldn't tabs be simpler?" is a suggestion dressed as a question, and it belongs two rungs higher.

• Is this built for support agents, account managers or both?
• Are saved searches private, or shared with the whole team?
• Is the 500-row limit a decision or a placeholder?
• What happens to the old search page after launch?

Value: what works, and why

Specific strengths the author should keep in the next version. "Nice work" doesn't count — it tells the author nothing they can use. Name the detail and the reason it works, as if you had to defend it against someone who wanted to cut it.

• Filters live in the URL, so I can send a search to a colleague
• The empty state says which filter removed all the results
• There's a keyboard shortcut for the search box, and agents rarely touch the mouse
• Results update as you type, with no Search button to hunt for

Concerns: worries, named respectfully and specifically

Problems or risks you see, with the reason. A useful pattern is "I'm worried that … because …". The test that separates a concern from a suggestion: it describes what might go wrong, not what to do about it. If your card contains "should", it is probably a suggestion.

• Twelve filters on one screen: new agents may not find the two they need
• The results table drops "last contact", which agents check on every ticket
• The demo account has a few hundred contacts; our biggest customers have tens of thousands
• Saved searches have no owner, so the list could be a mess within a month

Suggestions: concrete ideas to improve

Specific changes the author could make, ideally small enough to try before the next review. A good suggestion answers one of the concerns. If it answers none, ask which problem it solves before you add it.

• Show four filters by default and put the rest under "More filters"
• Bring back "last contact" as an optional column
• Before launch, try it with three agents on their real accounts
• Give every saved search an owner and archive the ones unused for 60 days

Use this template — it's free

A 60-minute Ladder of Feedback agenda

This plan suits one piece of work, one author and four to eight reviewers.

1. Warm-up, 5 minutes. One easy question from the icebreaker questions list gets every voice into the room before the critique starts. ProstoRetro's built-in icebreaker round gives each person a turn.
2. Show the work, 10 minutes. The author demos or walks through the piece and says what it is for and what is still open. Reviewers listen; their questions go on the board.
3. Silent writing, 10 minutes. Everyone adds cards to all four columns, one point per card. Cards stay hidden from others until the writing ends, so the first sharp concern doesn't set the tone for the rest.
4. Answer the questions, 7 minutes. When the cards are revealed, the author reads the Clarify column aloud and answers each question in a sentence or two. Any concern the answers resolve is dropped from the discussion.
5. Grouping, 5 minutes. Merge duplicate concerns and suggestions, and put each suggestion next to the concern it answers. ProstoRetro can propose the groups with AI; you keep or undo them.
6. Voting, 3 minutes. Reviewers vote on the concerns the author should deal with first. The author sits this one out: the vote shows what the reviewers care about most.
7. Discussion, 15 minutes. Read the Value column aloud in two minutes, with no debate. Spend the rest on the top-voted concerns, each with the suggestions grouped next to it.
8. Next steps, 4 minutes. The author says which changes they will make and by when. Record them as action items with an owner and a due date.
9. Close, 1 minute. Thank the author. Presenting unfinished work to a critical audience is the hardest seat in the room.

Running it with a remote team

• Point with screenshots. "The button on the right" means nothing on a video call. Cards can carry images, so paste a screenshot of the exact screen a card is about.
• Sign the questions, not necessarily the concerns. Anonymous cards are on by default, and each person can sign a card or not. Unsigned concerns help when the author is senior to the reviewers; signed questions let the author follow up after the call.
• Invite the people who see other problems. When the room is open to anyone with the link, a support agent or a customer success manager joins with just a name, without creating an account.
• Stop the live redesign. Remote reviews drift into redrawing the screen together. Put a timer on each concern, and when it runs out, leave the solution to the author.
• End with an honest read of the room. An anonymous poll — "ship as is", "ship with the changes", "needs another review" — tells the author more than polite nods on camera.

Variations

The asynchronous ladder

For a long document such as a technical proposal, reading it together in the meeting wastes everyone's time. Open an infinite room, ProstoRetro's board with a permanent link, a few days ahead and let reviewers add cards as they read. The cards stay hidden until the meeting, and the call starts straight with the questions and the top concerns.

The spoken ladder for two

For a pull request, a mockup or a short spec, two people don't need a board. The reviewer walks the four rungs out loud, in order, in about fifteen minutes. It's a good habit for pairs and for mentoring, and it trains people out of opening with "this is wrong".

A fifth rung for questions only users can answer

Some concerns can't be settled by opinion: whether agents will use saved searches at all is a question for the agents. Build a custom template with a fifth column such as "Ask users" and collect those questions there. They become the plan for the next round of user interviews instead of a debate in this one.

Common mistakes

• Concerns disguised as questions. "Have you thought about mobile?" is a concern. Write it as one, so it can be voted on.
• Dropping the Value rung when time is short. It is the easiest rung to skip when the clock runs down, and the one that tells the author what to protect in the rework.
• The author defending every card. In the discussion the author asks follow-up questions and listens. Decisions about what to change come afterwards, not live under pressure.
• Reviewing too much at once. Three features in one session means shallow feedback on each. One artifact per ladder.
• No decision at the end. If the author leaves without saying what they will change, the next review repeats the same concerns.

FAQ

What are the four steps of the Ladder of Feedback?

Clarify, value, concerns and suggestions, in that order: ask questions until you understand the work, say what is good about it, name what worries you, and only then propose changes.

What is the difference between a concern and a suggestion?

A concern describes a problem or a risk ("new agents may not find the filters they need"); a suggestion proposes a fix ("show four filters by default"). Keeping them apart lets the team agree on the problem before it picks the fix.

Is the Ladder of Feedback a retrospective?

Not quite. A retrospective reviews how the team worked over a period; the ladder reviews one piece of work while it can still change. Run it as part of the sprint review, and hold a separate retro on how the work went, for example with Rose–Thorn–Bud.

How long does a Ladder of Feedback session take?

About an hour for one substantial piece of work. For a small change reviewed by three or four people, keep the demo to five minutes, discuss only the top two concerns, and it fits in 30 minutes.

Can I run the Ladder of Feedback online for free?

Yes. Ladder of Feedback is one of the templates built into ProstoRetro; it costs nothing, and reviewers join from a link. Our guide on running a retro in ProstoRetro covers each phase step by step, and the template library has formats for the retro that follows.