During the product development, some people often seek for the perfect solution.

“How do you ensure the UUID (Universally Unique Identifier) is unique so the system won’t crash?” A developer asked me recently during a discussion on a RESTful API.

“We have to fine-tune the UX,” said a developer from another product team, “I don’t feel comfortable delivering this UI to the users.” He then spent plenty of time explaining his imagination to build the perfect UI.

To initiate communication with a product team that is about to start the Agile journey, the Agile Coaches planned to design a questionnaire so that the team members from that product team could provide the background information. The Agile Coaches spent months drafting the questionnaire but didn’t release any to the product team. They worried that the questionnaire wasn’t detailed enough. It might fail to gather enough information before initiating their coaching.

Over-obsessing with a perfect solution is a common pitfall. Unfortunately, it happens in various places, regardless of whether the product is software or a service. The developers planned for a perfect solution without actually working on the product. After several delays, they delivered the product, imagining it was perfect. But they discovered many unexpected issues. As the developers hadn’t thought of those issues before, they determined the delivery failed. They then spent more time planning for a more perfect solution, creating a spiral of death.

There isn’t a perfect solution. Even if you can think of thousands of ways to refine your product, you can never know how the user will react to your product without delivering it. More things can go wrong, both from business and technical perspectives.

Of course, I’m not saying we should ignore all the possibilities that could go wrong. Indeed, UUID is theoretically not unique. However, it is extremely rare to produce a duplicate UUID. Is it necessary to handle the practically impossible problem, not to mention the consumer can resolve the problem simply by resending another request?

As long as the imaginary problem is controllable, we should deliver the product to the users first and test the market. Usually, you would realise more scenarios that you couldn’t anticipate during the development.

The UI developers released the UI to the users with numerous add-ons to impress the users, but delayed for a couple of months. When the users first looked at the UI, they didn’t comment on the add-ons. They didn’t recognise how the developers fine-tuned the user experience. All the users asked was to show the information they needed.

The questionnaire is just a trigger to kick-start the Agile journey. The product team members might misunderstand the questions and distort the facts. A perfectly designed questionnaire can never replace an onsite observation.

The “perfect” solution is just an assumption of value. Only after you deliver to the users can you validate your assumption is correct. Avoid perfectionism. Ship your product and get feedback from the market.