There are some nuggets of wisdom in this article, but I think it's very clouded by a certain perspective. I normally don't comment, but feel that it's important to slice what I feel is useful and what can be detrimental behavior as a PM.
As a PM of about 4-years of experience, I understand the author's concerns and at the same time believe that he has solved for the wrong problem; his own anxiety rather than team cohesiveness and trust. The issues he solves for can be solved in different ways without such a negative impact on the team, actually in a very positive manner that increases trust, cohesiveness, and user context.
I'd first like to point out that I've made the mistakes of micromanagement that he mentions in the first section. I also quickly learned how detrimental that behavior is to team relationships, productivity, and outcomes. I'm certainly not perfect!
The way the author solves the problem of pace is by creating regular check-ins every half day. He then goes on to identify, how these check-ins can be used as open to monitor common slow-downs: engineering struggle and product context (he calls is product debt).
I'd first like to make the point that some other engineers have commented here, estimates are estimates, we are agile, you learn things along the way and need to adapt. I believe your job as a PM is not to hold the team to estimates, it is to come up with creative solution and serve as a master facilitator on your team.
So when the author says the following I can't help but notice the irony. I'd explore us all to practice what we preach. Instead care about iterations (sprints) not task micromanagement:
"As a product manager (PM), I often make assumptions as to when a particular user story will be delivered. This is painful because I don’t believe in time estimates and don’t think I should be involved in estimating the relative complexity of a story since I don’t own its implementation.
I know I shouldn’t but I can’t help doing it anyway…"
So how do you solve the problems that the author points to "struggle" and "context" without adding interruptions?
• For struggle, that is what standup is for. Not only standup, but if you create a culture of trust engineers will naturally reach out if they hit road blocks, make a slack channel for your team. It's even better if you can teach your team about red flags, things that the article says which are true to look out for: complexity is rapidly increasing, not feeling confident in the stack/codebase. For any of this to work you MUST create a culture of questions and answers. Yes, all want to look competent, but what's also great is being able to depend on your team.
• Adding to the previous point, this is why small tasks are soo important, [read this book on product flow](https://www.amazon.com/dp/B007TKU0O0/ref=dp-kindle-redirect?...) if complexity is small to begin with you can avoid that issue AND you get the added benefit of smaller iterations, meaning faster red flags. The author points this out too, this is critically important.
• For context, context is king. Want to avoid "Product debt", get your team/tech lead involved from Day 0 of your quarterly/yearly roadmap, they should know everything about the user that the PM does minus the RAW research effort. Run a Kickoff/Inception/IPM that truly integrates your entire team, every engineer should have product context. Devs will then see tricky edge cases, radiate them up to the PM and you can make a call together if the work is necessary.
All of this is to say that there are some good parts of this article, but I think that adding one more check-in is not necessary when there are other ways to solve the problems identified.