
Ask HN: How to deal with product managers slowing down product release cycle? - throwaway_0123
Every startup I&#x27;ve been at, when the company&#x27;s in the &#x27;growth stage&#x27;, things get shipped nearly every day. It&#x27;s great, and gives the team more control over the product and iterations. However, as always, once growth hits a certain point, people in charge of product are hired. After that, things slow down considerably. It drives me crazy. We go from shipping daily, to not releasing features for WEEKS because they nit pick every little damn thing. And of course, &#x27;crunch time&#x27; happens more frequently because projects take forever to push forward, causing the arbitrary deadlines to be missed.<p>Is this normal for startups or have I simply been unlucky? Anything I can do to remedy?
======
olegious
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.

------
finnthehuman
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.

------
gesman
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 :) )

------
idoh
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.

------
hluska
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.

------
dasmoth
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?

------
bgdnpn
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."

------
cimmanom
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.

------
kevinsimper
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.

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

------
itronitron
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.

------
codeonfire
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.

