The Feedback Ladder: From Code Review to Customer Insights
I’ve worked with hundreds of developers over the years.
Some build fast but never seem to deliver what matters.
Others move slower—but consistently land the work that has real impact.
The difference isn’t velocity.
It’s feedback.
Or more specifically, how many layers of feedback that developer actively uses.
Most teams only think about feedback at the top: customer feedback, feature usage, stakeholder input.
But the best developers I’ve worked with? They’re collecting feedback constantly—from the inside out.
It’s a layered system. And if your team isn’t using it, you’re probably shipping code that misses the mark.
Let’s walk through what that system actually looks like.
Layer 1: Internal Review — Your Own Thinking
Before code reviews, before QA, before you push the commit… there’s the first and most powerful feedback loop:
Your own brain.
Ashley Davis, my guest on this week’s Product Driven Podcast, calls it “personal feedback loops.” That moment where you step back from your code and ask:
Am I solving the right problem?
Is there a simpler way to do this?
What trade-offs am I making?
What did I not do, and why?
It’s a kind of self-review that mirrors test-driven development—except it’s about thinking, not tests.
And it’s massively underrated.
Every good developer I’ve ever worked with has some form of this reflex.
They pause. They reframe. They gut-check before handing it off.
You can teach this. But only if you name it.
Layer 2: Peer Feedback — Fast and Frictionless
Here’s where most teams stop: peer reviews, code comments, maybe a Slack convo after standup.
But ask yourself:
Are peer reviews helping engineers make better decisions?
Or just checking for syntax and spacing?
True peer feedback means surfacing assumptions. It means having the courage to say, “Are we sure this is the best way to do this?”
It’s not about nitpicking. It’s about building a culture where better thinking gets multiplied.
Make it lightweight. Make it normal. Make it continuous.
Layer 3: Stakeholder Feedback — Are We Still on Track?
Ashley said it best: “You can spend hours or days coding in the wrong direction.”
That happens when developers lock in too early—without checking with the PM, designer, or team lead.
At Full Scale, we’ve seen teams burn weeks on misunderstood features simply because nobody paused to ask: Are we still aligned?
This isn’t about waiting for sign-off. It’s about developers taking ownership for the outcome.
The best engineers don’t just ship what’s in the ticket. They ask if the ticket still makes sense.
Layer 4: User Feedback — Did It Work?
This is the top of the ladder. The place most teams claim to care about… but rarely reach.
It’s not enough to ship the feature.
Did the user notice?
Did it solve their problem?
Did anything actually get better?
If you don’t know, you’re not done.
And if your engineers never get visibility into that feedback, they’ll never improve their instincts for what matters.
Ashley pointed out how many developers work in a vacuum today—especially in remote environments. That used to happen gradually as companies scaled.
Now it happens from day one.
And that disconnection? It’s killing motivation, slowing progress, and leading to more waste than most CTOs want to admit.
How to Build the Feedback Ladder Into Your Team
Start with questions. Encourage developers to gut-check their own work before review.
Normalize mid-flight feedback. Don’t wait for sprint review—ask for feedback on direction early and often.
Break the wall between engineering and users. Share customer insights with the dev team regularly. Let them see the impact (or lack of it).
Reward curiosity. When someone asks, “Are we sure this is the right thing?”, celebrate that. It’s not dissent—it’s ownership.
Great developers don’t just code faster.
They climb the feedback ladder—every day.
If your team is stuck, burned out, or off track, don’t just ask them to move faster.
Ask them what kind of feedback they’re using.
Then go one layer deeper.
🎧 To hear my full conversation with Ashley Davis—author of The Feedback Driven Developer—and learn how to make feedback loops part of your development culture, check out this week’s Product Driven podcast.
You’ll never think about “product-led” the same way again.