3 ms·

The reason a product owner can't handle all conceptual issues in advance is because he speaks english, and not logic Is there a reason the product owner can't

by mnutt 11y ago

The reason a product owner can't handle all conceptual issues in advance is because he speaks english, and not logic Is there a reason the product owner can't speak both english and logic? It seems like establishing mental models of how the application is working requires at least some level of logical thinking. In the past I have worked on projects where the product owner wasn't thinking only in terms of output and not how the application achieved its goals. The result was an initial overly simplistic happy path design, followed by developers poking holes in it, followed by the product owner adding a series of exceptions to the design to try to handle the edge cases. Neither side felt ownership of the mental model, and it turned out to be a mess.

jerf 11y ago
"Is there a reason the product owner can't speak both english and logic?" Theoretically no, but it's a big ask for one person. In reply to this entire chain, I'd suggest that it's actually something for the technical lead and the Product Manager to work out in conjunction with each other. For any team past about 4 people, it's just going to be too much to expect someone to both be the technical lead and be in contact with the users enough to be able to make those decisions. (A bit of crosstraining may be good, but trying to avoid that specialization is probably asking for trouble.) If the PM and the lead don't respect each other enough to make that work, you've got a people problem. There's a lot of people-problem ways to muck this up, unfortunately. (Most obviously, I'd contend that making the PM be above the tech lead is a very common failure case. If you can't trust anyone on the engineering team to have a roughly equal voice in the product design process... uhhh... that's a pretty big problem on its own!)
bsaul 11y ago
By speaking logic, i meant using a rigourous formalism to express processes and behaviors. Things like state diagrams, or code. But many specifications today are written in terms of user scenarios, or general definition, in english. A coder would fall in the same trap should he use the same formalism, only he would probably feel the need to specify its problem using rigourous design tools.
Too 11y ago
Oh god, the happy path fallacy. I've seen this too many times. Product manager comes up with conceptual model X, once implementation starts people it's brought to attention that X will only work under condition A,B,C, which together only occur for 5% of the users. Instead of reverting X, and trying out Y instead, the heavy train to finish X has already gained momentum and exceptions are added into the UI breaking the whole flow required for X to be intuitive. The sad part is that these unreasonable conditions are usually quite obvious to spot early on. I'm just making things up now but it can easily be things like requiring the user to hand over their bank log in details so that random startup can analyze their expenses, analytics that require write access to some big corporations sql database or that every user in the whole world uses Outlook 2007 and are willing to install our plugin.

by mnutt 11y ago

jerf 11y ago

"Is there a reason the product owner can't speak both english and logic?" Theoretically no, but it's a big ask for one person. In reply to this entire chain, I'd suggest that it's actually something for the technical lead and the Product Manager to work out in conjunction with each other. For any team past about 4 people, it's just going to be too much to expect someone to both be the technical lead and be in contact with the users enough to be able to make those decisions. (A bit of crosstraining may be good, but trying to avoid that specialization is probably asking for trouble.) If the PM and the lead don't respect each other enough to make that work, you've got a people problem. There's a lot of people-problem ways to muck this up, unfortunately. (Most obviously, I'd contend that making the PM be above the tech lead is a very common failure case. If you can't trust anyone on the engineering team to have a roughly equal voice in the product design process... uhhh... that's a pretty big problem on its own!)

bsaul 11y ago

By speaking logic, i meant using a rigourous formalism to express processes and behaviors. Things like state diagrams, or code. But many specifications today are written in terms of user scenarios, or general definition, in english. A coder would fall in the same trap should he use the same formalism, only he would probably feel the need to specify its problem using rigourous design tools.

Too 11y ago

Oh god, the happy path fallacy. I've seen this too many times. Product manager comes up with conceptual model X, once implementation starts people it's brought to attention that X will only work under condition A,B,C, which together only occur for 5% of the users. Instead of reverting X, and trying out Y instead, the heavy train to finish X has already gained momentum and exceptions are added into the UI breaking the whole flow required for X to be intuitive. The sad part is that these unreasonable conditions are usually quite obvious to spot early on. I'm just making things up now but it can easily be things like requiring the user to hand over their bank log in details so that random startup can analyze their expenses, analytics that require write access to some big corporations sql database or that every user in the whole world uses Outlook 2007 and are willing to install our plugin.