There are many great definitions of product management. There’s universal agreement that the best PMs are utility players who have a range of skills that lets them jump into almost any role so they can do whatever it takes to ship products faster. Between diving into details and reacting to incoming requests — from engineering, design, sales, marketing, support, PR, legal, and more—it’s easy to get sucked into spending 100% of your time with a time-horizon of the release date two-weeks out.
It’s a trap.
Google’s investment approach
Take a lesson from Google. Back in 2005, just post IPO and with their core search and AdWords businesses growing at a tremendous pace, Google realized that all their resources could easily get sucked into the vortex of refining their core products. They could get lulled into the monotony of continuous iteration. So Schmidt, Page, and Brin forced Google to invest outside the core.
We spend 70 percent of our time on core search and ads. We spend 20 percent on adjacent businesses: Google News, Google Earth, and Google Local. And then 10 percent of our time should be on things that are truly new.
- Eric Schmidt, 2005
While this is somewhat related to Google’s notorious “20% time” for engineers, Schmidt’s point was broader. Google wanted to invest 20% of its resources on new businesses built off the strong foundation of search/ads, and 10% of its time on completely new ideas that could seem crazy.
Schmidt was forcing Google to think about where to deploy its resources like investors think about allocating assets. The mix of investments depends on risk profile and time horizon. With its monopoly-like profits and founder-friendly share class structure, Schmidt knew Google had an abundance of capital and time. He wanted to make sure Google took advantage by investing in high risk, high expected return projects to optimize for its long-term success.
A Product Manager’s 70/20/10
While Google likely has a longer time horizon than your company, its allocation approach makes sense if you just compress the timespan.
I think the ideal mix of a PM’s time is 70% on the coming weeks, 20% on up to a quarter out, and 10% further out than that. This maps neatly to my post on roadmaps: 70/20/10 on #now/#next/#later.
Avoid the trap of spending 95% of your time on reactive tasks. You will never leave room to come up with, nurture, and develop the big new ideas that change the trajectory of your product.
Steady vs. Spurts
Many PMs shift their time allocations around lumpily. It’s easy to go all the way to 20/80/0 for one week of the quarter when you are putting together a roadmap. Everyone loves a week dedicated to brainstorming.
Consistency works better here, however. It allows more time for ideas to marinate and to bounce them off other people. It allows time to prototype and figure out engineering costs before having to commit to building a feature.
And it will produce better ideas, because it gives you time to observe. It is easier to come up with one new idea every week than 10 ideas in a one-week sprint.
Paul Graham’s great essay on How to Get Startup Ideas explains this well:
Since what you need to do here is loosen up your own mind, it may be best not to make too much of a direct frontal attack on the problem — i.e. to sit down and try to think of ideas. The best plan may be just to keep a background process running, looking for things that seem to be missing. Work on hard problems, driven mainly by curiosity, but have a second self watching over your shoulder, taking note of gaps and anomalies.
- Paul Graham, 2012
There’s a silver lining to the 70%: your everyday job as a PM should be filled with clues for new ideas if you start looking for them. The results of that Hive query you ran, the surprising A/B experiment result you analyzed, the user research session you sat in on, the sales meeting you presented at, the competitor product you tried, the whiteboard session you designed in—all these short-term tasks are filled with seeds for future feature ideas. Open your eyes and write them down.
How about other roles?
I cannot say for sure, but I suspect many other roles could benefit from taking a similarly structured approach. For example:
- Designers: 70% on the visual specs for upcoming features, 20% exploring new features, and 10% on wireframes for entirely new concepts/styles.
- Engineers: 70% building features and fixing bugs, 20% on prototyping fledgling ideas or exploratory data analysis, and 10% on speculative initiatives like a 10x performance improvement.
- Sales: 70% on closing deals, 20% on bigger I/Os for the next quarter, and 10% on long-term relationships with agencies and big advertisers.
Maybe those percentages are not quite right or the tasks are a bit off, but it does seem like a potentially useful approach.
While you probably don’t have the luxury of building a self-driving car for 10+ years out, you also cannot afford to only focus on two weeks out.
You are completely responsible for shipping products fast, above a minimum quality bar, and with the right scope. But your job doesn’t end there. Clean up your calendar, shut off your email occasionally, keep track of insightful observations, and set aside time to think further ahead.
You need to live in the future and bring great ideas back.