Hacker News Reader

Comment by gregmac | Hacker News Reader

When prioritizing, it's not always obvious which items are big vs small. How do you provide that feedback to PM during prioritization?

Sometimes implementing what should be a simple feature requires a month of refactoring some old technical debt. And sometimes what seems like a very complex feature is actually just a matter of enabling a flag on some third party component you're already using.

All is us have likely experienced "why is x taking so long?? Had we known, we wouldn't have done it now!" and/or "we didn't realize y was so simple, otherwise we would have done it months ago and probably won a few more deals!" How do you avoid that?

View on HN

I think that last paragraph has a clue as to the problem and solution. Those questions all are assuming someone other than the devs are responsible for deciding things. If the devs are making those calls, they won't wonder why things are taking so long or what could have been simple. PMs should help act as an intermediary with the customer and convey that domain information to the devs but shouldn't have any real say over the roadmap or features as they don't have the knowledge or experience to make those calls.

> When prioritizing, it's not always obvious which items are big vs small.

Why does the size of the work that needs to get done matter? If you need it you need it. If you don't, you don't. If you want a fast fix, note it. Speak in outcomes. "The lowest amount of work possible to get us ________"

> All is us have likely experienced "why is x taking so long??

I wouldn't work with a PM that disrespected me like that.

> Had we known, we wouldn't have done it now!" and/or "we didn't realize y was so simple, otherwise we would have done it months ago and probably won a few more deals!" How do you avoid that?

This isn't prioritization, it's a PM making ill-informed judgements on dev work. Don't have your PMs do that. Product people can define priority, scope, etc. If your PM isn't prioritizing something because they think it takes a long time, they do not understand their role.

> Why does the size of the work that needs to get done matter? If you need it you need it.

Generally, I would agree, but I've seen cases where it mattered, because the value of a feature would become 0 after a set date. For instance, we needed a specific feature to fulfill the requirements for a (massive) contract, and you could only apply for the contract until a specific date. The value of this feature outside this scope was pretty much zero.

> Generally, I would agree, but I've seen cases where it mattered, because the value of a feature would become 0 after a set date. For instance, we needed a specific feature to fulfill the requirements for a (massive) contract

As I said, you put it at the top of the backlog and alert the team of a new deadline. You work on it until the deadline. If you make it, great, if not, you move on. Asking for an estimate wouldn't have made you make it, it might've only prevented you from trying.

But not trying something very unlikely to succeed sounds valuable to me. Why waste 2 months of engineering time if your engineering team is convinced it will take at least 6 months?

Reply on news.ycombinator.com