Home About Eric Topics SourceGear

2005-02-14 15:00:01

Tenets of Transparency

Summary: Eric claims that if ISVs are unwilling to trust their customers, then they won't have any.

Reminding my readers once again that I am not a Microsoft employee, I observe that over the last year or two, the world has seen a different posture from the developer tools groups at Microsoft. They've opened up. The buzzword for this movement is "transparency". Some folks have told me that the leadership driving this concept comes straight down from Eric Rudder, Senior Vice President in charge of Servers and Tools.

This concept of transparency is visible in many different ways, including their Community Technology Previews and the Product Feedback Center. But perhaps the most obvious change is the ubiquity of weblogs by Microsofties of all kinds. Not that long ago I was habitually reading every weblog written by a Microsoft employee, every day. Today there are so many Microsoft weblogs I just can't begin to read them all. Only Scoble can read that much stuff. :-)

In this column, I want to closely examine this concept of transparency and talk about why it is so important, even for a small ISV.

The Magic of Selling Software

If you really think about the nature of an ISV, selling software is an amazing thing. Throughout recorded history, most products have been tangible. When I buy land, I can plant corn on it. When I buy a table saw, I can use it to rip a board down its length. When I buy an orange shirt, I can be properly attired for an Illinois basketball game. These products are tangible.

In contrast, software is digital intellectual property, nothing more than a bunch of bytes that happen to be in the right order. In fact, here at SourceGear, most of our sales never involve anything physical at all. Money flows in our T-1 line and products flow out. Sometimes it seems like magic. Customers are buying something completely intangible, and they're giving us real money for it!

However, as the old saying goes, money doesn't grow on trees. Whether the customer is buying software or guns or butter, all product buyers need to have a certain level of confidence and trust before they can make the difficult decision to part with their money. Speaking as a consumer, I need to feel different levels of trust for different kinds of products. Buying a car is a very high-trust deal. Buying paper clips? Not so much.

I observe that buying software is closer to the "high trust" end of the spectrum. When people buy software from your ISV, they are expecting a lot from you, both now and in the future:

So, by asking customers to pay for your software, you are asking a lot. You are expecting them to trust you. But how much do you trust them?

Declaring my intention not to stretch this metaphor too far, I compare the ISV/customer relationship to a relationship between two people. Relationships don't work without mutual trust. If one side expects trust but is unwilling to give it, the relationship will simply fail.

So often I see software entrepreneurs who don't want to trust their customers at all. It is true that trusting someone makes us vulnerable. Just as in a human relationship, trust is a risk. We might get hurt. But without that trust, the relationship isn't going to work at all.

Transparency is an ISV's way of trusting your customers. By letting your customers see behind the corporate veil, you extend them your trust, making it easier for them to trust you in return.

Here in the Midwest there is a restaurant chain called Steak-n-Shake that seems to understand transparency. Their slogan is "In Sight It Must Be Right". The idea is that if you let your customers watch you prepare their food, you can't slip anything funny into the burger.

If this doesn't make sense yet, please bear with me. In the following sections I will discuss eight ways that ISVs can trust their customers by being transparent.

1. Have a Weblog

When I am a customer of another ISV, I want to see weblogs:

Weblogs give me a way to see the people behind the products.

Noting that weblogs come in all flavors, I want to clarify what I mean. Lots of weblogs are written by individuals who feel compelled to tell the world what they had for breakfast and whether they found a way to get laid last night. Others keep a weblog to write about their religious or political views, or to provide extended family with daily pictures of their kids. These are not the kinds of "blogs" I have in mind.

The style I am recommending here is what most people would call a "corporate weblog". The goal is to give the world a personal glimpse of the people behind the product, but not to get too personal. Let people see who you are, but stay mostly on topic. The point is to write about your company and your products, not about the arcane details of your life.

If you are working in a small ISV, consider writing a weblog, but please do go into this challenge with your eyes open. Writing a good weblog is harder than it looks. It takes a lot of time and effort. But when it's done right, a weblog can be an excellent way to make your company a bit more transparent.

2. Offer Web-based Discussion Forums

Together, you and your customers form a community. What kind of community do you want to be? Do you want to live in a neighborhood where everybody stays in their house to watch "Law and Order" reruns? Or would you rather get outside, enjoy the air, compliment your neighbor's lawn, and commiserate about the price of gas?

One of the easiest and best things you can do for your customers is to give them a place to talk. People like to talk, especially when they have something in common. A simple Web-based discussion forum can provide a place for this to happen.

The great thing about this kind of forum is that it allows two kinds of communication to take place:

When everything works out just right, the result can be a huge benefit for you and your customers. An active community will increase the overall gravity of your products.

However, real community is a strange thing. You cannot really force it to happen, but you can definitely prevent it from happening. The basic guidance is to provide the infrastructure and clear the obstacles:

By the way, this seems like a great place to insert a gratuitous plug for my good friends over at Telligent Systems. If you need good software for weblogs or discussion forums, they've got what you need. (I have no connection to the company.)

Give your customers a place to talk about your product, even if you don't always like what they say. This is a great way to extend them your trust.

3. Don't Hide Your Product's Problems

As I mentioned above, software customers usually want to know that a product will be steadily improved in the future.

There are exceptions to this rule of course. Last week I purchased a computer Scrabble game for about $20. In this case, future upgrades are not very important for me. I just want to play the game in its current form. Unless I find some horrendous bug, I don't really expect this vendor to ever provide me with an upgrade.

But most software products aren't like that. When people buy Vault from us, they often ask questions about the future of the product. They plan to be using our product for a long time, and they just want to know that we will be continually improving it along the way.

But not only do users want you to keep improving your product, they usually care about specifically how the product grows and matures. They want to be reassured that your product will be growing deeper, not just wider. I define these terms like this:

  1. A product gets "wider" when it appeals to new users.
  2. A product gets "deeper" when it works better for the users it already has.

The usual way to make a product wider is to add more features. Reaching an entirely new segment of customers often means adding entirely new capabilities to the product. For example, we are currently in the process of adding Eclipse integration as a feature for Vault. While it is true that some of our existing customers have requested this feature, the primary motivation here is to reach out to new customers.

The problem is that ISVs can easily fall into the bad habit of always making their product wider without making it deeper. The connection between "new features" and "new revenue" is easy to see, but it's harder to make a business case for doing things that simply make your existing customers happy.

Yet, we know intuitively that if our customers are unhappy, we're going to be in trouble. So it is critical that you find time in your small ISV to do the things that keep your current customers happy:

So what's my point? Here it is: Companies that try to hide their product's problems are usually the ones that never fix them.

No software product is perfect. All products have problems. The only question is whether the vendor is fixing them or not. By being open about the problems in your product, you identify yourself as a company who is willing to be held accountable for getting those problems fixed. That's the kind of company that customers can trust.

4. Don't Annoy Honest People

First let me clearly say that I do believe it makes sense for most ISVs to implement some sort of mechanism to help users be compliant with the licensing terms of their product. I will call this mechanism "license enforcement code".

But let's not sugarcoat anything here. License enforcement code is a terrible waste. We spend time and money to design, implement and test it, just like any other feature of the product. However this "feature" adds no benefit for the user.

I therefore believe it is critically important to never go too far when including license enforcement code. The goal should simply be to "keep honest people honest". If we go further than this, only two things happen:

  1. We fight a battle we cannot win. Those who want to cheat will succeed.
  2. We hurt the honest users of our product by making it more difficult to use.

It makes sense to optimize your product for the honest users, since they are by far the most common case. License enforcement code should be simple and minimalist. By including license enforcement code, you are telling your customer that you do not trust them. Don't shout this message -- whisper it. Since it adds no value to the honest user, the best you can do is to cause them no harm.

All SourceGear products use a simple serial number scheme for basic license enforcement. We try to make this functionality completely painless. But I'll confess that we had to walk somewhat of a winding journey to get here.

When we released Vault 1.0, we included a "product activation" system that was designed to prevent people from using the same Vault serial number on two servers. We figured that even though everybody hates product activation, we could get away with it because Microsoft is doing it. ("It's not our fault! Microsoft started it!")

But things didn't turn out the way we expected. First of all, the Microsoft product activation scheme doesn't seem to work as badly as I thought. I still hate the idea in principle, but I have to admit that Microsoft's product activation has never caused me any real inconvenience. A few months ago I built a new PC for my home. I bought new copies of Windows and Office, and in both cases, the product activation Just Worked.

On the other hand, SourceGear's experience with product activation was very unsatisfying. The "feature" worked most of the time, but it was really frustrating in those times when it did not. On several occasions I found myself on the phone trying to help a customer who was having trouble with activation. It is one thing to have a customer who can't get the product installed because of a goofy configuration. But it is ten times worse to have a customer who can't install the product because of a glitch in our license enforcement code. Sometimes it felt really embarrassing.

Product activation increased our technical support load, annoyed our customers, and gave us more code to maintain. If we received any benefits from product activation, they were invisible. We ripped it out for the Vault 3.0 release. Not only does it make more sense to trust our customers, it's a lot less work.

5. Offer a Painless Demo Download

This is so standard nowadays that I feel silly mentioning it: Provide a demo download so people can try your product before they buy it. I doubt that any serious ISV today would try to implement a policy where customers must always pay before even seeing the product.

Nonetheless, although there should be no question about "if" you have a demo download, there are good questions to be asked about "how" you manage it. The high-trust path looks like this:

  1. Use time-limited demos, not feature-limited. (People who use "crippleware" as their demo are not willing to trust me, so I don't trust them.)
  2. Don't ask people to register just to see a demo. (I want to evaluate your product, not your privacy policy.)
  3. Don't make people agree not to talk about your product. (People who try to prevent me from talking are trying to hide something, and are not to be trusted.)

The way you handle your online demo is another opportunity to express trust in your customer.

6. Offer a Money-Back Guarantee

Perhaps the ultimate expression of trust for an ISV is a money-back guarantee. If for some reason they change their mind after making a purchase, they stop using the product and you give them back their money. It is typical to give them 30 days after the sale to make this decision, sometimes more. The motivation for this kind of policy is very simple: You are making it easier for customers to enter into a relationship with your ISV by eliminating all of their risk.

A money-back guarantee dramatically increases the transparency of your company. Now your prospective customer can see everything a customer can see. They can taste the product, sample the technical support and smell the purchasing process. If any of it displeases them, then they can just hit "Undo" and get a refund.

This kind of policy seems very risky, but anecdotal evidence consistently suggests that it's really not. I have spoken with quite a few ISVs who offer a money-back guarantee, and they all say the same thing: Very few people ever ask for the refund, but lots of people experience greater confidence about their purchase.

7. Share a Little About Your Financial Standing

When I buy software from a small ISV, I usually wish I could know all kinds of things about the company's financials:

I suppose I am nosier than most. I know how the guts of an ISV work, so I always find myself wondering about all the gory details.

I am not suggesting that you divulge all of this information. However, sharing a few select tidbits can sometimes increase confidence for your customers. Lots of software companies don't survive. Customers want to know if your firm will be around for a while. If your firm is conservatively managed and operating profitably, let people know.

8. Talk About Your Future Plans

Conventional wisdom says you should never make a promise you cannot keep. That's good advice, and I agree with it 100%.

But some interpret this advice to mean that you should never make any promises at all. I believe we can do better. Customers really want to know about your future plans. They want to know what new improvements will appear in the next release and when that release will be available. When they ask these questions, surely there is something you can say?

Just remember to always under-promise and over-deliver. As long as you carefully stay within this boundary, consider talking with your customers about your plans for future releases.

Ways in Which You Might Want to be Opaque

Thus far, I have described a level of trust and vulnerability that may seem outrageous. In response to those who might (perhaps understandably) diagnose me as a raving idiot, I would say two things:

First, I don't necessarily expect every ISV to implement every suggestion I listed above. As always, please use common sense to figure out the degree to which my advice is a good fit for your situation.

Second, I don't expect any ISV to be completely transparent. Even if you act on all of the points above, there are still a lot of things that you probably want to hold private.

For example, customers don't need to know your actual revenue and income numbers. They don't need access to the internal databases you use for tracking work items or technical support tickets. They don't need to listen in when your team argues about the priority to place on a bug they reported.

Just as relationships do not function without mutual trust, they also do not function without healthy boundaries.

Practicing What I Preach

As I wrote this article, I had a crisis of conscience. I can honestly say that SourceGear today would score very well on 7 out of the 8 points above. However, the other one haunted me as I wrote this piece.

Since founding the company in 1997, we have been selling software products with a stated policy of "no refunds". We encourage our prospective customers to take full advantage of our 30-day demo period, liberally extending it when they need more time. We prefer that people spend plenty of time evaluating before their purchase so that we don't have to fiddle around with the hassle of refunds.

In general, this approach has worked, but it's not perfect. We occasionally get somebody asking for a refund even though our Web site clearly explains our "no refunds" policy. And the truth is that despite our apparently strict policy, we don't want money from anybody who doesn't love our products. We don't get many requests for refunds, but I can't think of a situation where we refused a customer who asked for their money back within a reasonable amount of time.

So our policy is inconsistent with our practice, and when refunds do happen, there is no standard procedure for handling them in a consistent manner. Furthermore, our stated "no refunds" policy just doesn't make us look very friendly. I suspect that for some people it raises questions about our trustworthiness.

It is time for us to change. Effective immediately, SourceGear's policy is to offer a 30-day money back guarantee. I won't bore my readers here with the details, all of which can be found on our company Web site. I share this story merely because my own journey on the subject of transparency may be instructive to readers.

Bottom Line

After publishing an article, I often hear from people who want to discuss it with me. This time I would like to try and guide that discussion traffic into the right places:

I will close with one final piece of advice. Quibble over the details if you like, but don't avoid the main point of this article: You cannot expect your customers to trust you if you are unwilling to trust them. You might not like my suggestions. That's okay. But you still have to figure out how this principle applies to your situation.

 

Eric Sink is the non-legendary founder of SourceGear, a developer tools ISV located in Illinois. Eric considers himself lucky to be one of the few people to get season tickets to Illinois basketball this year, even though his seats are in the very top row. More of Eric's writings and rants can be found on his weblog is at https://ericsink.com/.

This article originally appeared on the MSDN website.

Copyright 2001-2023 Eric Sink. All Rights Reserved

If you are in need of contract software development services, I would appreciate your consideration of SourceGear.