Skip to main content

8 Questions for a Product Owner on Customer Delight

It's easy to talk about delighting the customer, but how do you really do it? As a Product Owner, it is your responsibility to create great products.  How do you take this philosophy and transform it into competitive advantage for your company or your project?

During our workshop, "Making the Whole Organization Agile," Steve Denning lead the participants through a series of exercises and role plays: 12 Practices of Customer Delight. I decided to participate this time around, and reflected on how I could improve my own business. I was stunned at the ideas I was able to produce. I'll come to that at some point...

Here are first 8 questions Steve in our Delight the Customer workshop:

1. What is your goal?

As a product owner, you should always be clear on this. It can however be helpful to challenge your ideas. Think of an idea for a product or service. Is this a new idea or an extension of an existing product or service? If its a new product, try to think of an extension to an existing product. If you thought of an extension, try to think of something totally new for your customer.

2. How will it play with your customers?

Now that you have an idea or two, how will customers react to it? In the course, participants find two people to role play interested, but critical customers. In the real world you can ask real customers. You be the salesman, entrepreneur or inventor. Your partners play the interested customer - not the customer from hell! and not the apathetic customer - interested, but a bit skeptical. What do you learn from these interactions?

3. Who is your core customer?

Who are the people you have to delight? What outcomes do they want?  Sometimes you have a distinction between users and buyers. For instance top managers buy a CRM system but relatively low-level staff use it. Sometimes the relationship is even more obtuse, e.g. Google gets money from Adwords customers, but provides value to internet search users, who make up 98% or more of the clicks. Even though these users provide no revenue (this time), Google's ability to generate ad revenue depends on the loyalty and presence of search users.

4. What do your customers want (or rather, think they want)?

Ask them. They'll tell you. Of course they don't know what they don't know so you'll need to go beyond that.

5. What do your customers really want?

What is the need behind the features they have asked for? Customers generally ask for incremental innovations. Disruptive innovations address the needs of new customer segments. Disruptive innovations may well seem irrelevant or undesirable to established customer segments. Brainstorm! Keep your eye out for disruptive innovations. And surprise your customers with something unexpected.

6. What is it that your core customers might not like about your product?

Bad profits. We have all experienced them. For example: many airlines have discovered many sources of bad profits: Fees to change your ticket that are so high you're better off throwing the ticket away. Invalidating your ticket because you skipped a leg. Charging you for checked baggage. Charging families extra to sit together. Who likes to pay these fees? They are a rip-off! Such practices get your customers upset. Those are what we call bad profits! What are you not going to do, so that your customers don't get upset?

7. How could you delight your customer sooner? 

Faster is almost always better. This question was a real "Eureka!" moment for me. One of the first signs of a successful agile transition is improved employee morale. How can I make this happen faster? Watch this space...

8. Could you delight more by doing less?

My DVD remote control has 54 buttons - and I use about five of them. My friend's TiVo remote has 28 buttons... and I use about five of them. My daughters iPod has five buttons. Less is more. What can you simplify or get rid of to make your product better?

Questions 7 and 8 really helped me move my thinking forward. I am now considering entirely new avenues for my business. Should be fun!

Want to experience and learn the practices yourself? Want to learn the remaining four practices? Want to transform your product or service? Come to my workshop in Seattle, Making the Entire Organization Agile, June 26 to 28.


vdgJolly said…
May I put in another question towards the Product Owner?

Why do you create your product?

Popular posts from this blog

Sample Definition of Done

Why does Scrum have a Definition of Done? Simple, everyone involved in the project needs to know and understand what Done means. Furthermore, Done should be really done, as in, 'there is nothing stopping us from earning value with this function, except maybe the go-ahead from the Product Owner. Consider the alternative:
Project Manager: Is this function done?
Developer: Yes
Project Manager: So we can ship it?
Developer: Well, No. It needs to be tested, and I need to write some documentation, but the code works, really. I tested it... (pause) ...on my machine. What's wrong with this exchange? To the developer and to the project manager, "done" means something rather different. To the developer in this case, done means: "I don't have to work on this piece of code any more (unless the tester tells me something is wrong)." The project leader is looking for a statement that the code is ready to ship.

At its most basic level, a definition of Done creates a sh…

Explaining Story Points to Management

During the February Scrum Breakfast in Zurich, the question arised, "How do I explain Story Points to Management?" A good question, and in all honesty, developers can be an even more critical audience than managers.

Traditional estimates attempt to answer the question, "how long will it take to develop X?" I could ask you a similar question, "How long does it take to get the nearest train station?

The answer, measured in time, depends on two things, the distance and the speed. Depending on whether I plan to go by car, by foot, by bicycle or (my personal favorite for short distances) trottinette, the answer can vary dramatically. So it is with software development. The productivity of a developer can vary dramatically, both as a function of innate ability and whether the task at hand plays to his strong points, so the time to produce a piece of software can vary dramatically. But the complexity of the problem doesn't depend on the person solving it, just …

Money for Nothing, Changes for Free

“Money for Nothing, Changes for Free” encourages both customers and suppliers to focus on value.

A key advantage of Scrum projects is that at least once per sprint you have something that could be shipped and no work in progress. You can change direction every sprint, and you can reevaluate whether the project is a good investment or if your money could be better spent elsewhere. Abrupt cancellation is risky for the supplier.

While the concept of an early-exit penalty is not new, Jeff Sutherland gave it a unique allure with his allusion to the Dire Straits hit.
Desired Benefit Incentivize both customers and suppliers to focus on functionality that provides genuine value.
Structure This works with Agile software projects because there is little or no work in progress. After each Sprint, functionality is either complete or not started. Work is basically on a Time and Materials basis with a cost target, often with the intention that the project should not use up the entire project budge…