How a Backend Team is Leading the Product Revolution
This all started with a question by Andreas, a Product person for a backend team that I coached. The mental block: you can't be product and user-centered in backend teams. Here's my counter argument.
Why Feedback is Essential in Agile Teams
“We mostly hear from users when something breaks.”
— Andreas, Technical Analyst on a backend platform team
It was one of those statements that stops you mid-sentence. Andreas wasn’t trying to be dramatic. He was just being honest.
His team manages a backend platform that powers a suite of internal tools at a major European bank, and they are good at what they do. Stable. Scalable. Efficient.
And yet, when it comes to being a customer-oriented product team (internal customers, in this case), Andreas was stuck. He couldn’t see how to apply the most basic product mantra: “Listen to your users.”
And there’s a good reason for him to feel that way.
“People only reach out when something’s broken. No one ever says ‘Hey, your service saved me an hour today.’ And even if they did… we’re usually too busy fighting fires to do anything with it.”
Sound familiar?
This is the quiet reality for many Agile teams, especially in mature organizations where backend systems are long-established and user contact is minimal. Sometimes even discouraged… ☹️
Agile champions continuous improvement, but how do you improve when the only feedback you get is a support ticket, a passive-aggressive Slack message, or worse: silence?
In this post, we’ll unpack that question. I’ll walk you through a real conversation with Andreas, and share concrete ways to shift from reactive problem-solving to proactive insight-building. Even if your product is a backend system, that lives entirely behind the scenes.
Spoiler alert: It’s possible.
Even if you’re not “customer-facing.”
Even if your team is swamped.
Even if feedback feels like a luxury you don’t have time for.
Let’s help Andreas.
Let’s help all of us.
Let’s dig in.
🔍 1. The Challenge: Why Feedback is Hard in Existing Products
“We mostly get feedback when something is broken. How do we get proactive insights rather than just complaints?”
— Andreas, Technical Analyst
Andreas wasn’t just curious, he was frustrated. You could hear it in the tone of his voice.
If you’re someone trying to bring more product thinking into a technical team, you’ve probably felt the same way.
Even if complaints are feedback, they’re late feedback. They tell you what should have been different, not what’s possible going forward. They keep teams stuck in the past, chasing problems, rather than designing for the future based on direct user or customer feedback.
And for backend teams (where users are often other internal developers) the feedback loop is even more fragile. No visible interface. No app store reviews. Just a JIRA ticket when something breaks… or silence.
Crucially, what Andreas was describing is the default state for many teams. But it doesn’t have to stay that way.
✅ Try This: Move From Reactive to Proactive Feedback Collection
Instead of waiting for feedback to arrive wrapped in a JIRA bug report, we can build deliberate feedback loops into how we operate. Even in backend systems.
Here are a few ways to start:
Schedule Developer/User Check-ins:
Talk to the teams using your services. Not when there’s a problem, but on a regular basis. Ask how they’re using the system, what’s working, what’s awkward, and what they don’t care about (refactoring or removing is possible here).Run Lightweight Experiments:
Use feature flags or API versioning to roll out small changes and monitor how users respond. Follow up with a short feedback prompt (“How did this update make your life easier?” is often enough). For example: deprecate an API endpoint with a feature flag. Collect feedback. Then remove (or not) the deprecation.Embed Feedback Collection Points:
Consider in-context tools like:A short survey link in the release notes
A quick thumbs-up/down button in your internal dev portal (just like AI chatbots use these days)
🛠 Extra Tactic: Release Notes Reactions
If five or more teams use your service, try this trick:
Add emoji or simple poll reactions to your release notes.
For example, post your update in Slack, Discord or Teams, and for every major update in the notes, ask:
“Was this update useful? 👍👎”
TIP: seed it. Reach out privately to a few users ahead of time, and ask them to react or reply after reading. This gives social proof, which encourages others to chime in.
It’s fast. It’s visible. And it shows your team wants to listen, not just when things go wrong, but all the time.
⭐️⭐️⭐️⭐️ This post is sponsored by The Global Agile Summit, where you can find the most advanced ideas on Software, Product Development and Agile! Join The Global Agile Summit, the most forward looking Agile event of 2025
🔦 2. The "Invisible User" Problem: Collecting Feedback in Backend Teams
"Since we work on backend products, we don’t have direct contact with end users. How do we even start gathering feedback?”
— Andreas
This is one of the most common (and dis-empowering) mental blocks for backend teams who genuinely want to be more product-minded.
Because if you don’t have direct access to “users,” how do you even start listening to them?
Backend Teams: You Do Have Users!
Just because you’re not building UIs doesn’t mean you don’t have users. You do.
They’re the developers in other teams: the ones integrating your APIs, relying on your data pipelines, and building their features on top of your platform.
And their developer experience matters. We’d call that user-experience in end-user facing teams, right?
Just like end users, developers want things to be intuitive, predictable, and easy to use.
Just like end users, they get frustrated when things are unclear or break unexpectedly.
And just like end users, they often won’t speak up unless something goes really wrong.
So here’s your shift in mindset for Product people working with backend teams:
Your job isn’t just to ship code.
Your job is to build a product that helps other teams ship their code better.
And when backend teams adopt this mindset, when they see their software as a product for others, it sparks something powerful:
🧠 A product culture starts to grow across the whole organization.
Because if every team is user-centered (not just the front end), the entire company becomes more agile, more collaborative, and more innovative.
✅ Try This: Create Developer Feedback Loops
Start small. Don’t overcomplicate it. Here's how to begin:
Run Developer Interviews
Schedule short 20-minute chats with teams using your services. Ask how they’re using your APIs, what’s confusing, what they are currently working on, and what’s difficult for them about it. These are your "user interviews."Create a Developer Feedback Channel
Set up a Slack, Discord or Teams channel like#platform-feedback. Pin a simple feedback form or just a message like:
“Using our API? Got a win? Hit a weird edge case? Drop it here, we’re listening! 🙌”
Celebrate Dev Successes
When another team ships a cool feature thanks to your platform, highlight it! “This new shortcut in the UI? Powered by our new search endpoint.” That visibility reinforces your product's value, and builds pride.
🛠 Bonus Tactic: Make Feedback Feel Like a Conversation
Nobody wants to “open a ticket” just to say something could be better. That feels formal, slow, and often thankless. And frankly, that’s why most teams only get “THIS IS COMPLETELY BROKEN” JIRA tickets…
Instead, make it feel social. Informal. Like helping out a colleague.
One team pinned a message in their feedback channel that read:
“We’re constantly improving our platform. If you’ve got thoughts, rants, or brilliant ideas, drop them here or in this form. We’re humans. We’ll read it.”
A small shift like that (tone and accessibility) can made feedback flow.
📉 3. The Data Gap: How to Get Actionable Usage Insights
"We lack data on how people actually use our API. We can track endpoint hits, but that doesn’t tell us the full story."
— Andreas
Here’s where many teams get stuck: They have some data, but not the kind that drives decisions.
This is the moment to shift from Volume to Value.
One of the first things I help teams understand is this: your metrics should reflect your product’s impact, not just its activity.
For backend teams: it’s not enough to know that your API is called 10,000 times a day. You need to know why, how, and to what effect.
That’s where daily metrics come in.
These are the signals that help you make informed product decisions every day. They won’t be available out-of-the-box. You’ll likely need to define and instrument them with your team. But once in place, they’ll help you navigate with clarity.
✅ Start with Metrics That Matter For Backend Teams
Here’s what this could look like for a backend team:
Most used API endpoints (also least used API endpoints)
Most frequently failing requests
Feature adoption rates for new or optional parameters
And don’t stop at what’s used, capture context:
Which teams and components are using which endpoints?
Are feature flags turned on?
What’s the size or scope of the payload?
Introduce observability tools that can give you rich, queryable logs and insights, and work with your platform team to tag and trace usage patterns over time.
🧪 Bonus Tip: Usability Dojos
One team coined this practice “Dev Gym Fridays.” Another called it “Integration Labs.” Whatever you name it, the idea is simple and powerful:
Bring internal users into a structured, low-stakes environment to use your product and give live feedback.
Watch them work. Ask them what feels clunky. See where they slow down. That’s more valuable than any chart of endpoint hits.
These kinds of feedback loops don’t just help you improve your product.
They also build empathy, alignment, and trust.
⚖️ 4. The Breaking Change Dilemma
"We have a ton of legacy code. If we improve the API for the 80% use case, it could break things for the 20%."
— Andreas
This one hits hard, because it’s not just technical. It’s emotional. Andreas is afraid of making improvements because of possible consequences for edge cases!
You don’t get rewarded for breaking things that work. But if you don’t evolve your API, your team risks becoming a hostage to its past. Andreas is stuck between two bad options: maintain the legacy and stall innovation… or break something and lose the trust of his users.
✅ Try a Two-Stage Validation Process
1. Quantitative:
Analyze usage. How many consumers rely on those edge-case features? If it’s under 5%, that’s a signal to consider deprecating. Talk to the users of that endpoint, and consider their context. The metrics help you decide where to look!
2. Qualitative:
Don’t do it alone. Run a Developer Advisory Board. Invite teams who use your API to help co-design the next version. Make it collaborative. Ask your Agile Coach or Scrum Master to facilitate so you can focus on the content, asking questions, and building understanding for your users.
🛠️ De-Risk the Transition
Offer grace periods and dual-support phases: Maintain old and new versions side-by-side.
Use feature flags or opt-in beta endpoints to validate improvements.
Build a small internal changelog portal with version timelines and migration guides. TIP: use a markdown tool for that such as Notion or Confluence.
Create a Sunset Monitor: A dashboard showing what % of traffic still uses deprecated endpoints, so everyone sees progress, and you get the data you need to justify decisions you need to make for your product.
🔁 Key mindset:
Treat change — even deprecation — like a product. Market it. Test it. Support it.
🎯 Visual metaphor:
It’s like building a new bridge right next to the old one—before tearing it down. Everyone will see the old bridge, and the new one. Slowly the traffic will shift, and you will be able to remove the old one.
♻️ 5. Making Feedback a Habit
"Even if we start collecting feedback, how do we ensure it becomes part of how we work and not just a one-time thing?"
— Andreas
This is the ritualization part. And it’s a question every product team must answer, not just backend teams.
Because feedback isn’t just a one-off activity. It should be a habit.
Like brushing your teeth. Not just for emergencies.
✅ Establish a Feedback Rhythm
Quarterly Feedback Retros: Analyze trends across interviews, surveys, and support tickets.
Backlog Refinement: Add a review step where feedback is mapped to upcoming work.
Assign a Feedback Champion: Someone on the team owns tracking and following up on feedback threads. Hint: if you are a Product person, this should be you at first, but you can ask for help!
And most importantly: close the loop.
Publish a "You Said, We Did" update every quarter. Even internally, especially internally!
Thank contributors. Show them how their input shaped decisions. This builds your future user team! They will help you for a long time.
Invite users to help prioritize future work. Start small, with friendly users, then go broader when you feel comfortable with the process.
🔄 Use The Existing Ceremonies to Sustain Feedback
Refinement: Great time to review feedback and turn it into actionable stories.
Retrospectives: A chance to reflect on how feedback is collected and used.
Want to go even deeper? Try running a retro about your feedback practices. Go meta. It's worth it.
Feedback isn’t just a tool—it’s the voice of your future product whispering back to you. 💬
🎯 Small Steps, Big Impact
Creating a culture of feedback doesn’t require a complete overhaul of your workflows or a suite of fancy tools.
What it does require is intention: a commitment to listen earlier, act smarter, and build relationships with your users (even if they're internal).
If you’re wondering where to start, here’s your checklist for the next month:
✅ Create one feedback loop
✅ Run one Dev Check-In
✅ Pick one piece of feedback and close the loop
That’s it. Small, deliberate steps.
Remember: Agile thrives on iteration, and so should your feedback strategy.
Start by collecting the right signals. Set up lightweight collection points.
Make your users feel heard, and show them their input matters.
Because the best products, don’t just respond to feedback.
They grow because of it.
👉 What’s your biggest challenge in collecting feedback? Let’s discuss in the comments! 🚀
PS: I want to thank Andreas for his questions and challenges. Working with him as a pleasure. It’s not often we see Product people working in backend teams of massive systems take this kind of proactive approach to growing a product culture! If you agree, leave a nice comment for Andreas in the comments. I’ll deliver these to him!
At the Global Agile Summit we create the space for you to meet likeminded individuals, and form a community of pragmatic innovators! Get inspired, take action!
Join us in Tallinn, and help define a better way to develop and deliver software
