5 ms·
In my experience it is the opposite of that. Many ‘product’ groups exist because engineering teams kept complaining about meetings and just wanted to be told w
by dpeck 6y ago
In my experience it is the opposite of that. Many ‘product’ groups exist because engineering teams kept complaining about meetings and just wanted to be told what the build. Collectively as a profession we have ceded away many of the things that made software development unique and powerful over the last 10 or so years.
- spamizbad 6y agoThis is true, but I've also seen "product leaders" in organizations not articulate a clear vision, requiring the engineering staff to do a Socratic-like process to pull tangible requirements out of said "product leader". It's a tedious process so I'm not surprised engineers throw their hands up and just have a PM do it. I do think SV puts more trust in their engineering teams to produce polished software, whereas other companies will burn through tons of dev resources over nit-picking or implementing speculative edge-cases.
- dpeck 6y agoCompletely agree, same thing has led to massive growth of product mangers, product owners, and various other titles that do similar things. The devs still tend to have to ask a lot of questions to get anywhere useful but in these situations the P* roles at least give them some traction to work from and get movement.
- throwaway11121 6y agoFrankly, since I've moved to the Netherlands, every project I worked in seemed to exist exclusively to justify a comfy, lazy job for incompetent Dutch POs, scrum masters,"customer journey experts", copywriters, designers. There is way too much money in this country and an incredible amount of bullshit jobs.
- vinay_ys 6y agoJunior engineers and PMs need the software to have a skeletal structure on which they can hang their features. This skeletal structure has to be put together by the lead engineer and lead PM. Usually I see both PMs and engineers churning with bad design when such a clarifying structure is missing or ill-defined or has become broken due to hard pivots in pursuit of business/product-market fit.
- PeterisP 6y agoOn the other hand, I can certainly imagine situations where the requirements aren't "hardcoded" but rather they are flexible and heavily driven by what's feasible and what's hard from the engineering perspective (so they can't be "pulled out" from the product leader), and determining that vision properly requires involvement of engineers and can't [technically can, but the outcomes suck] be prepared by someone else and just handed off to engineering.
- pc86 6y ago> requiring the engineering staff to do a Socratic-like process to pull tangible requirements out If you've got good business analysts, this is what they're supposed to be doing. I think if you have great product people, great business analysts, and great developers, the system of PO-Analyst-Developer can work. The problem is that BAs and product people aren't generally making a ton of money, so the great ones will move on to more lucrative positions, and great developers get bored quickly if they're just given a list of JIRA tickets. So pretty soon, one of the three things breaks down then all hell breaks loose. The product folks don't have a clear business vision. The analysts are soft technically and don't know what questions to ask. The developers are either building a space shuttle when they need a bike, or they don't know how to build the bike in the first place.
- pc86 6y agoI would tweak that just a bit that bad developers just want to be told what to build. The best engineers I've ever worked with and for were constantly asking "why" and would get incredibly frustrated in this "Product Owner runs the backlog" type of organization.