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.

Comments

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

Why do you create your product?

Popular posts from this blog

Scaling Scrum: SAFe, DAD, or LeSS?

Participants in last week's Scrum MasterClass wanted to evaluate approaches to scaling Scrum and Agile for their large enterprise. So I set out to review the available frameworks. Which one is best for your situation?

Recently a number of approaches have started gaining attention, including the Scaled Agile Framework ("SAFe") by Dean Leffingwell, Disciplined Agile Development (DAD), by Scott Ambler, and Large Scale Scrum (LeSS), by Craig Larman and Bas Vodde. (Follow the links for white papers or overviews of each approach).

How to compare these approaches? My starting point is Scrum in the team. Scrum has proven very effective at helping teams perform, even though it does not directly address the issues surrounding larger organizations and teams. An approach to scaling Scrum should not be inconsistent with Scrum itself.

Scrum implements a small number of principles and constraints: Inspect and Adapt. An interdisciplinary Team solves the problem. Deliver something of va…

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…

10 Warning Signs, that your team is not self-organizing

How do you know that self-organization is working? The Bern Chapter of Scrum Breakfast Club looked into this questions, and identified the following warning signs (which I have taken the liberty of translating).

The team reports to the Scrum Master at the Daily ScrumPeople wait for instructions from the Scrum MasterTeam members don't hold each other responsible [for their commitments]The same impediment comes up twice"That's the way it is" => resignation"I" instead of "We"Flip charts are lonelyCulture of conflict-avoidanceDecisions processes are unclear, nor are they discussedPersonal goals are more important than team goals
To this list I would add my a couple of my favorites:
you don't see a triangle on the task board (not working according prioritization of stories)after the daily Scrum, people return directly to their desks (no collaboration)there are a least as many stories in progress as team members (no pairing)
P.S. You can join the …