The Tire Swing Cartoon - ProductFTW #2
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.
Originally published January 25, 2024. Revised May 2026 with origin history, variants, and frequently asked questions.
What the Customer Really Needed
Where the tire-swing cartoon came from
The image traces to the University of London Computing Centre's ULCC News Newsletter #53, published in March 1973. The cartoon appeared as anonymous corporate humor about how software requirements drift through stakeholders. From that single newsletter it spread quickly through IBM training materials, system-analysis textbooks, and consulting decks throughout the 1970s and 80s–no individual author is credited, just "ULCC News."
What gave the cartoon staying power is that every panel is true. Project managers, engineers, business analysts, and customers each describe the same product and produce mutually incompatible mental models. By the 1990s, the image was a fixture in training; by the early 2000s, it had been adopted by the agile community; today, it's standard issue in product-management writing.
The cartoon you've seen vs. the ones you haven't
Most people know the seven-panel "what the customer wanted vs. what was delivered" version that's been screenshotted into
thousands of slide decks. The cartoon has several other variants worth knowing:
- The classic IT version : 7 panels covering customer description, project leader, analyst, programmer, consultant,
operations, billing, what was installed, support, and what the customer needed. - The agile version: 4 panels, emphasizing that early customer involvement would have caught the misalignment.
- The lean/MVP version: 3 panels: what was asked for, what was actually needed, and what shipped first.
- The "everything went wrong" version: adds a final panel where the tree has been chopped down and the customer is still unhappy.
Each variant makes a different argument about why the original misalignment happens. The IT version blames role-based silos. The agile version blames waterfall sequencing. The lean version blames over-specification. The pessimist's version blames the customer.
My First Cartoon Swing Experience
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.
Common questions about the tree-swing cartoon
Who created the tire swing cartoon?
No single creator. The cartoon emerged from anonymous corporate humor in the early 1970s and was passed around via Xerox copies, internal newsletters, and overhead transparencies for decades before the internet. Modern variants are adapted by individual designers, but the original sequence has no attributed author.
What does the tree swing meme mean?
It illustrates how the same product specification produces wildly different interpretations across stakeholders. A customer describes what they want, the project manager hears something different, the analyst documents something different again, and engineering builds yet another thing. The gap between "what the customer needed" and "what was installed" is the cost of communication failure across roles.
Where did the tire swing cartoon come from?
It first appeared in University of London Computing Centre ULCC News Newsletter 53, published March 1973. From there it spread through IBM training and system-analysis textbooks before being adopted by the project management and later agile communities.
Why is the tree swing cartoon still relevant?
Because the underlying failure mode hasn't changed. Modern product teams still produce specs that look reasonable on paper but render incompatibly across functions. The cartoon is a useful diagnostic: if your team can look at it and not see your last project, you're either exceptionally aligned or not looking carefully.
What's the right fix for the tree-swing problem?
Direct customer-to-engineer contact, working in short iterations with feedback loops, and shared definitions of "done" across roles. The cartoon is making the case for collaborative requirements work: PRDs written with engineering, not handed to them. See Mastering the Art of Requirements for the practical playbook.
Part of the Product Requirements Field Guide — ProductFTW's collected essays on the six phases of writing requirements, from problem definition to launch.