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!
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.


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…