Launching: Good Enough vs. “Perfect”

The cast of “Product Chefs” is expanding. A year-plus extremely-rapid design, develop, release, refine is quickly becoming design, deliberate, design, deliberate, develop, deliberate, design, deliberate (you get the picture). 

I have definite ideas about how wrong this is in this current environment, but I’m too experienced to think mine’s the only – or only correct – perspective. My feeling is you work on the bulk of the product – the 80% – get that correctly-positioned for release and refinement and you go. Your audience is going to be your best source of feedback, and you’ll never be able to test every usage case beforehand, anyway: get it working, get it out, and get ready for audience feedback to inform your plans for Release 1.1, 1.2 and beyond. 

At what point does it make sense to be more concerned with the 20% (as opposed to the 80%)?
When should your company (any company) be more concerned about Getting it “Perfect” than with “Getting it Launched?” (air traffic control, financial systems and the like aside)

Those who feel charged with “protecting the Brand” can generally make a case that just about anything is not yet “ready for prime time.”  

In more jaded moments, it’s easy to point out that

  1. Success breeds envy; when something starts working, people want a piece
  2. When a product is designed by committee, each member can claim their piece of success upon success; upon failure, there is near-zero culpability 

To the other point of view, however, maybe it’s upon success that you start taking a harder look at the 20% you’ve been neglecting in initial releases. It slows you down, but with more eyes on you, maybe you need to adjust design, develop, release, refine to account for more upfront.

Managing Expectations in Project Timelines (with FAQ)

As we’ve delivered products through the years, managing timelines – and stakeholders’ perceptions thereof – has been an interesting source of teachable moments.

The snarky note below was for a core team-only. The tone in it is not recommended for general stakeholders. The FAQ covers two main recurring points; additional contributions would be great – please send them.

Our April 11th due date for Final Design approval and sign off is now missed by at least 20 days. None of the later milestones, therefore, were hit. Everyone should understand that the other dates – Production, Coding, Integration, Testing, Launch – move out accordingly.  Even so, I don’t want to presume this understanding is there throughout the rest of our extended team, so I’d like to send a new timeline out to everyone. I’d also like your help in backing me up and reïterating this message. 

I have some FAQs prepared that I can send (e.g. “Q: But you said Launch was May 15! How can it not be May 15!?”; “Q: But this latest design is so much like the existing design! Doesn’t that mean it’s really easy to put in place”)

Thanks, and please let me know if you’ve got feedback for me before I circulate our new timelines for this relaunch.

The Team

Btw –

A: Because of the relatively fixed nature of the space / time continuum, moving one point affects the other points in a directly-proportional ratio
A. No – it’s still a design job that requires Design, production and coding that needs to happen with the same resources we have in place today.

Corollary: “Q: So, can’t we get some more help to speed it up? More designers, Producers and coders to still hit our date two whole weeks from now?”
A: Sorry, but no. Especially in such tight timeframes, adding additional resources does not automatically mean our time-to-market improves. Getting external resources up to speed could help in a longer-term project, but not one that’s expected in just a few weeks. A re-launch project like this is like giving birth to a new life. Giving birth takes about nine months for humans. Adding additional resources to the pregnancy will not speed up the birth.