How to Do Things Your Customer Didn’t Ask For

Some time ago I got a question from Sebastiaan, one of my colleagues. He told me he was struggling with an important issue:

Should we spend time on things the customer didn't (explicitly) ask for?

Here's his full question:

Hey Jurgen,

I am curious about one aspect of Scrum that I don’t really like. Right now we have acceptance criteria and we adhere to them strictly. So strict even, that we’re now starting to say [to the Product Owner]: "No, we are not going to do this, because it is not in the acceptance criteria."

However, a lot of times, we know that this will mean one of two things:

  • rework later;
  • customer not dissatisfied, but not extremely happy either.

I think part of the reason that we get return customers is not just because they got what they wanted, but also that they got more than they bargained for, with minimal effort on our side. Sometimes you just want to add some real value to the work item that you’re busy with, that will only take an extra hour and will “wow” the customer. How do we deal with that in an agile/Scrum way?


This question was so interesting that I had to think about it for six weeks before feeling able to reply (sorry Sebastiaan). Anyway, here are my thoughts:

The underpromise, overdeliver principle tells us that we should manage our customer's expectations in such a way that we are able to deliver more than the customer asked for. It is easy to see why this works. You save yourself some slack in case things go wrong, meaning you have some time to solve any problems. But if things work out well, you have some time left to do something extra for the customer, assuming (note I'm stressing the word assuming here) that the customer will be pleasantly surprised with the extra cherries on top.


The question of how best to satisfy customers has been described in the Kano model, published in 1984 by Dr. Noriaki Kano. In Implementing Lean Software Development, Mary and Tom Poppendieck wrote this about the Kano model:

Kano noted that increasing performance [implementing more features] gives linear results – customer satisfaction is increased in direct proportion to the increased performance. To get an exponential increase in customer satisfaction, you need to discover and meet unmet needs and thus surprise and delight customers. Kano said that great products do not come from simply listening to what customers ask for, but from developing a deep understanding of the customer's world, discovering unmet needs, and surprising customers by catering to these needs.

So, does that mean that the team should build what they think will delight the customer?

Absolutely not!

As Kano pointed out in his work, it takes deep understanding of the customer's world to understand how to delight a customer. The average team member is usually too far away removed from the customer to really understand her world. That's why there's a Product Owner in Scrum. The Product Owner represents the customer, the users, and any other external stakeholders. It is the Product Owner's job to deeply understand the customer's world. It is the team's job to deeply understand the technological world. Together they should be able to build a product that will delight the customer.

(Of course, it is even better when the team tries to understand the customer's world, while the Product Owner tries to understand the technological world. But never should a team be allowed to implement features without asking.)

A year ago, in my blog post Oh My God, They Killed the Bug (You Bastards!), I blogged about someone having solved a "problem" in my car that I didn't want to be solved. I had a rotating knob on my gear stick, but when my car was returned to me the knob was fixed. It was a fine example of a technical team trying to understand my needs as a customer, and attempting to overdeliver by (literally) fixing something that I had not pointed out as a problem. They completely missed the mark, and I was furious. I had grown fond of my silly old rotating gear stick, and it took me a month to get used to the new situation.

The road to hell is gold plated with good intentions…

So, here's my 4-step guide to delight your customers:

  1. As a team member, while planning a new sprint, make suggestions to the Product Owner about things that you think might delight the customer. Don't feel bad if the Product Owner doesn't agree with your suggestions. He is supposed to understand and speak for the customer. (But I'm sure the Product Owner will appreciate your ideas.)
  2. When the Product Owner asks for a change during the sprint, and when you agree that the change is a good idea, then do it! Who cares if the changed feature wasn't listed among the acceptance criteria of the sprint? Agile is about "people over process". If the people involved want it, then it must be good. Sticking to acceptance criteria is a process. And process is for wussies.
  3. If, during a sprint, you have a great idea that you think is worth doing within the sprint, talk about your idea with the Product Owner first. Don't assume he is going to be pleasantly surprised later during the sprint review. I'm sure he will be even more pleasantly surprised if you contact him first and ask him if it's OK to spend some time on your suggested change.
  4. If, for some reason, the Product Owner is unavailable, and you think implementing your idea now will save you serious problems down the road, then do it. But make it reversible! Try to delight the Product Owner as soon as he is available, but roll back the change if it turns out he doesn't like it.

Fixing the knob on the gear stick in my car was not on my acceptance criteria. I probably wouldn't have minded the technical team "fixing" it, if they had shown immediately what they had done when they delivered my car. And if they had been able to "unfix" the gear stick before the color of my face had turned shiny red, I would have been delighted at their proactive, communicative and technical skills.

(pictures by nutmeg and mccun934)

Twitter TwitterRss SubscribeEmail NewsletterDelicious Bookmarks

Latest, greatest and favoritest posts:
Great Managers Have No Secrets
Communication = Information * Relationships
Oh My God, They Killed the Bug (You Bastards!)

  • So, Now You're an Agilist... What's Next?
  • The Big Agile Practices Survey
Related Posts
free book
“How to Change the World”
  • Sebastiaan

    Looks like the TypePad developers could use my input on when to ask if I’m SURE that I want to close the window. I typed a comment and thought I’d hit the “Post” button, must’ve been “Preview” though…
    Anyway, what it said was:
    Thank you for the elaborate reply to my short question!
    Did you ask the mechanic why they “fixed” your gear stick? In my experience with car mechanics are as bad as communicating as software developers are perceived to be. Maybe they saved you from a very dangerous situation on the road!
    I think our product owner is going to be happy with your guide. However, I am immediately concerned about scope creep.
    A good product owner will know to limit changes during a sprint, but they also want to look good for the customer. In that way, they’re also gold plating whenever they can get away with it.
    I guess it’s up to the team (developers AND product owner) to make sure that this doesn’t get out of hand.
    Still a difficult call to make sometimes.

  • Sebastiaan

    Ah, I was multi tasking and didn’t see the captcha when I closed the window after hitting post. Total UX FAIL though… Show the captcha while posting or not at all, sheesh.

  • Ryan Kohn

    A colleague and I discussed a similar point a few days ago. We were talking about the best way to propose further work to an existing client for whom the project has already been completed and closed.
    The typical approach is to leave things be until the client approaches you with additional work. The client will, of course, be satisfied with this arrangement (based on the assumption that you do good work, which is the case, right?).
    But what about work that you think would benefit the client, that they didn’t specifically ask for?
    You can’t just go ahead and do the work and send them a bill afterward. I doubt they’d pay. But if you approach them to suggest the work, they might like your idea. In that case, you can agree on a rate for the work and deliver it as expected. It’ll work out much better for the both of you.
    On any project, you shouldn’t be arbitrarily extending the hours required to do the work and then charge by the hour. That sounds a lot like robbery.

  • Jurgen Appelo

    @sebastiaan: *always* do a Ctrl-C of input text before clicking on any web form button! 🙂
    I never asked the car mechanics why they “fixed” my gear stick. I only noticed when I was on my way home.
    And true, successful projects depend on good Product Owners, and good software developers.

  • Roel

    Interesting post,…
    The other way around might also be interesting, what if the customer asks for something which you don’t really want to build? Sometimes customers tend to have strange ideas about what should be implemented. (for example ‘I want music on my homepage’)
    We have experience and we know the market, functionality like this should be managed away by the product owner or the scrum master I think.


    Thoughtful blog post. A hard question clearly answered.

  • Matthew

    The biggest problem with every project is the customer not asking for what they want. If you can regularly work out what a client actually wants then you’re half way to being a success.

  • Curious Cat Management Improvement Blog

    Management Improvement Carnival #61

    Submit suggestions for the management improvement carnival.
    Unplanned items and legacy issues by Xavier Quesada Allue – A small change request if you want. How are you going to manage this work? Are you going to create a new story for this? To…

  • Codetoglory

      I think the approach should be different for the kind of products we are building. If they are disruptive, obviously customers cannot completely drive the requirements. One good example is IPhone.
      The other approach is the regular agile appraoch for driving the product backlog via customer involvement.

How to Change the World - free Workout - free