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 sett

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.