Perhaps you grew up with the idea that you don’t want to merely meet expectations, you want to exceed them. But is that really the right thing to do?
At the risk of stating the obvious, exceeding expectations is going above and beyond promises or current expectations. How can that not be the right thing to do?
The key is to set realistic customer expectations, and then not to just meet them, but to exceed them — preferably in unexpected and helpful ways. — Richard Branson
Richard Branson sets this up perfectly. How we exceed expectations is in relation to the expectation baseline. He also notes that what we deliver beyond expectations should be helpful.
Exceeding expectations is the wrong thing to do when the value received from going above and beyond is less than something else you could otherwise deliver. It defies a core Agile principle, a Lean Startup concept, and the Theory of Diminishing Returns — all super important in product development.
I’ve worked many years leading teams delivering software solutions. It’s common to want to keep adding cool features that we presume improve the product, or to extend the capabilities of existing features. What ends up happening is we deploy code that supports features rarely used in lieu of higher-value deliverables.
You should absolutely look for ways to exceed customer expectations, but there’s a way you should go about it to maximize effectiveness. Let’s take a look at how Agile, Lean, and the Theory of Diminishing Returns recommends managing expectations.
Agile Principle
Simplicity — the art of maximizing the amount of work not done — is essential.
“The art of maximizing the amount of work not done” is one of twelve principles from the Agile Manifesto. In my experience, it is the hardest principle to grasp. How can maximizing the amount of work not done produce the most value?
The premise of this principle is teams often do more work than is necessary to meet the objectives. The result is spending time in less valuable endeavors than they should.
Have you heard of gold-plating? Gold-plating is where the team works on adding bells and whistles beyond what is needed to meet the need. It’s not that the extras aren’t useful — they often provide some value. The issue is if you independently prioritized this extra work among all other work, it would not likely be the next right thing to work on. Yet, these extras get worked on anyway in an effort to “make it better while we’re in there.”
A mature team only produces just enough to meet the need, and nothing more, then moves on to the next right thing. Why add extras, or exceed expectations, when the current solution isn’t yet validated.
As I wrote in “Why ‘Requirements’ are Bad,” we should work from assumptions that need validated rather than presuming definitive requirements. We can exceed expectations once we validate we’re on the right path. Until then, do as little as needed to meet the need and validate.
This approach allows the team to turn their attention toward more valuable work, based on independent value and priority. You have to decide, are the above and beyond features you want to add more important than any other work your team could work on? If not, release it for validation and move on to your next highest priority.
Lean Concept
Minimum Viable Product (MVP)
If you have any exposure to Agile, you likely know the term minimum viable product, or MVP. You may have also heard it called minimum marketable product or minimum marketable feature. The point is, it’s the minimum you need to deliver to meet the requirement or goal — it is barely sufficient, but sufficient none-the-less.
The word minimum may throw you off because you, like me, learned the minimum is not good enough. You’ve heard all your life that you must go above and beyond and exceed expectations. MVP is a tough concept to grasp. Where do you draw the line at what is sufficient and what is lacking?
It’s important to understand that the key word here is viable. By definition, viable means it is capable of working successfully. A minimum viable product fully meets the need, but no more.
Why is MVP an important concept to embrace? Our natural desire is to implement the most amazing features, and all of them, in version 1.0. That simply is not prudent, and many times not feasible due to technical, time, or cost constraints. Therefore, hard decisions need to be made.
In making priority decisions, MVP comes into play, not just for the product as a whole, but for feature sets as well. You must consider what provides the most value and what has diminishing returns.
Theory of Diminishing Returns
When producing anything, you deal with a concept called the Theory of Diminishing Returns, also known as the Law of Diminishing Returns. As the chart above shows, the greatest value delivered in any project occurs in the earlier phases of the effort. Once the MVP is attained, the incremental value available becomes less and less compared to the effort required.
What your decision ultimately comes down to is this — is the additional value you can provide by going above and beyond on one thing greater than the value you could provide by putting time and resources into starting a different task, or project?
For example, is that user interface enhancement for an existing feature more important than implementing the next product feature that does not yet exist? Which provides the sharpest rise in incremental value? Only you can make that value decision. If you are truly going to find success with agile product development, MVP is a concept you must embrace.
In Conclusion
What defines MVP will vary between teams, products, and organizations. Remember the words viable and sufficient? It’s all relative.
A market leader in software may not be able to launch a barebones product and expect to win in their market space. For them, MVP is a more feature-rich product than perhaps a startup that is first to market with a new idea.
On the other hand, a product used internally within your organization might be able to forego some user interface polish in favor of implementing some automation capability that will relieve workflow pressure in a process that is backed up.
In the end, your goal should be to keep each work item as small as possible while focusing on building out the features that can independently rank highest in your priority list. If what your team is about to add or modify is not required to make it work, ask yourself, is that add-on more valuable than the next highest priority item in your backlog?
Remember, first make it work, then make it work better based on independent priority and value.
To learn more about this and other management concepts supporting agile product development, check out the book Pursuing Timeless Agility: the Path to Lasting Agile Transformation.