Another way to solve this problem is to have engineers on customer support rotation of some sort. This way, engineers get to see how their software is used in the wild and interact with customers, and PMs get to see how unrealistic expectations and deadlines comes back to bite you in the ass in a form of your engineers being busy fixing half assed crap.
This sounds great in theory, in practice working on any non-trivial software means there are parts you know little-nothing about. Having spent time on support duty I'd end up pinging team members for help (disturbing people without having a sense of priority since I don't do support), budding into other people's stuff without the capacity or desire to follow it up long term.
The best way I saw to get devs into customers shoes is to let developers be involved in client rollout - like ship then on-site and see how people use the feature they wrote.
But frankly even then, devs shouldn't be making a lot of these ae user facing decisions, send the UX guy.
Few things I noticed that made this work in practice:
* Engineers pair up for few rotations with other engineers who are experienced in interacting with customers, triaging issues, troubleshooting issues across the system and identifying which internal service is causing issue and ping the team that supports it and/or move it to their support queue.
* The goal is not to fix every single bug or issue in the queue. Prioritize incoming tickets and gather as much information as possible before moving it to some team's backlog. Solve only problems that you think are manageable within the length of your support rotation.
* One engineer per team or owners of a set of services should on the rotation (this again depends on how teams are organized already).
* Pair with customer support or customer success agents when dealing with difficult customers, situations or need help communication-wise in general.
* Bring in these bugs to your team and make sure stakeholders are aware of them. This is important especially when the team ships something and moves on to the next thing thinking they have 100% capacity for the new project. This is another feedback channel that PMs should be aware of.
* Engineers on support rotation are exempt from their team duties while on support. Again, this communicates what capacity the team will be operating on in the next week or two.
I learned so much about other parts of our product and APIs, how users interact with it, and most importantly (for me at least, since that was the new part) working with people in the company who are not in engineering or product!
I've worked (as a dev) in a customer-facing industry where devs are generally divorced from customers. Working in support has helped me understand the codebase better (because yes, you usually don't know it all that well if you just fix bugs and build features) and helped me to (at the time) connect with the value some people get out of it. That was nice.
What was less nice is dealing with the angry minority of customers. That was I would say significantly more unpleasant than dealing with the happy minority was pleasant. For that reason I would not recommend interfacing with customers for anyone. There is a reason support agents have such a high turnover.
It's really motivating to hear customers are happy and I don't know why a PM wouldn't share that good news.
However, sometimes the problem is just technical, and every game of telephone makes it worse. I have had two week back-and-forths which were eventually resolved by the agreement that OK, this nerd who does our implementation (me) can be on a teleconference with your nerd who does your implementation so long as us grown-ups are also in the call - and then it takes maybe five minutes to get to "No the digit five. Not the word five, the digit five." "Oh! Oh Wow. I never considered that. Sorry. Yes, it works now." and we're done.
I really valued time spent shadowing people using my software, one of our tools was for call takers, and I could see that the thing they're all kinda used to but have to keep working around is a thing I can fix with a CSS tweak, whereas the change their manager tells us should be prioritised is going to take months. I can land the tiny improvement next week, and make their lives better while their manager argues with my manager about whether the big piece of work is P2 or P3 and so on. The role I'm in theory taking next (if they get their act together and issue me a contract to sign) is more user contact again, and I look forward to being able to make people's lives better directly.
Asking them to tell you next time doesn’t always work since they just cannot imagine that the thing that takes them hours a day can be fixed in 5 minutes, forever. I think they unconsiously don’t want their hard work devalued like that.
That’s what a good tech lead with a robust roadmap is for.
PMs sprung out of the notion that engineers are anti-social and need someone to keep customers/internal teams at bay so eng can focus on coding.
Of course in reality there are plenty of highly competent tech leads who can both negotiate with customers on a roadmap and build it.
That's where you'd want a PM brought in, the tech lead ideally would work together with the PM on the roadmap, in that technology must be considered when designing a roadmap, feasibility, effort needed, technical complexities, needed tech dept pay backs, needed redesigns, infrastructure upgrades, security considerations, etc. As well as being consulted for what can tech realistically provide as means to solve problems, etc.
That's why I think a PM is needed, so the tech lead can focus on leading the technology, while the PM focuses on capturing requirements, getting funding, coordinating the launch, and all that.
Ideally, there's also a separate dev manager, so the tech lead doesn't have to worry about employee resourcing, project allocation, hiring, compensation, promotion, needs/wants, vacation time, performance, etc.
For all these things, the tech lead should be consulted and have a voice, but freeing them from all this work is definitely a plus, why have your most experienced developer do all this management work?
The reason PMs exist is because it’s a full time job, just like most roles. Being an engineer and/or tech lead is also a full time job. In larger companies, we tend to split out full time jobs. Often in small startups, people have multiple roles. So in a small company you might see someone talking to customers and engineering. In a large company, it’s far more likely that the engineer and the PM are two different people.