We’ve seen a number of Idea Maze cases so far. What leaps out at you? What doesn’t?
In this piece, I want to talk a little about what’s leapt out to me while I wrote and researched these cases. If your conclusions are different from mine, don’t fret — it’s likely that your takes are just as (if not more) valid than my conclusions, especially when read in the context of your operating domain.
A reader, Michael Webb, just sent me his list of notes that he made while reading through the Idea Maze. I thought some of these takeaways were really insightful — and things that I didn’t even think about.
I’ve gotten permission to share his list here:
Often you need to do lots of experiments. You don’t know in advance what will work! (e.g. iPhone keyboard; ByteDance multiple new apps) And generate lots of ideas (which may seem stupid); can then do analysis to consider before progressing/discarding (e.g., Amazon had lots of ideas to increase convenience of shipping before Prime idea; did rigorous analysis to figure out which ones were worth progressing).
Apple’s unit of iteration was the demo.
Also: people often don’t recognise good ideas in the moment! (PayPal case) → Don’t be too quick to dismiss ideas when you’re deep in the Idea Maze!
Cf Amazon PR-FAQ as a unit of iteration (see notes on “Product Development as Iterated Taste”)
It takes about twelve thousand storyboard drawings to make one 90-minute reel, and because of the iterative nature of the process I’m describing, story teams commonly create ten times that number by the time their work is done.
Put people who have the idea on/in charge of the problem the idea solves, even if it’s not their area of expertise (e.g., Apple promoting the guy who had the keyboard idea to be DRI for it; Amazon taking an engineer who had similar Prime idea and putting him on what was a business project; Microsoft promoting Sinofsky who had idea for bundling Office as Technical Assistant to Gates to be Group Program Manager of new Office business unit).
It’s fine to do stuff that looks stupid at the beginning. (iPhone keyboard designs)
Adjust your internal structure to reflect your strategy (Microsoft re-org’ing Office)
If you expect customer behaviour to change as a function of some new feature/opportunity, think too about how long you expect it will take and be prepared to wait that long! (Prime: took 2 years before data showed Prime customers doubled spending on Amazon; not so surprising given most customers shopped online only a few times a year.)
Cf ByteDance, had several years of slow growth and mis-starts before it took off.
Need to hypothesise the causal mechanism of action and be rigorous about how long you expect it to take to prove out!
Do rigorous resource prioritization. This requires knowing what the priorities are (e.g., the keyboard for the iPhone). Double down on the things that start to look like they’re working (making the inventor of the best prototype keyboard the DRI).
Go after the obvious people who need to use your product. Don’t build stuff for yourself because it’s technically interesting. (General Magic)
Don’t bite off more complexity than you need to. (General Magic)
You can get away with early failures if you keep iterating in response to feedback. (PayPal)
If something fails, draw the right lesson. It could be the concept was bad, or it could just be it was badly executed. (ByteDance)
Figure out what your users like, and do more of that. (Instagram)
Set deadlines to get things done (Bezos Prime membership, starting mid-Oct, “by end of the year”).
Even if you’re growing, may not be fast enough. Amazon Q3 y-o-y was 15% vs 12% previous year; Best Buy at 17%. Recognise as “house-on-fire” issue.
Big companies spend lots on marketing. (E.g. Microsoft spent >$200m on marketing for release of Windows/Office 95.)