Skip to main content

Good Profits, Bad Profits, and Roaming Profits

Today, I opened the latest issue of K-Tipp (the Swiss equivalent of Consumer Reports) and they reported on the new Data Roaming Rates of the three big Swiss Telcos. Although the Telcos claimed simpler, lower rates for customers, the rates are still high and confusing. I believe these companies are doing a tremendous disservice to themselves, which will eventually cost them market share and profitability. They are creating Brand Debt.

Under the new rates, Switzerland's leading provider charges 30 Swiss cents / 30 KB. There is a daily limit of CHF 7, unless you exceed 5 MB, in which case, access costs 30cts per additional 30KB. Why don't they say CHF 10/MB? Here in Europe we have the metric system for a reason! And what is this limit that is not a limit?

It sounds like I could send an email up to 30 KB for 30 cents. Is that true? Far from it! I measured the data volume to sign on to the internet and check my email: 1330 KB with no new messages! (OK I'm a special case: I have 5 IMAP accounts and a VPN). I check my email at least 5 times per day, so I'm looking at CHF 33 / day, just to check email (before I even do anything!) If I actually read mail, send mail, surf the internet (or heaven forbid, listen to internet radio), it would cost much more, even if I took one of the roaming packages these carriers offer.

What's wrong with these rates? Obviously some people pay them and I am sure the carriers make a lot of money off of data roaming. The problem is the additional messages that these companies are sending to their customers:
  1. Our goal is to make sure you can't figure out what the service will really cost.
  2. We will hit you for all we can!
  3. GO TO ANOTHER PROVIDER!!
These are Bad Profits.

How can you make Bad Profits with Data Roaming? Roaming is a great concept! I can take my telephone or PDA anywhere in the world and be reachable, make calls or surf the net! It's a great idea that can simplify my life tremendously. The engineers have done a great job of building a great product. All the potential is there for the customers to be delighted.

But the people who decided the pricing policy have said, "let's milk it for all it's worth!" Why is this a bad thing? Because they are accumulating debt. Brand Debt. Someday they will have to pay this debt.

Everybody understands that financial debt is a bad thing. You borrow money and have to pay it off with interest in the future. Over the long term, you cannot spend more than you earn (unless you are a government). Sooner or later, you have to pay off the debt. If you can't service the debt (pay the interest), you are bankrupt and lose your house and other valuables.

Engineers know that technical debt is a bad thing. If adding a new feature to your system causes more errors than it creates in value, your code is effectively dead (bankrupt). So good engineers know they have to write tests, refactor the code, review their work, and build safety nets to ensure that they are not taking on technical debt when they implement new features. Otherwise, sooner or later the technical debt will be so great that they cannot add new features. They will have to throw the product away and start again from scratch.

If your brand has a good reputation, people will trust you, perhaps even love you, and be happy to buy your services. Look at Apple: People stand in line to buy every new product they bring out.

Accumulating Brand Debt means you are chipping away at the value of your brand. Remember the 70's joke about two GM product lines, Chevrolet (the people's car) and Cadillac (the top-of-the-heap luxury car, before Mercedes took over this position)? What is the difference between a Chevrolet and a Cadillac? Oh, about 6 thousand dollars.' That was a serious case of brand debt. It took Cadillac a long time to recover its position. (Did it ever recover its position?)

Bad profits mean you are accumulating Brand Debt. Bad profits look good on paper might be easy money because your customers don't (at the moment) have good alternatives, but they annoy your customers. Given enough time and brand debt, your customers will surely find an alternative.

How can you tell if your company is accumulating Brand Debt? Here are some warning signs:
  • You're afraid to talk to your customers due to the problems it might cause
  • Your revenue is stagnating or shrinking, especially in a growing market
  • You're thinking, this market will cease to exist in a few years, so let's milk it for what it's worth.
  • The alternatives to your product are substantially cheaper than your product, only inertia is keeping your customers on board
With Scrum, the team is focused on creating value for customer or user. This is essential for creating great products.

But having a great technical team is only half the battle. Your company needs the right purpose. The purpose is to delight the customer. Good profits are what you get when you delight the customer.


Interested in continuing this discussion? Join us for a Gathering on Radical Management in Washington DC, May 12 & 13, 2011. Earlybird pricing until March 31.

Comments

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 …