How about a "no" to having product managers?
Master the Art of the Product Manager 'No'
21–30 of 173 posts
Re: Master the Art of the Product Manager 'No'
#22Earlier quoted context omitted.
Yes, but here be dragons, especially in front of customers (B2B sales). Sales Engineers for example are trained never to give the hard No to a customer request. Sometimes, they think they are saying no but the customer hears, "maybe". For example, "we'll consider adding that to the roadmap". Now the PM is stuck developing a single feature, the customer just got handed a stick to beat you with, and your CFO just got l…
Yep, I worked on a B2B product riddled with features that were there to make a sale. The success rate of those features converting to a sale was less than 20%, and none of those conversions were the whale clients. The features were typically well implemented and integrated with the rest of the product, and totally unused. The features added substantially to the complexity of the code base. It's funny to see HN defend…
Re: Master the Art of the Product Manager 'No'
#23One reason they persist in their insanity is everyone is an expert in giving excuses why their own team is too tied up with work to assist. Sure this reduces conflict over telling middle-management why their ideas are stupid, but in the long-run it's detrimental to the organisation to avoid explicitly hashing-out disagreements. Creating a culture where everyone lies to avoid hurting one another's feelings is not good.
Re: Master the Art of the Product Manager 'No'
#24Re: Master the Art of the Product Manager 'No'
#25There are many kinds of "negative" responses: 0. This idea is bad. 1. This idea is probably bad, but if someone wants to put together a more compelling argument we will discuss it at a future meeting. 2. This idea needs to be more fully developed before we can decide whether it is good or bad. 3. This idea is probably good, but it will remain in backlog limbo until someone makes a compelling argument that it is a pri…
1. The idea is technically feasible
2. The idea aligns with company's business goals
3. The idea is our team's responsibility and cannot be done by another team
4. The idea is more important than the other things our team plans to work on in the future
5. The idea is more time critical than the other things our team is working on now
If any of these cannot be proven, then it goes on the backlog as a P4 and nobody realistically will ever look at it. It's just the reality of corporate software building. There are always 10-50x more ideas than there are staff/time to work on.
Of course, all five of those can be, and often are, overridden by the Prime Directive:
0. One of the executives (often one of your grand-bosses high up on the totem pole) wants it.
Re: Master the Art of the Product Manager 'No'
#26There are many kinds of "negative" responses: 0. This idea is bad. 1. This idea is probably bad, but if someone wants to put together a more compelling argument we will discuss it at a future meeting. 2. This idea needs to be more fully developed before we can decide whether it is good or bad. 3. This idea is probably good, but it will remain in backlog limbo until someone makes a compelling argument that it is a pri…
In most companies I've worked, in order to actually implement an idea, you need to prove a few things, whether the person proposing it is the PM, an engineer, or any other person involved in the product: 1. The idea is technically feasible 2. The idea aligns with company's business goals 3. The idea is our team's responsibility and cannot be done by another team 4. The idea is more important than the other things our…
If you have to convince someone of all of those things in order to build some reasonably large thing over the space of a few weeks, that's probably reasonable.
If you have to convince someone of all of those things in order to allocate a few hours to fixing some tech debt or minor bug then your codebase is going to slowly deteriorate until the same someone is asking you why there's so many bugs and everything takes so long to develop.
Re: Master the Art of the Product Manager 'No'
#27Re: Master the Art of the Product Manager 'No'
#28Re: Master the Art of the Product Manager 'No'
#29Inside a company, I don't think there should be space for these sorts of responses. I can see these only being necessary/used where people are disenfranchised and not involved in setting or understanding the overall product priorities. But then I've always seen the PM's prioritisation role more as an expert mediator than a dictator...
Re: Master the Art of the Product Manager 'No'
#30There are many kinds of "negative" responses: 0. This idea is bad. 1. This idea is probably bad, but if someone wants to put together a more compelling argument we will discuss it at a future meeting. 2. This idea needs to be more fully developed before we can decide whether it is good or bad. 3. This idea is probably good, but it will remain in backlog limbo until someone makes a compelling argument that it is a pri…
Just be direct and realistic. If it's to a customer, "we'll add it to our backlog for review" and tag it as customer suggestion so it doesn't just sit there forever.