Full disclosure i'm a product manager- good PMs care about ship speed just as much as you do, they should also care about reducing the risk that what you ship will not solve the right problem for the customer or solve the right problem in the wrong way. A PM that nitpicks every little thing is doing it wrong. A PM that excludes engineering from the de-risking/validation process is doing it wrong. A PM that doesn't involve engineering at the earliest stage of the process is also doing it wrong. A PM that takes credit for the team's work, doesn't fight for the team and blames the team for missteps is also doing it wrong. There are many bad PMs out there (thus the hate for the profession among the HN crowd), I'm not saying I'm that good, but I'm trying.

You describe two separate items (that can build off each other, but are separate): - Not releasing as fast as you'd like - Bad schedule estimation/deadline setting

As with anything you want to change, you have to make the case that your idea is better for the business. What is the business value in pushing a feature to production today rather than letting it sit on the shelf until all stakeholders are satisfied it's ready? In the beginning you're scrambling to have a product online at all. Now that you have some users, how quickly do they need those new features? And how well do they respond to churn and/or half-baked implementations? Is not having those features costing you potential new customers? Answer these questions to yourself, honestly, and you'll have the beginnings of a case you can present for what turnaround time should be.

If you want to push back on scheduling, you have to get better at time estimates than the person setting the schedule. How are the changes to process causing more developer time to be spent? How do they impact wall-clock time to deployment? Once you know that, you can say "This timeline covers a preliminary implementation, but doesn't include time for PM review or iterating on that feedback, here's why..."

Frankly, you seem more concerned with your particular taste in release cadence than building a product.

Launch your own company and hire PM's that does things the right way.

(Then watch for anon HN posts complaining about you and your PM's styles :) )

PM chiming in here, but only for SaaS B2B. I work for a growing SaaS provider that caters to F500 companies. No PM I know of wants things to slow down, that's crazy. What I've seen though is that as a company gains customers, keeping them happy starts to raise in priority. Large customers customers in particular are extremely change averse. Some things I've seen:

- adding any bit of 3rd party software can be a nightmare, it might cause the entire contract to come under review again (like having a new analytics provider)

- some customers require 90 days notice of any material change in functionality, like moving a button to a new screen

- changes need to be communicated to marketing, CSM, and then to the admins of the customers

- and on and on

So I think that having many large customers, slowing things down just sort of happens. You can blame PMs or whatever, but it is just a thing that happens, at least with SaaS B2B companies.

If you want to remedy it, you'll need to take some time to figure out why it happens.

Sometimes, it happens because during the growth stage, a founder is in charge of product. Handing the reins to a hired PM is hard for even experienced founders to do. Sometimes, the tendency is to micromanage to such a point that the hired PM is more like a product administrator than a product manager.

Other times, it happens because as you reach scale, there's more risk to every release. It's one thing to move fast and break things when you have 100 customers. It's another thing entirely to move fast and break things when you have 10k customers and a wack of SLAs.

And still other times, it happens because developers haven't scaled with the company. Growth stage developers are a different breed than scale stage developers. As a company reaches scale, things generally need to get more formal and experts take favour over generalists.

Once you understand what's going on, you can start making changes. I don't know how to fix the issue where a founder has trouble giving up the reins, so when I worked for startups, I liked to stick with startups where a founder planned to stay in charge of product. Derisking a release is complicated and relies on strong communication between many departments. Scaling up to a scale stage developer requires being open to change.

How did "things got shipped nearly every day" work in practice? A common version of this is "the automated tests are passing, therefore it's good to go". But is your project manager actually on board with this, and if not where do their concerns lie?

It's possible that if you were to wave a copy of "The Phoenix Project" at them, they'd come back next week with the zeal of the converted. But I do think that there are valid arguments for not saying that everything that passes automated tests is releasable, especially when dealing with more interactive user-facing tools. Manual testing, especially when it's relatively exploratory rather than focussed on the "correctness" of specific features can be really valuable for making sure that the user interfaces are coherent and pleasant to use, and finding odd interactions which are hard to imagine when looking at the code. Perhaps your PM wants to see more of that? Is there a way to fit this in while maintaining a release frequency which everyone is happy with?

I've worked as a PM for a few startups and scale-ups and can confirm that sometimes one of our responsibilities is to slow down the release speed. Why? Because, after (and even before) the customer base passes a certain threshold in size and complexity, there are many more hidden variables in the "what and how to build" equation.

This being said, as a PM (or at least as the specific "story writing and prioritizing" sub-category of PMs known as a Product Owner) you sometimes have the feeling that you're adding complexity and overhead to the process without actually contributing much. I guess this is true mostly when you're new to the company and have a long way to becoming an integral part of the product development machine.

In addition, I have to agree with this line taken from another comment: "Growth stage developers are a different breed than scale stage developers. As a company reaches scale, things generally need to get more formal and experts take favour over generalists."

Product managers are valuable to have involved in product planning and design and in big picture acceptance testing, but they shouldn’t be gatekeepers. If you can, create a policy that prevents them from blocking deployment.

If you can’t do that: Give them access early when it’s still in a rough stage so that big things can be fixed early and so that they can feel they’ve had their way by reporting (obvious) real bugs instead of bikeshedding.

Then as you approach launch, set a cutoff date. Anything not fixed by then will be treated as a bug to be priorized and fixed as part of the general backlog.

Then the product manager can decide whether they’d rather fix their bikeshed nitpick or some other real bug.

I have tried it myself that Product wants to control what is going on, and I read the Phoenix Project which gives a pretty good description of your project. It is really good!

But the solution is really to introduce different kind of users that you can deploy to, so that you can deploy to the betausers without asking and if you can prove it improves the product then deploy it futher, just like Facebook have talked about as well.

Try to do things in smaller chunks. Can't nitpick something for weeks if there aren't that many details.

The longer people use your product, the more resistant they will be to unexpected changes in the product. One of a product manager's primary responsibilities is preparing customers for upcoming product changes so that they are well received.

PM's and other charlatans who are trying to trade on the software engineer's profession will use every trick in the book. They will try to sell you a car and headlights, wipers, tires separately. The reason they slow down projects is they want to sell each tiny part to executives as a big accomplishment. They don't really care about moving the needle and the tiny parts have high chance of success on the software dev side. What you need to understand is they are focused on spoon feeding dumb executives "huge" accomplishments. If you want to disrupt this, focus on this communication. For instance, finish the project ahead of time and find out how to communicate this to executives around the PM. When the PM tries to take credit for only a tiny bit of what was delivered and unaware of the rest, they will look like fools. When they seek retribution against you, try to amplify the fact they are out of the loop and trying to slow things down. You will have to be devious to carry out this strategy successfully, but PM's are people trying to sell what you spent decades learning to do for yourself, so all is fair.