I dlatego bardzo często dojrzałe firmy dają się tak łatwo wygryźć z rynku startupom :P
Planowanie produktu wyłącznie przez ludzi, którzy nie mają styczności z kodem, jest suboptymalne i zwykle się nie udaje.
Programista / architekt: zwykle wie, co technicznie można zrealizować i jakim kosztem; nie zawsze wie, czego chce biznes
Product manager: zwykle wie, czego chce biznes, ale nie zawsze wie, co się da zrealizować i jakim kosztem; czasem miewa nierealistyczne pomysły, a czasem odwrotnie - nie wie, że jakiś potrzebny ficzer można zrobić w godzinę.
Dlatego planowanie produktu należy robić przy udziale obydwu stron i dbać o obustronną komunikację.
U nas przytłaczająca liczba ficzerów jest z inicjatywy oddolnej, a pomysły z góry też są zawsze konsultowane z programistami.
Oprócz tego nie można robić nic, co nie przyniesie zysku firmie
Zakładając, że nie ma się programistów o ujemnej produktywności lub złośliwców psujących kod, każda rzecz przynosi jakiś zysk firmie. Pozostaje kwestia priorytetyzacji.
Poza tym programista to nie maszyna, która robi stałą liczbę np. 5 ficzerów na sprint i jak zaplanujesz 2 ficzery więcej, to musisz zrezygnować z 2 innych.
Jeśli programistom dasz do roboty coś, czego nie lubią i czemu wewnętrznie się sprzeciwiają, to będą to dłubać przez 2 lata i wyjdzie z tego jakiś korporacyjny syf. Jeśli pozwolisz im pracować nad tym co lubią, i tylko trochę to ukierunkujesz, to nagle może się okazać, że ten sam zespół ma 10x większą produktywność.