4 ms·

Such a cool article! Reminds me of a tip I got from a friend: "Never ask the product owner what to do in an edge case." "So what should our product do if the d

Such a cool article! Reminds me of a tip I got from a friend: "Never ask the product owner what to do in an edge case." "So what should our product do if the definition of the official timezone in Amsterdam changes relative to UTC?"

spacemanmatt 5y ago
I think the point here is, timezones change regularly and it's not an edge case.
- anticristi 5y ago
  I agree that it's not an edge case for devs, but I do think it's an edge case for POs in the EU. My friend was even struggling with conversations like "so what if the user hits save exactly when data coverage drops". Not an edge case for techies, but likely an edge case for POs.
  - jonathanlydall 5y ago
    > My friend was even struggling with conversations like "so what if the user hits save exactly when data coverage drops". My favourite PO response to a question like that is "Oh, I suppose that could happen, but it would be very rare so don't worry about that", at which point you need to re-iterate that even if rare, we still have to do decide what should happen, even if it's just showing an error to try again.
rendall 5y ago
> "Never ask the product owner what to do in an edge case." Could you expand on that? I've found it best to keep PMs informed even about edge cases, but I'm curious to know what your friend meant? I usually don't ask, but say something like "We store time as UTC for future events, but apparently this is not the best practice because when timezone rules change, the local time is not updated. Setting up that refactor will be medium complexity. I recommend we take the time to fix it now, so that we will not have awkward moments for event organizers as people show up an hour early."
- anticristi 5y ago
  He was referring to cases like the PM being a highly skilled person with clinical trials. The PM already knows a lot about regulations, customers, what problems can be "automated" away with software, etc. The PM is likely trained in life science or medicine, and never coded themselves. One might be tempted to ask the PM to decide on the following: What should happen if the user clicks "save" but the network went down? Shall we retry a few times? How many times? With what backoff? Or shall the application be offline-first? How should potential conflicts between the server data and the client data be resolved? As you can imagine, the PM has already enough on their plate, so, in my experience, it's best to not overwhelm the PM with such questions and take a decision based on "best guess" on what would maximize customer success. Another anecdote: A PM had to prioritize "integrate with Lufthansa" and "migrate to Java 8". Clearly the latter issue is at the wrong level of detail for a PM.
- marcosdumay 5y ago
  The PM never has a good answer, and never has any idea on the problems his answer will cause. If he had an answer, you would receive the situation as a requirement, not as an edge case. So, if you go ask him, you could as well ask some random strange on the street and it would be as useful. Some times the end user knows the answer, but very often their opinion is equally useless.
  - rendall 5y ago
    > The PM never has a good answer Hmm. Perhaps I've had good luck with PMs. I've actually generally been impressed by some of the insights I've received from PMs about how to prioritize business interests. Most recently, there was a question of what to do in the case that data coming from the client is inconsistent with what is on the server. The proposal was to throw an error. PM said that, whatever we do, it should not interrupt or block communication, which answer simplified the remaining discussion.
    - marcosdumay 5y ago
      Well, notice that the answer came in the form of a requirement. The PM just forgot to tell you that one up-front. Also, your conversation doesn't reflect you asking him what to do. You made a proposal, and he clarified the requirements. He didn't tell you what to do. I wasn't very clear on my post, but the way you did is the one that works. You go to the PM with an answer, and he says if it's acceptable (or why not). You know how to weight the technical details, he doesn't, he knows about the business details. So your proposal should be reasonable, but there isn't any expectation about any one he comes up with.

spacemanmatt 5y ago

I think the point here is, timezones change regularly and it's not an edge case.

anticristi 5y ago
I agree that it's not an edge case for devs, but I do think it's an edge case for POs in the EU. My friend was even struggling with conversations like "so what if the user hits save exactly when data coverage drops". Not an edge case for techies, but likely an edge case for POs.
- jonathanlydall 5y ago
  > My friend was even struggling with conversations like "so what if the user hits save exactly when data coverage drops". My favourite PO response to a question like that is "Oh, I suppose that could happen, but it would be very rare so don't worry about that", at which point you need to re-iterate that even if rare, we still have to do decide what should happen, even if it's just showing an error to try again.

rendall 5y ago

> "Never ask the product owner what to do in an edge case." Could you expand on that? I've found it best to keep PMs informed even about edge cases, but I'm curious to know what your friend meant? I usually don't ask, but say something like "We store time as UTC for future events, but apparently this is not the best practice because when timezone rules change, the local time is not updated. Setting up that refactor will be medium complexity. I recommend we take the time to fix it now, so that we will not have awkward moments for event organizers as people show up an hour early."

anticristi 5y ago
He was referring to cases like the PM being a highly skilled person with clinical trials. The PM already knows a lot about regulations, customers, what problems can be "automated" away with software, etc. The PM is likely trained in life science or medicine, and never coded themselves. One might be tempted to ask the PM to decide on the following: What should happen if the user clicks "save" but the network went down? Shall we retry a few times? How many times? With what backoff? Or shall the application be offline-first? How should potential conflicts between the server data and the client data be resolved? As you can imagine, the PM has already enough on their plate, so, in my experience, it's best to not overwhelm the PM with such questions and take a decision based on "best guess" on what would maximize customer success. Another anecdote: A PM had to prioritize "integrate with Lufthansa" and "migrate to Java 8". Clearly the latter issue is at the wrong level of detail for a PM.
marcosdumay 5y ago
The PM never has a good answer, and never has any idea on the problems his answer will cause. If he had an answer, you would receive the situation as a requirement, not as an edge case. So, if you go ask him, you could as well ask some random strange on the street and it would be as useful. Some times the end user knows the answer, but very often their opinion is equally useless.
- rendall 5y ago
  > The PM never has a good answer Hmm. Perhaps I've had good luck with PMs. I've actually generally been impressed by some of the insights I've received from PMs about how to prioritize business interests. Most recently, there was a question of what to do in the case that data coming from the client is inconsistent with what is on the server. The proposal was to throw an error. PM said that, whatever we do, it should not interrupt or block communication, which answer simplified the remaining discussion.
  - marcosdumay 5y ago
    Well, notice that the answer came in the form of a requirement. The PM just forgot to tell you that one up-front. Also, your conversation doesn't reflect you asking him what to do. You made a proposal, and he clarified the requirements. He didn't tell you what to do. I wasn't very clear on my post, but the way you did is the one that works. You go to the PM with an answer, and he says if it's acceptable (or why not). You know how to weight the technical details, he doesn't, he knows about the business details. So your proposal should be reasonable, but there isn't any expectation about any one he comes up with.