In my career, I’ve been lucky enough to work for companies that did cool stuff. This goes for both my employer and my clients. Nothing is so energizing as to work with really smart people who create really cool products. One that will always stick with me is the Nextel FanView. 
The FanView started as a product from a Canadian company called KangarooTV. The details of the business arrangement are unclear to me so many years down the road but basically Nextel bought the product (or partnered with the company) and hired my employer-at-the-time to improve the usability of the product. The end result was a killer product that allowed NASCAR fans unprecedented real-time access to race information while physically at the race. It really took sports spectating to an unprecedented level of interactivity. They were keenly aware of their target customer and provided numerous easy-to-use features that complimented the experience without standing in the way.
Sometimes, products I’ve used and even some I’ve worked on, seem a hodge podge of features, slapped together with little regard for how those features will actually be used. This is often the case when product development is an undertaking solely oriented at satisfying one particularly squeaky wheel – usually a customer or executive. Since companies are in the business of making money, it seems obvious that listening to customers is a good idea. And since executives are the ones responsible for ensuring us lowly employees get to take a paycheck home, we want to listen to them, too. The problem comes when the new features being demanded are added reactively without a long term vision for how this fits in with the direction of the product and how it satisfies the needs for all of our customers or stakeholders.
In Agile project management, a system’s features evolve in reaction to user needs. In Agile, the customer is first and so development tasks are always driven by a User Story. User Stories are written from the perspective of a specific user (possibly a defined user persona) and speak of a specific need for that user. For instance: “As a small business B2B owner I want to ensure I’m paid on time by customers” might turn into a feature which sends SMS messages to that User on the 31st day after an invoice was sent so they know to send a follow-up invoice. Overly broad user stories (like my example, to be honest) are refined or split up until their requirements are clear and then the stories are then broken down into distinct tasks that can then be assigned to the necessary design & development staff to implement the requirements to satisfy the story. Agile, in my opinion, is the best way to create a usable, accessible, and useful product.
Customer collaboration over contract negotiation. Agile Manifesto
So why do even Agile teams create products with hodge-podge features? I think its due to this reactive mentality that doesn’t include a vision for what the real end goal of the system should be. Without a vision – one that gets enforced – you wind up with Homer Simpson’s car. 
In one episode of The Simpsons, Homer discovers he has a brother he never knew he had. His brother (voiced by Danny DeVito) owns a car company and is so overjoyed at learning he has a brother that he lets Homer design a car. Homer wants to make the best car ever, so he adds everything to this car you can imagine, inspired by his own whims and the cool features of other cars. The end result is a hideous looking disaster and completely ruins his brother’s company. How do you avoid designing Homer Simpson’s car? Clearly not hiring a known idiot like Homer Simpson is a good start. But even non-idiots design disasterously bad products because they continue to slap on features.
I think one step to solving this is by creating what I call the One True User Story. As I mentioned earlier, User Stories are written from the perspective of a customer, and written to satisfy a specific need. This means, I hope, we have a clear picture of who our users are. Like I said, “hopefully”, because it would be somewhat stupid to make a product that doesn’t have a customer. So if we’ve done our homework to define our customers, we should know what they are expecting – in other words, we should know what need the customer has that we seek to address with our product. This is the One True User Story.
“As a fitness enthusiast who travels frequently on business, I want to be able to adhere to my workout schedule while on the road”.
The One True User Story for a gym-finding mobile app I am currently building.
The One True User Story is our vision for what this product will be. It is intentionally broad – far too broad, in fact, to be directly actionable, as it describes the overall story of the specific user and the primary need we hope to address. The point of the One True User Story is that when we begin Sprint planning, nothing should ever be added to the product backlog if it fails to address the One True User Story. If it is useless when measured against the One True User Story, or if it conflicts with the One True User Story, it must be erased from our minds, never to return, never given a moment’s consideration as we move on toward those potential features that do satisfy the One True User Story.
By calling this the One True User Story, I don’t mean to suggest that there is really only one thing. Our product may have many customers. It may have many dozens. They are, in fact, no different than the personas developed by our friends in UX. Each customer persona should have their own One True User Story and each story written throughout the life of the product needs to be compared against it and priority given to stories that most closely complement the goals of the One True User Story.
I can envision times when the One True User Story will overlap in some ways across personas. To me, this indicates an opportunity to prioritize the development of new features that satisfy the goals of multiple people. They will probably also come in direct conflict across personas. This would indicate a need for features which would personalize the experience for the user types in conflict. This may mean making two different products rather than trying to satisfy everyone in a half-assed fashion. Requirements may (in fact, probably will) change. The vision may evolve. The population of users may change. These are all actually very good things. In any case, the One True User Story for those users must be obeyed, lest we create our own version of Homer Simpson’s car.
I’d be very interested in hearing what others think of this idea and whether it is something they think would be useful or are already doing in some way.
For more information on Agile and Lean UX, I recommend these resources: