Member-only story
“Our competitor has released a new update,” the vice president said, “with thirty new features.”
“We should have new features too,” said the other vice president. “What do users want?”
“Presumably, because our competitor is second in market share, they want some of the features our competitor has produced.”
So they chose one at random from the list, and passed it along to the project architects.
“Why do we need this feature,” said the project architect, “when we already have another feature that does the same thing? We should actually be improving that feature to handle the use case that this implies.”
“What use case does it imply,” asked the other project architect.
“I’m not sure, but whoever is using it this way is going to choose our competitor’s product if we don’t get busy.” So, they passed the use case onto the project managers.
“OK,” said the project manager to the engineer, “we have two weeks to implement a new feature to handle this use case.”
“What is the purpose of this use case,” said the engineer, “when we handle this behavior better in the happy path already?”
“I don’t know,” said the project manager, “but the order is coming from the top with a high priority so it must be based on customer feedback.”
“This use case requires violating several assumptions made in our critical flow. If people are actually doing this, we should…
