I don't believe his view conflicts with yours.
I think it's very possible to have someone present to help define value and priorities, and focus on the people part of getting shit built, while giving engineers a lot of creative involvement and ownership.
I've lucked out and most plans I've worked with are super, super high level and gives everyone a lot of freedom.
Fowler cites Jack Reeves, who said that the parallel to a construction blueprint is not some UML diagram but the source code. Therefore all programmers are designers. Programming has a parallel to construction workers, but they are not people, they are the compiler and linker.
Software would should, as much as possible, be design of novel things. And the only way we know whether something novel really works is to see what happens when people use it. The shorter that feedback loop, the more effective we can be.
Usually products without someone filling the product manager (not project manager) role in some way suffer for it.
> Product Management is mostly about consistent execution of plans, not painting high-level visions.
It's a common view that software developers are an output device, like a printer. You tell them what to build by sending them very detailed instructions. They follow the instructions to the letter, and their work is judged by compliance. Perfection is perfectly conforming to some one else's plan.
I think this is bunk. It might have made a little sense when releases were every 18 months to 3 years. But in an age where companies are releasing dozens of times per day [1], it's foolish. Perfectly following a plan means you believe nobody will learn anything during the time it takes to follow the plan. But if you are releasing early and often, you can learn a ton from users. You can be much more innovative and much more effective than competition.
That only happens, though, if you treat team members not as rote plan-followers but as creative professionals who are deep collaborators. Where vision isn't something a few HiPPOs hammer out in exclusive twice-annual sessions, but where everyone constantly participates and refines it. If a company's process has already shut down collaboration, then of course the difficulties of remote collaboration aren't a problem. The challenge -- still unsolved, I think -- is how to maintain both a high level of collaboration and fast iteration without having to have everyone together.
[1] E.g., https://www.infoq.com/news/2014/03/etsy-deploy-50-times-a-da...