Managing Customer Expectations in Agile Framework!

Always deliver more than expected

– Larry Page

Managing Customer Expectations: This may sound like a slight overlap on our previous discussion about going the extra mile in an agile context. I do admit, there are a few similarities, In the last discussion, we went through the importance of definition of done, customer expectations management in an agile context.

In this one, we focus slightly on the balance of MVP Vs delivering more than expected. I would also like to touch on the aspect of satisfiers vs Dissatisfiers, but I would like to use the MOSCOW framework today for the scope of this discussion.

Today’s motivation is derived from a beautiful quote by Larry Page – Always deliver more than expected. It is indeed a simple, yet powerful one. But the question remains at large – how practical is this in an agile context where we are expected to deliver consistently. Add to this, the complexity of time and strict deadlines. I suppose these are the segments we will need to think through in an agile context – how do we continually surprise the customer positively?

1. Managing customer expectations:

Coming from a customer facing background, I would always focus on the primary question of any developments we do. This may be a bit fine tuned towards the agile processes in product development. However, I do think, at times the development team can get isolated from a customer which has resulted in a fair few famous failures.

In the end, we are all in the business of meeting customer expectations, if not exceeding them. The harsh reality is that we can engage a customer as long as the needs are fulfilled and we solve a real problem. The moment it stops making sense to a customer, we lose out and the discussion of attrition, churn etc kick in.

1.1 Promise less, deliver more

One of our investors always used to say – you must always promise less and deliver more. I do admit, it took a  long time for me to let the message seep. The flip side however is that we can’t promise nothing and claim that we’ve reached our goals and lived up to the promises. It never is as simple as that.

We are indeed talking about managing customer expectations. It needs to be a fine balance between the two. We do however have to be absolutely sure of delivery before we commit or else it is a slippery slope down the loss of customer trust.

1.2 Does Agile say Deliver the bare minimum? – MVP

It is a fair question to ask. Agile processes aim at achieving quick results, taking customer feedback and making changes. The aim of the process is to incrementally produce a product with which the customer’s needs are met.

1.2.1 Does this mean that we produce the bare minimum at each stage?

The answer I suppose is a YES and a NO. Yes, we can commit to incremental, small changes as opposed to a waterfall approach where the change is known after a long period of time. But this never is at the cost of quality of an outcome. One of the common issues I’ve noticed is that quality and time are often under contention. With an intense competition, the question is between quality and the scope.

Of course this is an individual decision and boils down to a company’s mission and vision. I would however note that trust is often the hardest thing to maintain in businesses. And if we compromise on quality, it makes a clear headway for defining customer losses and attrition.

2. Packets of pleasant surprises

Always deliver more than expected – I would like to call it a packet of pleasant surprises. I have never complained about getting an extra item in an order if it is something I like.

In the last discussion, we were talking about satisfiers and dissatisfiers. Most definitions of done would cover all the minimum requirements where the basic product requirements are outlined. The satisfiers however are aspirational goals. These have a  great potential of making customers happy and keep them surprised in a positive manner.

If I were using the MOSCOW methodology of prioritisation, these are the segments of Could Have as opposed to SHOULD HAVE or MUST HAVE. We can never afford to compromise on those. One of the earlier posts also discussed the differentiation between a minimum viable product and a minimum lovable product. I suppose these are the extra distinctions which can start making a product more lovable and closer to the end user.

In essence, these additional deliveries take the relationship with a customer beyond mere transactional scope into something stronger. It goes beyond the discussions of customer loss and attrition to trust, brand loyalty which are far more fascinating challenges to embark on.

On that note, I would like to bring the focus back to today’s inspiration

Always deliver more than expected

– Larry Page