https://news.ycombinator.com/item?id=22827275
bah grosso merdo faut faire comprendre aux mecs en face qu’on bosse tous ensemble (donc pas les voir comme “les mecs en face” justement)
et à partir du moment ou ils sont “intégrés” au fonctionnement
bah ils comprennent que changer d’avis / les prios etc ça a un impact sur les délais ..
ils ont tout à fait le droit de changer
juste ça a un impact et s’ils sont intégrés et qu’les échanges sont OK ils le comprennent
lorsque c’est un proxy PO il doit justement aider le dialogue, comment faciliter les trucs entre ce qui est faisable techniquement “rapidement” etc, les compromis possibles, ‘fin bref
mais le PO doit servir à établir le besoin aussi
après c’est selon les équipes les fonctionnements le business
tout est un peu flexible
sur comment on va établir le besoin
le principe d’agilité c’est d’avoir du feedback rapide et constamment pour pouvoir pivoter si on part sur un truc qui va pas etc etc
perso je l’ai vu les grands méchants du management qui établissent des besoins inatteignables et tout
et après tu discutes avec eux et bah non enfaites tout l’monde est logique, t’expliques les trucs, ça se passe bien, compromis pour arriver au truc qui leur va le mieux dans les délais, the end
c’est pas toujours le cas évidemment
encore une fois y’a pas “un seul” fonctionnement de team, des fois ça va être à l’équipe de dev d’avoir des connaissances fonctionnelles pour apporter des solutions et contribuer aux échanges, des fois tout va descendre d’une tour d’ivoire (bon ça fonctionne rarement), des fois c’est juste le PO qui a vraiment les connaissances et tu vas juste chercher à l’implémenter du mieux possible, des fois le PO fais proxy d’une autre team qui a le besoin, etc etc
capkutay :
There’s no way to answer this in a comment…you can take a full course on tech product management and still not have all the answers. But I’ll at least offer some advice:
Just be very good at measuring and presenting data from all the channels in your company. Your customers, your prospective customers, your customer engineers, your sales people, your support team, your engineering managers, directly from developers too.
Understand the real cost of each feature. That’s not easy. Try to predict the real value of each feature. That can be even harder. How many customers are asking for that feature? What’s the avg LTV of that cohort? Will the feature reduce churn? By what percentage? Own those metrics and tell the whole company that’s why you’re prioritizing those specific features.
Be prepared to go back and check your assumptions and see if your predictions were correct…If you were wrong, then your next job is figuring out why and then working towards improving your own models to predict the value/cost of each feature. The fact is once you start intensely measuring that type of data, you’ll find lots of gaps in your own process and fixing it as you go.