This rule is related to the concept of Jidoka in Toyota Lean. Take note, that the rule is not about what you do, it's how you do it. A risky experiment is fine, as long as you perform it well.

First Time Right

In all your work, you will deliver quality software - do not create technical debt. Whatever you do, do it right.

Doing it right does not imply reaching perfection. It means:

• Simplicity: the chosen solution is easy to explain to stakeholders, because it resembles the actual business domain.
• Maintainability: the chosen solution complies to the architecture guidelines and coding standards.
• Reliability: no deployment to a production environment shall ever break the system.

In general, do not sacrifice these rules to complete the functional scope of a project. If the scope is too large to guarantee quality - reduce the scope instead.

Additional notes

• As a product owner, you will always want to avoid technical debt. Technical debt prevents you from being agile, because the resulting mess will need to be cleared some sprint later - this fixes your roadmap and thus limits the ability to change your mind.
• The rule of First Time Right is about the default attitude towards making software: simplicity, standards compliant and with sound deployments. Of course it is possible to deviate a little from the rule if the business case is right. Then, the removal of technical debt must be included in the business case.
• Existing software is not necessarily affected by the rule. Don't be too hard on yourself. The rule is about everything you do, not about everything you did before - that would fit under refactoring.
• To get to the most predictable solution for a given problem, it's always best to test before you invest. This means that every risky piece of the solution must be proven to work before it can be used in your software.