Be careful about hiring product managers. TFA warns that they can become a glorified backlog groomer and black hole for tickets. They can also become another point in a game of broken telephone between your users and your engineers. If this starts to happen in your organization it can cause a lot of dysfunction.
The key for me has always been: talk to your users. If your software engineers don’t know at least some of the users on a first name basis they need to step it up. Software engineers are generally a well educated bunch who are capable of listening to users and prioritizing work when given the chance.
A good product manager is going to know that and work with the team to provide extra support above and beyond those capabilities. They should enable teams to scale with the number of customers but not be the single point of contact with them.
It’s all about communication and playing broken telephone with error reports, requirements gathering, etc is a quick way to lose team effectiveness over time.
Software engineers need to step it up ? Many times organizations purposefully put distance between customers and engineers. I like working with the customer directly , but it can be easy to put your foot in your mouth when you are so far away from the contract. Bad customers may also try to exploit this lack of knowledge and ask for extra work outside the contract scope.
I agree, but I am a little biased here as a product owner. Developers like to code. It's what they were hired to do, and it's what generates the most value the fastest. Anything which pulls a developer into meetings is lost productivity. There are occasions for devs to speak with end users; during, for example, refinement and demos. However unless I am vigilant, the developers quickly end up spending most of their time wasted in meetings with four other managers.
You hit the nail on the head: developers aren't well versed in customer and office politics, and most of them don't want to be. I am, as part of my job, and I know who is trying to muscle their pet project into the next sprint. I am the buffer; the diplomat and negotiator; and my team seems very happy with this arrangement.
I’m suggesting that developers should know some of their users as people who use their software and talk to them semi-regularly. Especially when your company is small and still trying to find a market fit.
Beeing a Product Manager myself I agree there can be a risk. But there are other situations that demand alot of work like I am now doing: The product is customer facing and has been developed for years with marginal success. Management expects now a new direction backed by insighths and data.
Drawing multiple scenarios of new strategies, talking to customers, setting up market research and getting sometimes pushed back hard is a fulltime job. And I didn’t even get started about traveling globally to meet customers and go to conferences. I just barely can keep up on the side with new technology and trends.
A good PM should be able to do this grindwork and get as much as possible insights to bring it to engineers and bring engineers closer to customers.
I think one doesn’t need multiple PMs and especially not PO to only groom backlogs, here I agree with you. But there is alot of work in dealing with uncertainty, ideas, strategies and put onto paper to have good discussions/discovery.
> If your software engineers don’t know at least some of the users on a first name basis they need to step it up.
I have both customer support and developer experience. The customers your engineers will know on a first-name basis are probably the troublemakers: the ones who consume $100,000 in support costs for a $20,000 contract; the ones who always have another "helpful" suggestion for irrelevant new features; the ones who have psychological issues and form parasocial relationships with your team because even their own coworkers can't handle them. I have personally seen all these things several times over.
Not to say that dev staff talking to customers is bad, just that it's very human and you have to watch out for all manner of things you wouldn't expect from reading some abstract blog post.
Product should be the glue between teams and create efficient flow of data between stakeholders.
Imo the problem with Product Manager is it's a catchall term when there are 4 types.
Research, OPS, UX/UI and technical. They are all very different in their execution and value but they are seen by some as 'you manage the backlog but with data to prove my ideas aren't wrong'
Zero point of having a PM if this is how they get deployed.
It's too bad as the role, when assigned and matched well, can cut through to the core pain points.
Also 100% agree, you want to talk to high, medium and low supporters to get a good map.
For one I worked at, I deployed receptive.io (now part of Pendo) and it showed every customer demographic wanted a specific feature and ALL their great ideas where shit on by the users.
The echo chamber at C level is, imo, the reason PMs get sidelined.
> The echo chamber at C level is, imo, the reason PMs get sidelined.
I spent a lot of my time at my last job trying to ascertain the business value of strategic projects - for which there appeared to be no business cases - while explaining to my end users who had strong businesses cases why their projects wouldn't be completed any time soon. Eventually it became clear that I was supposed to just make up some numbers to justify the work on the strategic projects; business value be damned. C level sometimes forgets their big ideas have enormous opportunity cost involved, and that they, too, should be able to justify the EFTs.
The key for me has always been: talk to your users. If your software engineers don’t know at least some of the users on a first name basis they need to step it up. Software engineers are generally a well educated bunch who are capable of listening to users and prioritizing work when given the chance.
A good product manager is going to know that and work with the team to provide extra support above and beyond those capabilities. They should enable teams to scale with the number of customers but not be the single point of contact with them.
It’s all about communication and playing broken telephone with error reports, requirements gathering, etc is a quick way to lose team effectiveness over time.