5 ms·
I agree that everyone should feel responsible for fulfilling their part of the contract, not just in the most shallow way. > "the product requirements only sai
by ls15 4y ago
I agree that everyone should feel responsible for fulfilling their part of the contract, not just in the most shallow way.
> "the product requirements only said there should be a Save button, not that the data should be saved"
If these were really the requirements, then the PO's salary should be split and go to the developers, because they would need to do that job anyway and at least do not get distracted by an incompetent PO.
- morelisp 4y agoYou think a PO is incompetent if they hand over a mockup with a "Save" button and not a 200 page document that among every other detail says "Clicking or otherwise depressing the 'Save' button should persist the information in fields A, B, and C into the database within 500ms" or some such overspecification? We're selling ads, not sending people to the moon. This kind of culture eventually produces the equivalent stupid formalization on the dev side like "all modules must have at least 99.85% coverage and a three-phase UML diagram review by the architecture team before deployment". Better to have some slack and people willing to use common sense on both sides.
- ls15 4y agoI think a PO is mostly useless if they do not provide a clear set of acceptance criteria. Low-effort requirement descriptions are just shifting the responsibility to the developers, because they leave too much room for interpretation. Lack of technical understanding is another common source of friction. TBH, the best PO that I worked with has a CS degree.
- willcipriano 4y agoI agree. I'd expect a huge compensation gap between someone who types up "make a save button" when the user says "I want to save", and some who comes up with "Users wish to persist state between uses of the application, therefore we want to retain the users current balance, brightness setting..." The former shouldn't be paid more than a front desk receptionist, and I'll keep the difference since I'll be picking up the rest of the role.
- morelisp 4y agoI did say "a mockup with a Save button", not "a rock with 'Save plz' carved into it thrown through the devs' office window." Yes, the PO has to care too. I guess count yourselves lucky you've only had bad POs and not bad POs and bad developers.
- willcipriano 4y agoMockup is great if you are just working on the front end, but what is the save button actually supposed to do? I can figure that out, talk to the users and understand what they want to save, but I feel like that's the product owners job.
- morelisp 4y agoI can't tell if you're missing the forest for the trees here, or trying to embody the exact annoying response I'm talking about.
- lupire 4y agoWe'll need to escalate to the PO of Poe's Law to get a more precise spec.
- willcipriano 4y agoI'd better watch or the two of you will tell someone else to write a funny comment and then use that as evidence for how hilarious you are.
- ls15 4y agoI think we are talking about different complexities of projects. In a complex project in a complex environment in a team larger than 2, a mockup often does not cut it. I've seen underspecified requirements leading to misunderstandings countless times. I have never seen a situation where I thought that writing down those 5-15 acceptance criteria upfront was a waste of time. The discussions that follow when a deadline was missed because of misunderstandings feel much more like a waste of time to me. In a simple project a mockup can be enough, but then what do you need a PO for?
- morelisp 4y agoThe absolute worst PO I ever worked with had a CS degree, and kept asking stuff like "why aren't you using MVC" and specifying technical details that wouldn't work rather than a product vision. Deep technical knowledge can help a PO, especially in technical products, but it should not be influencing how they present to the dev team. Otherwise they're just another even-less-accountable architecture astronaut.