Google expects everyone to innovate, even the finance team
Again, that’s great, but when you’re dealing with patents and designs that have to remain secret, the intranet isn’t always secure enough. Secure admin-protected project folders accessible only to key users/project contributors are a better option.
Founders Larry Page and Sergey Brin approve hires. They favor intelligence over experience
Employees get a “free” day a week. Half of new launches come from this “20% time”
I’m not sure how this doesn’t get abused, but having flex time devoted to training, brainstorming, applied research and “field trips” is definitely a great idea. You just want to make sure that the free time isn’t being wasted on… well, picking up your dry-cleaning, updating your resume, or hanging out by the water cooler.
Innovation, not instant perfection
Google launches early and often in small beta tests, before releasing new features widely
In the case of companies for whom “beta” tests aren’t relevant or possible, prototype/field testing is essentially the same thing. Test as much as possible. Word to the wise: Test to failure. Look for the flaws. DO NOT test in optimal situations simply to “validate” your design. Testing is about finding out your product’s flaws more than it is about finding out its strengths. Use that time to discover what you missed, what you didn’t know about your product. Better to find out now than when you’ve spent tens of millions of dollars and it’s too late.
Mayer discourages the use of “I like” in meetings, pushing staffers to use metrics
It was bound to happen: I disagree with this one. (It may apply to Google, but it doesn’t always work for other companies.) Data can be completely meaningless. It can be corrupted. It can be misinterpreted. Heck, it can be manufactured. (It’s happened at one of the companies where I once worked. Not good.)
Gathering the right type of data in the right way can produce wonderful depths of insight that can help guide a decision, but data alone should never drive a solution. More often than not, the “data” that is presented to decision-makers is at best incomplete, and can easily be taken out of context. (Not to mention that data will usually pull designs back to the safe “middle” of the bell curve instead of the edgy remarkableness, where it belongs.)
Leadership isn’t about hiring data monkeys to take a show of hands and hand over the most popular answer to a general question. Leadership is about vision, purpose and instinct.
(So I’m not saying data is worthless, but it isn’t the end-all, be-all either.)
I would encourage comments like “I like it” or “I don’t like it.” (I prefer words like “love” and “hate,” but that’s a whole other story.) As long as you qualify your answer, there’s a place for that kind of feedback. You cannot discourage emotions and tastes when it comes to feedback and project direction. It’s a very bad idea.
Give people a vision, rules about how to get there, and deadlines
Nope. Nope. 100x nope. Give them the vision, yes, give them deadlines, yes, but throw out the rules. Burn the rules. Tear them into little pieces and mail them to your competitors for Christmas. If you’re lucky, they’ll tape them back together and incorporate them into their innovation process.
Provide something simple to use and easy to love. The money will follow.
Trust me on this: It works every single time.
Hey. When life gives you kernels, make pop corn.
Okay… that was lame. Or… not. But every project worth anything is going to contribute something to your company. It could be customer/user feedback. It could be market data. It could be discovering the limitations of a material or of your manufacturing capabilities, or of your design engineering’s ability to problem-solve.
Every project yields lessons that should always be reviewed, shared, and applied. If you get far enough, some of the testing you do on prototypes and new designs can add a tremendous amount of bones to your knowledge bank. Even if the project is nixed, there should always be a mountain of invaluable info and insight associated with it up to that point. Use it.
Without fail, every design project I worked on in my career uncovered insight that helped improve other products that either shared parts or certain technical characteristics. Every project is a learning experience. (If a project isn’t, then you are doing something wrong.)
Thanks to Tim Coote at Bcom for the heads-up.