It’s usually pretty clear when you are not done with a design, but how do you know when you are done? The need for releasing at the right time is clear. Releasing a product in a timely manner is crucial to success—the least successful products are those that release outside their window of opportunity—so your design completion criteria must be release-friendly. On the other hand, the days when you could release a half-baked “good enough” product successfully into a competitive market are long past.
One way to weasel out of declaring your product finished is to release it unfinished as a “Beta.” Doing so lowers customer expectations and provides an obvious excuse when those lowered expectations aren’t met (“What did you expect? It’s a Beta.”) Some companies have a habit of labeling their products as Beta seemingly indefinitely (called “forever Beta.”) I’ll let you draw your own conclusion about the long-term viability of this approach.
There is no universally accepted list of criteria, but here is what I like to use:
(BTW: This list is in order of fundamentals—most fundamental first. And while the entire list can be applied as release criteria, appropriate subsets can be used as exit criteria for preliminary phases.)
I expected some readers will think this bar is too low, others too high. If there is a reasonable balance between the two, I’ll consider that a success. For those who think this bar is too high, I’d like to explore a few ideas.
While it should be difficult to find obvious problems or improvements in a quality product, that’s far from trying to be perfect. As Voltaire once noted, “The best is the enemy of the good” and this classic battle often rears into release criterion discussions. People will say “We don’t have time to be perfect!” Absolutely true—nobody does. But that’s irrelevant because perfection isn’t a goal. Don’t let the inability to achieve perfection be an excuse to lower your quality bar.
I’ve seen teams waste an incredible amount of time during the final project phases trying to address feedback by making changes that fall in the “different but not better” category. I believe this is a symptom of lacking confidence, which in turn is likely due to a weak design process. If you consider several design alternatives during the design phase and use user-centered design techniques as a decision making framework, you should have enough insight and confidence to recognize “different, but not better” design changes late in the process. Don’t waste your time with these—they will consume a lot of time but get you nowhere.
Some project managers live in fear—terrified that their career will be harmed if they don’t incorporate all feedback, especially feedback coming from management. This fear is not without reason. In some team and country cultures, what the boss says goes—regardless.
When I was at Microsoft, everyone was terrified of executive design reviews. One particular senior executive had a reputation for being obsessed with minor details that had nothing to do with goals of the design review (he had a unique talent for finding text his mother wouldn’t understand). As a result, people preparing for these exec reviews spend a significant portion of their time crafting their presentation to avoid getting his feedback. Not a healthy sign.
Managers can really help here by explicitly communicating how the team is expected to handle feedback so that everyone is on the same page. During reviews, executives should clearly distinguish mandatory tasks from unimportant, off-hand remarks. While it’s important to take all feedback seriously and perform due diligence, nobody should worry about their career being harmed for trying to do the right thing.
If you do only one thing:
Set criteria to determine when you are done with a project. Strive for high quality in a release-friendly manner. Avoid wasting time on changes that make the product different, but not better. Managers should set clear expectations on how feedback should be handled. Executives need to be clear on what feedback people really need to follow up on.
The comments are closed.