[sauercrowd]

This describes quite well the huge advantage small companies have vs big companies.

(Motivated) people at small companies "care", and what I mean with that is they are responsible and can see a large enough portion of the customer experience that - if something is broken - they'll see the pain and try to address it.

At a big company no one cares. They of course care about their job, but their job is such a small fraction of the overall customer experience, that seeing their work having an impact on their customer is exceptionally difficult.

That's why large companies need to encode customer feedback into a system to imitate feedback cycles. Mostly in metrics. That's a very lossy way to capture signal, and leaves a lot to be desired, but so far it doesnt seem like anyone has come up with a better system.

[TulliusCicero]

> That's why large companies need to encode customer feedback into a system to imitate feedback cycles. Mostly in metrics. That's a very lossy way to capture signal, and leaves a lot to be desired, but so far it doesnt seem like anyone has come up with a better system.

The other thing you can do is having senior leadership occasionally try the product themselves and talk directly to customers (especially ones that have problems).

Often, problems remain because of bureaucratic hurdles, or disputes between different fiefdoms: there's a feature that needs teams X and Y to improve, but it would only help the internal metrics for team X, so team Y doesn't give a shit and drags their feet. Leaders who are sufficiently high in the hierarchy can cut through these sorts of problems if they know and care.

[throwaway416430]

I manage post sales support at a small company where this theme is present, however, I'm concerned that things may be slipping in the wrong direction. I need help dealing with this situation.

Our software engineering team is burdened with tech debt and aggressive product roadmap. Understandably, they often feel the need to push back and keep things under control. Our customers and the employees who are accountable to our customers literally lose sleep when things aren't going well. Our engineering team feels complacent to function on a 9-5 schedule and sleep on critical issues for weeks.

The only thing the engineering team appears motivated to actually own is the next iteration of the escalation process that somehow makes them even less accountable. Invariably the next iteration includes adding more details to Jira tickets that nobody will read.

Basically no one on that team is dogfooding the product. Broken features are being shipped and they are expecting us to actually sell and support this.

[sauercrowd]

Here's what I'd suggest

1. There needs to be reframing of the engineer role in the team, by the leadership. It's not just to build things, but to help the customer. The job of the engineer is to build a good product for the customer, not just to "build", fix Jiras, ...

2. At the same time, get some engineers on customer calls. It doesnt need to be everyone, but you need to shorten the feedback cycle that engineers directly get signal from their users. A lot of information gets lost through Jira's, intermediates, ...

They dont have need talk, just listen. Will they pay attention? That comes back to the reframing of their job being to create a good product for users. If everyone understands that's the goal, they will.

If you have engineers building custom extensions for your database, because your CRM product needs some low level performance optimizations - it'll still be good but less interesting.

The goal is to get some engineers talking to customers, cause they'll talk to other engineers. And engineers know how to talk to engineers. It'll shorten the feedback cycle, and that's good for both speed + signal.

Now I don't know how much of that you already do, and they might even do all these things already, and what you see is the output of the worst issues already taken care of. If the latter is the case, there's some more cross team comms needed