I'm only speaking from my experience, but we shipped things quicker and were better received, and I'm curious if part of that reason is that, for the first time in my career, product didn't start with a background in the target domain. I wouldn't say this area is simple either. We deal with a lot of features on the merchant side of things (ecommerce).<p>I also don't doubt a lot of other factors came into play, but I want to focus on the product's background for a moment. One thing that stood out to me was that there were less arguments to push for something just because it's been done in other software for the past two decades. Which very well may be true, but uncertainty pushes my current PMs to investigate.<p>It's almost like we're starting from a blank slate and only adding the essential parts. They do take cues from other existing products, but I love how their attitude defaults to challenging them. We're also fortunate enough to have good relationships with our clients in order to validate our ideas. But we're not letting them lead the direction of the product.<p>Because that's what I feel sometimes with PMs rooted with deep domain knowledge. What we're building is being designed by a customer. This not only has the potential to make it less user friendly (UX designers feel less empowered to challenge them because the PM has relevant background while they don't), but it cascades down to the engineers with the amount of work that's been added.<p>I won't dismiss that that a PM can have both a background and release good products. But why do certain companies make it necessary for *all* PMs to have such backgrounds?
Maybe you lucked out and got a good PM who listens.<p>Knowledge is not a bad thing. The problem is that some people think they know everything and stopped listening to others. They take competing ideas and criticism as a challenge to their authority.