ProductFTW #2: The Tire Swing Cartoon
The start of building a successful product is to know what it is you need to build in the first place, and that starts with knowing what the customer needs, not what the customer wants.
What the Customer Really Needed
Unfortunately, I do not know to whom to give credit for this drawing. Internet legend has it that an early black-and-white version of this existed as far back as the 1960s, and folks at early computer firms would fax it to each other. I don’t know about that, but I distinctly recall the first time I saw it.
In 2006, I joined Green Dot Corporation as a Product Manager. I was employee number 65 or so. The company had raised its Series B with backing from Sequoia Capital and was well on its way to a billion-dollar IPO in 2010. When I arrived at Green Dot, it didn’t run Agile or another modern software development methodology (although we did try (and fail) to convert to Agile during my three years there). Product Management was a business function that reported up to the President and head of revenue. Our technology team included business analysts who took our Product Requirements Documents (PRDs) and converted them into Technical Requirements Documents (TRDs) and, in turn, created tickets for engineering.
We had a very messy yet traditional Software Development Lifecycle (SDLC). It was waterfall, yet we deployed software every week when I arrived. There was a lot of “1.1.1.1 The password shall be eight characters.”
I was introduced to folks in the Technology team early on and met Kim Kelly, then Director of Business Analysis. She had this cartoon pinned up on her cubicle wall. At the time, as a fresh PM and only 23 years old, I didn’t truly get it.
What everyone loves about this cartoon is that it pokes fun at just about everyone in the organization.
Don’t get me wrong, it is funny.
I also see a lot of folks on the internet saying effectively, “What the customer wanted” is the title.
From a product manager’s standpoint, both of these miss the point. I’ve used a variation of this version to make a point in every company where I’ve been a CEO or Chief Product Officer: The role of the product manager is to understand “what the customer really needs.”
There is a lot of valuable humor in the rest of the cartoon that goes into how to improve the SDLC. However, the start of building a successful product is to know what it is you need to build in the first place, and that starts with knowing what the customer needs, not what the customer wants.
I often use an over-the-top example for this with the Apple iPhone. If you had asked the majority of cell phone customers in the early 2000s what they wanted from a cell phone, you might have heard a few things:
- Smaller
- Better audio quality
- Longer battery life
A few of us were trying to figure out how to combine our Palm Pilots with our cell phones, and business nerds everywhere were clamoring for the Blackberry.
I don’t think any user survey or customer inquiry would have resulted in: “I need a touchscreen supercomputer in my pocket that is connected to the internet so that I can check my email, get directions, surf the internet, and maybe sometimes make phone calls.”
What the iPhone showed us is that this is what customers really needed. The iPhone and other touchscreen smartphones have destroyed the competition by answering so many needs and use cases that most folks would give up a lot of other devices before their smartphone.
I use the tire swing comic to make a point about what product managers are trying to accomplish: understanding user behaviors and needs. A good product manager isn’t an order taker. Sometimes, a simple request is all that’s needed, and a task is managed through the SDLC. A good product manager needs to understand the why and the value of that task so that they can prioritize and enhance it.
Having empathy for your users, their challenges, and their needs is core to building successful products. If you can put yourself in your users' shoes as a PM, you have a real chance of creating something they will appreciate. Many PMs find it easy when building a product for themselves, but the best PMs know how to do this even when the product isn't within their personal experience.
The idea of understanding what your customer really needs is deeply embedded in the construct of user stories:
As a user, I want software to do a task so that I can achieve a goal.
Achieving a goal is about a need, not simply understanding a description. With no disrespect intended, people usually don’t articulate the underlying need very well, and it is up to PMs to help unearth that need.
Enjoy a laugh, tape this cartoon to your wall, and remember to focus on user needs–not wants.