[{"data":1,"prerenderedAt":20},["ShallowReactive",2],{"post-100-cup-holder-problem":3},{"excerpt":4,"title":5,"updatedAt":6,"slug":7,"postId":8,"tags":9,"status":15,"coverImage":16,"content":17,"publishedAt":18,"createdAt":19},"Adding AI features is easy. Solving the right problem is hard.","The 100 Cup Holder Problem: A Product Lesson for the Age of AI","2026-03-18T14:57:40.898Z","100-cup-holder-problem","22438789-3981-45df-ba26-186de7345056",[10,11,12,13,14],"Product Design","Customer Feedback","Product Strategy","Innovation","Market Insights","published","https://ericnparadis-com-prod-mediabucketbucket-baexchhz.s3.amazonaws.com/media/ff7627a6-8eb1-4ab6-b8ff-64daa1d0a916.png","Every time I see a roadmap filled with AI features, I think about the 100 cup holder problem.\n\nBecause this pattern shows up whenever product teams mistake feature requests for real user needs.\n\nImagine you surveyed drivers about what they want in a new car.\n\nA common complaint might be:  \n*\"There aren't enough cup holders.\"*\n\nIf a product team took that feedback literally, they might design a car\nwith 100 cup holders. Technically, they solved the problem. But no one would actually want the car. Because what drivers really meant was something different.\n\nThey wanted convenience. Storage. A thoughtfully designed interior.\n\nThe cup holder complaint was just the visible symptom.\n\n### Customers Describe Frustrations, Not Solutions\n\nOne of the first lessons product leaders learn is this:\n\nCustomers are excellent at describing problems. They are terrible at designing products. Users tell you where something hurts.They rarely tell you what the right solution is. If you treat feedback like a feature backlog, the result is predictable.\n\nFeature sprawl.  \nComplexity.\n\nProducts that feel like a pile of requests instead of a coherent system.\n\n### The Pontiac Aztek Lesson\n\nThe Pontiac Aztek is a classic example.\n\nWhen it launched in 2001, it was supposed to be the ultimate lifestyle\nvehicle. It had camping attachments. Modular cargo systems. Dozens of niche\nfeatures. Each idea made sense on its own.\n\nTogether they produced one of the most famously awkward cars ever built. The problem was not that the features were wrong. The problem was that the product had no clear job to do. It tried to satisfy too many interpreted requests instead of solving a\ncoherent user problem.\n\nMost bad products are not built by bad teams. They are built by committees.\n\nMarketing adds a requirement.  \nSales adds another.  \nCustomer feedback introduces five more.\n\nEventually the roadmap becomes a compromise between dozens of partial\nsignals. No one is wrong. But the product loses its center of gravity.\n\n### The AI Version of the 100 Cup Holder Problem\n\nWe're seeing a modern version of this problem right now with AI. Teams ask customers what they want from AI. The answers sound like this:\n\n\"Add AI to summarize things.\"  \n\"Add AI to write emails.\"  \n\"Add AI to automate tasks.\"\n\nSo the roadmap fills up with AI features.\n\nAI chat.\\\nAI assistant.\\\nAI generator.\\\nAI everywhere.\n\nBut often those features are the new cup holders. They respond to surface requests instead of solving the underlying job. The real question is rarely \"Where can we add AI?\"\n\nThe real question is: **What decision, workflow, or outcome could AI actually improve?**\n\n### A Quick Note on Feature Creep\n\nIf this pattern feels familiar, it is.\n\nProduct management has had a language for it for years.\n\nThe Kano Model describes how features fall into three categories: basic expectations, performance improvements, and delight features. Most feature requests fall into the first category. Adding more of them rarely increases satisfaction. It mostly increases complexity.\n\nIf you're not familiar with the model, [I wrote a short breakdown](https://www.ericnparadis.com/posts/kano-model)\n\n### The Real Job of Product Leadership\n\nGreat product leaders do something subtle. They listen to what customers say. Then they reinterpret it. They ask:\n\nWhat job is the user trying to accomplish?\\\nWhat friction are they actually experiencing?\\\nWhat outcome are they chasing?\n\nOnly then do they design the solution.\n\nAcross multiple companies and platforms, the pattern is consistent.\n\nCustomers ask for features.  \nGreat teams uncover systems.  \nCustomers describe symptoms.  \nGreat teams discover the real problem.  \nAnd the best products rarely look like the original request.\n\nIf you ever find yourself building the 100th cup holder, pause. You may be solving the wrong problem. Because great products are not built by implementing requests. They are built by understanding what users are actually trying to\nachieve.","2026-03-09T18:54:56.758Z","2026-03-09T18:54:56.760Z",1776201805371]