Skip to main content

Successful Growth, but how?

Last week, I attended Basler Insurance's Forum for Small and Medium Enterprises. This year's theme was "Successful growth, but how?"

One talk stood out for me: Dr. Martin Strobel, CEO of Basler/Switzerland presented, 'Delighting your Customers: Profitable Growth through Value-Added Solutions'.

Here is the problem: Your market is saturated. Your product is not sexy. You are losing market share to more competition from other industries who are perceived as more dynamic. How do you turn this trend around? Or: You are a small player in your market. There are 7 or 8 players who are bigger than you. You can't attack all of them, so how do you grow in the face of tough competition?

These are exactly the problems Basler faced. The Swiss insurance market is quite saturated, but the banks have been gaining market share with high return (but high risk) investment instruments. In Austria they were barely a top 10 player.

In both cases, the answer was to get in the shoes (or more precisely in the heads) of their customers: Understand the customer, who he is, what he wants to do and why wants to do it.

Yes, a family father wants an attractive return in a industry with exciting potential. But he also wants security that his money will be there when he needs it. Yes, a homeowner wants the financial loss covered if his house burns down. But he also wants to be sure he gets out of the house if it does catch fire and he is probably interested in preventing a fire in the first place.

Kano Diagram, modified by StevensIn Austria, they identified doctors as a niche market and set out to understand what doctors need. They even went so far as to hire doctors to help them design their products. They came up with a customized product, which extended beyond the boundaries of a traditional insurance product but met the deeper needs of their target market.

Results: In Switzerland, first months sales for their combined product (with a 60/40 split between security and high return) were double their expectations. In Austria, they have been able to take a 40% market share in their target market niche (doctors and dentists) -- and networking with their customers is driving them to carry the product to other countries and markets.

Those of you who came to my talk on in the World Trade Center on Lean Software Development and Scrum will recognize the principles of product success (represented by the modified Kano diagram, above):
  1. Excite your customers. This is our highest goal in product design.
  2. Understand your customers. Deeply.
  3. Design your products to meet their needs, even the ones they don't about yet.
Thank you Dr. Strobel! This was a beautiful confirmation that the principles of lean product development can produce successful products on a grand scale!


Anonymous said…

This is an interesting article, however what you describe is based mostly on the works done by Kano. The graph you are showing seems to come straight out of a Kano questionnaire book. I find it odd that there is no reference to his work in your article? Did the person giving the talk reference it?

Lean has actually "copied" this from his product development work
Peter said…
Hi anonymous,

You are quite right, this is a Kano diagram. And every source on Lean and Agile that I have read (e.g. Mike Cohn, Tom & Mary Poppendieck) refers to it my name, as I do in this blog entry: "represented by the modified Kano diagram, above".

I call it a modified Kano diagram because I have never seen anyone else graph the effect of deterrents on customer acceptance.

I have to admit, the reference text is a bit far from the picture (blush). An editing error -- blogger doesn't let me set the title or alt text without editing some very gory HTML, so I tried to do it in text.

In any case, I believe Lean does not copy Kano, but simply builds on his work.
Peter said…
One more thought -

Lean -- and here we should credit Tom & Mary Poppendieck, because they formalized it for Software -- goes much further than just Product Design. Risk Management, Process Optimization, Contracting, Organizational Trust, Iterative developement....

It is a complete school of thought to drive product development from initial concept to actual revenue generation.

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 …

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…