Babe Ruth and Feature Lists

Why prioritized feature lists can be poisonous

By Ken Norton

5 min read • Nov 22, 2015

Ken Norton

Executive Coaching for Product Leaders with Ken Norton

Get a product-minded executive coach in your corner to unlock your full capacities as a leader

Learn more »

Babe Ruth at the plate

In 2007 I was a product manager on Google Docs. Docs was barely a year old, stemming from the acquisition of a marvelous startup called Writely. We were still nailing the basics. (On the FUD timeline, Microsoft had not yet called me “naive” and it would be three more years before they’d accuse us of being “up way past our bedtime.”)

Screenshot of Google Docs as it looked in 2007

Google Docs as it looked in early 2007. Note the lack of sophisticated page layout features and the emphasis on collaboration.

We were popular with legions of early adopters and we saw notable enthusiasm in the educational market. Teachers loved the idea of sharing documents with their students without the hassle and cost of software licenses. Our academic customers were passionate, smart, and vocal, which meant we got constant high-quality feedback. I responded by keeping a voluminous feature request list that was managed, quite naturally, in a Google Spreadsheet.

I was careful to track the priority and difficulty of the requests so we could spend our engineering time accordingly. Every time we got feedback from the forums, or talked to a customer, we made sure to reflect their requests in the spreadsheet, adding a new row if necessary.

My list emphasized broad themes such as formatting, printing, import/export, sharing, and commenting. We pushed hard to make sure each three-week release touched on as many top themes as possible. I felt good when a sprint made progress against all of our top priorities. Our sales and support counterparts passed along feedback from customers that reinforced our prioritization.

In March of 2008, the Google Apps team invited a bevy of academics to Google’s Mountain View campus to meet various product managers. I was invited to join twenty K-12 and university educators and administrators to chat about Docs and hear their feedback first-hand. I was ready to share my top feature priority list, to reassure them that their biggest requests were represented. And maybe bounce a few big, longer term ideas off them.

My list probably began like this:

Google Docs Feature Priorities

1. Formatting
2. Printing
3. Import/Export
4. Sharing
5. Commenting

I started at the top and described some of the exciting new formatting features that were being considered: styles, template galleries, and more fonts. Almost immediately, one of the participants reacted: “Oh this is bad, I thought that meant you were going to fix formatting.” Others jumped in: “Google needs to stop working on fun things and start focusing on basic functionality. Please don’t waste your time on the non-essential stuff on that list.” Eventually the whole room piled on, and it was painful. For them, formatting was a bug, not a feature, and it was so crummy nothing else mattered.

Why was it so atrocious? We were relying on the browser’s rich text surface, which used HTML as the underlying data format and caused browser compatibility nightmares. You’d bold a word and then be unable to un-bold it. Bulleted lists couldn’t be edited or deleted without screwing up the whole page or turning everything into a bullet. Centering a line would often center-align the entire document. Formatting bugs had been an annoyance for Googlers, but they were fatal for groups of students who needed to print a term paper to a teacher’s exacting specifications.

I wanted to make sure the group wasn’t overreacting so I tried an exercise I learned from a friend: I asked the group to pretend they each had one hundred dollars of Google’s money to spend. How would they stack formatting bugs against these other improvements? The outcome was incontrovertible: except for a few scattered dollars, they chose to spend all of their play money to fix basic formatting bugs. One woman said: “I spend one hundred dollars on formatting, then I take another hundred of my own money out of my own damn wallet and spend that on fixing formatting.”

What Did I Learn?

To us, “formatting” was a broad product theme to hack at indefinitely. We had big plans for shared style templates and additional fonts. But to our users, “formatting” was an urgent bug that needed to be fixed. Sure, collaboration and the cloud were our differentiators, but we were failing to meet a minimum quality bar.

We were right to manage our product development against themes, but we messed up by not setting the right expectation with our customers. We all agreed formatting was a top priority, we just never agreed on the details.

Our wish list approach also created false equivalence. There was a huge chasm between what #1 meant to us and what it meant to our users. For us, it was first amongst equals. To them it was a painful tumor overdue for removal.

Two bar charts. One of them shows them in relative linear descending width. The second shows the first item to be extremely long and the others much shorter in comparison.

Lists are good at conveying relative importance, but not orders of magnitude

Orders of magnitude separated #1 from the rest of the list. That urgency didn’t come through until we got a bunch of them in the room and let them vent.

When you ask your customers to tell you what’s important, give them a blank sheet. Don’t ask them to react to a list. Having a real conversation allows you to ask follow-up questions like “but if you had to choose, would you rather have A or B?” Use the time to deeply understand the problems they’re encountering.

If you do share a feature list with customers, keep it short and cap the length. Tacking low priority requests onto the end of a bloated list causes it to become unmanageable and dilutes the significance of the top themes. Be clear and descriptive, and separate bugs from features. Keep a separate unranked pile for requests that haven’t been prioritized yet or slotted into a theme. Make sure everyone understands the criteria for removing something from the list.

Baseball Players, Ranked by Hitting Ability

1. Babe Ruth
2. William Van Winkle Wolf
3. Shooty Babitt
4. Pickles Dilhoeffer
5. Stoney McGlynn


That customer summit was just the jolt we needed to prioritize basic formatting fundamentals. We knew it was going to be hard and it would take a long time. An amazing team of engineers would write our own editing surface and layout engine from scratch and toss the browser’s built-in editor to the wind. (By the time the rewrite shipped I’d moved to a different project so I can’t take any credit.) Docs became even more awesome and is now used by more than five million businesses and millions more consumers. That rewrite set the foundation for all of today’s amazing features. And in 2021, Google Docs would begin migrating away from HTML-based rendering entirely to a canvas-based approach.

Planets of the Solar System, Ranked by Habitability

1. Earth
2. Mars
3. Jupiter
4. Saturn
5. Venus

Originally Published: November 22, 2015

Ken Norton is an executive coach who works with product leaders. He spent more than 14 years at Google where he built products used by more than 3 billion people.

  • How to Hire a Product Manager: the Classic Essay

    The classic essay that defined the product manager role

    What is product management? What makes a great product manager, and how do you become one? This is Ken Norton's classic essay on the role of product management that launched thousands of PM careers.

  • 10x Not 10%: Bold Product Strategy and Vision

    Product management by orders of magnitude

    In this ambitious essay, Ken Norton looks at the history of innovation and challenges product managers and product leaders to think bigger, to aim for 10x, not 10%.

  • Please Make Yourself Uncomfortable: Jazz and PMs

    What product managers can learn from jazz musicians

    What can product managers and product leaders learn from jazz, an art form that is all about improvisation, collaboration, and being willing to take risks?

  • Best Books for Product Managers [2024]

    Essential product management reading

    Ken Norton shares his recommended books for product managers. The best books on product leadership, innovation, management, shipping winning products, and design thinking.

  • Building Products at Stripe

    Go deep, move fast, and build multi-decade abstractions

    What is Stripe's product culture like? Interview with a Stripe product leader demonstrate an embrace of going deep, moving fast, and maintaining a multi-decade perspective.

  • It’s Time to Fight for a Dual Product Management Career Path

    Companies should embrace multitrack job ladders for product managers who prefer product leadership to people management

    Companies should embrace multitrack job ladders for product managers who prefer product leadership to people management. A concrete proposal with sample career track is included.

  • Ants & Aliens: Long-Term Product Vision & Strategy

    Why you need a thirty-year product vision (yes, thirty)

    How do you plan for the future and deliver an innovative and compelling product vision that will inspire your team to deliver winning products?

  • Building Products at Airbnb

    Snow White, storytelling, and a relentless focus on experiences

    What is Airbnb's product culture like? Interviews with Airbnb PMs demonstrate an embrace of Snow White, storytelling, and a relentless focus on experiences.