4 ms·

How do people disentangle "ship the incorrect thing and let customers let us know what they really want" vs "ship the correct thing but built incorrectly and le

How do people disentangle "ship the incorrect thing and let customers let us know what they really want" vs "ship the correct thing but built incorrectly and let customers know why its wrong". I hate the second with a burning passion because it seems like its bound to give the impression that you really don't know what you are doing. I've been put into situations too many times where I just could not get the point across that "yes I understand that we may not be giving the customers what they want, but what you are telling me to build is clearly not correct" its maddening. Sorry if its off topic but it seems at least adjacent to the articles balance. This seems to happen with PMs who do not have a deep enough background in the technical detail and yet reject the feedback given because it will reflect that poor understanding. "Agile" environments seem to enable this kind of behavior. I'm beginning to think I need to pivot to PM in my career so I can avoid the madness as a developer.

sumtechguy 4y ago
That depends on your customer. Some are cool with 'something is better than nothing'. Some are not. Some also are very 'I put it in the contract just do it that way' others are 'I just want the right thing'. Some just do not know what they want at all and just want you to do it and put all the liability off onto you but do not really want to spell out what that means at all. Being a PM is that turned up to 11 but now you do not control the code at all.
- peteradio 4y ago
  I guess what I'm talking about is this: 1) PO wants feature X for customer P. 2) Architect in meeting with PM and PO indicates that feature X is a simple addition to Y 3) Engineer is assigned X and says no this isn't a simple addition to Y because on deeper inspection it will fail for cases 1,2,3, we would need a different architecture. 4) PM says build it the naive way, let the customers find case 1,2,3 before we fix, we are an Agile team after all. 5) I quit.
  - antupis 4y ago
    I would do 4.5) escalate to PM boss everytime 1,2,3 happens.
  - helge9210 4y ago
    > PM says build it the naive way Why PM has an option to choose here? > will fail for cases 1,2,3 a) tip QA to test these cases b) add cases 1,2,3 to "Known issues" After all that is the reason they call it "beta": "Cause it beta then nothing"
  - skellera 4y ago
    Seems like you’re working with a PM who thinks agile is an excuse to release bad software. MVP should still solve a customer pain point. To play devils advocate though, maybe case 1,2,3 are low enough risk to release. Having metrics set to watch if these are actually big problems could be “good enough.”
  - nightpool 4y ago
    Without details, it is really, really, really hard to say whether cases 1, 2, 3 are real, important issues that need to be fixed or just needless complexity that 99.9% of users are never going to care about. The PM is trying to distinguish between those two cases because they've been burned before on developers double, tripling, and quadrupling their estimates as they find "one more thing" that is inelegant or could potentially be improved and delaying the launch schedule. You need to convincingly make the case to the architect (and to the PM) that issues 1, 2 and 3 are critical to the users, fundamental to the design and going to be much harder to clean up later if we don't spend the time to get them right now. Or you're wrong, and you should just suck it up and build the simpler thing today and leave the complexity of the new thing for the future, when you can decide whether the feature is even worth the cost of having whatever new architecture it would require.
    - MetaWhirledPeas 4y ago
      This is a good answer. Determine how much the deficiencies matter and make your case. If you're being asked to ship something with a major deficiency and being ignored by the team you need to inform someone higher up. Not always the most fun part of the job.
MetaWhirledPeas 4y ago
My personal take is that "built incorrectly" should almost never be tolerated. The customer doesn't need to know how it was built, merely how long it will take. But if by "built incorrectly" you mean an unwise business decision (logging in with a phone number for instance) then yeesh, I wish I had an answer. Putting your foot down sometimes means leaving a job.

sumtechguy 4y ago

That depends on your customer. Some are cool with 'something is better than nothing'. Some are not. Some also are very 'I put it in the contract just do it that way' others are 'I just want the right thing'. Some just do not know what they want at all and just want you to do it and put all the liability off onto you but do not really want to spell out what that means at all. Being a PM is that turned up to 11 but now you do not control the code at all.

peteradio 4y ago
I guess what I'm talking about is this: 1) PO wants feature X for customer P. 2) Architect in meeting with PM and PO indicates that feature X is a simple addition to Y 3) Engineer is assigned X and says no this isn't a simple addition to Y because on deeper inspection it will fail for cases 1,2,3, we would need a different architecture. 4) PM says build it the naive way, let the customers find case 1,2,3 before we fix, we are an Agile team after all. 5) I quit.
- antupis 4y ago
  I would do 4.5) escalate to PM boss everytime 1,2,3 happens.
- helge9210 4y ago
  > PM says build it the naive way Why PM has an option to choose here? > will fail for cases 1,2,3 a) tip QA to test these cases b) add cases 1,2,3 to "Known issues" After all that is the reason they call it "beta": "Cause it beta then nothing"
- skellera 4y ago
  Seems like you’re working with a PM who thinks agile is an excuse to release bad software. MVP should still solve a customer pain point. To play devils advocate though, maybe case 1,2,3 are low enough risk to release. Having metrics set to watch if these are actually big problems could be “good enough.”
- nightpool 4y ago
  Without details, it is really, really, really hard to say whether cases 1, 2, 3 are real, important issues that need to be fixed or just needless complexity that 99.9% of users are never going to care about. The PM is trying to distinguish between those two cases because they've been burned before on developers double, tripling, and quadrupling their estimates as they find "one more thing" that is inelegant or could potentially be improved and delaying the launch schedule. You need to convincingly make the case to the architect (and to the PM) that issues 1, 2 and 3 are critical to the users, fundamental to the design and going to be much harder to clean up later if we don't spend the time to get them right now. Or you're wrong, and you should just suck it up and build the simpler thing today and leave the complexity of the new thing for the future, when you can decide whether the feature is even worth the cost of having whatever new architecture it would require.
  - MetaWhirledPeas 4y ago
    This is a good answer. Determine how much the deficiencies matter and make your case. If you're being asked to ship something with a major deficiency and being ignored by the team you need to inform someone higher up. Not always the most fun part of the job.

MetaWhirledPeas 4y ago

My personal take is that "built incorrectly" should almost never be tolerated. The customer doesn't need to know how it was built, merely how long it will take. But if by "built incorrectly" you mean an unwise business decision (logging in with a phone number for instance) then yeesh, I wish I had an answer. Putting your foot down sometimes means leaving a job.