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
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:
- They trust that your product will work on their machines.
- They trust that you will help them if they have problems.
- They trust that you will continue to improve the product.
- They trust that you will provide them with a reasonable and fairly priced way of getting those improved versions.
- They trust that you are not going out of business anytime soon.
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
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:
- I don't want a traditional sanitized
marketing voice. I want to hear real people speaking in the first
person about their company and its products.
- I'm not
interested in a press release that contains one small quote from the
CEO. I want the entire thing to be a quote from the CEO.
don't want to hear from people whose job it is to talk to me. I want to
read stuff written by the actual developers working on the product.
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
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
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:
- First, your customers can talk with you.
They can ask you questions when they need help. They can tell you about
bugs. They can request new features. They can gripe when they get
- Second, your customers can talk to each other. They can commiserate when your product bothers them. They can help each other.
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
- Make it easy for people to post comments or questions. Use good forum software that doesn't get in everybody's way.
- Encourage everyone in your company to participate. The community works better if your developers are active in the discussions.
a gentle moderator. Delete personal attacks or stuff that is completely
off-topic, but don't delete a post just because somebody is griping
about your product. (If they're complaining, that's because they care,
and you probably deserve it anyway. Let them gripe, and go make your
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
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:
- A product gets "wider" when it appeals to new users.
- 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:
- How polished is your product? Does it merely function, or is it shiny and clean?
you find time to fix the Low and Medium priority bugs? Or do you fix
the Urgents and the Highs and let the other stuff linger around?
you spending developer time to make your product nicer or faster or
easier for your current users? Or do you forget about them as soon as
you have their money?
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
- We fight a battle we cannot win. Those who want to cheat will succeed.
- 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
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:
- 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.)
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
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:
- Is the company profitable?
- How much cash does it have? How much debt?
- What kind of corporation is it? Who are the owners?
- Do they have outside investors?
- Is the founder still involved? Does she still have a decent equity stake?
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
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.
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:
- If you want to talk about SourceGear products, please visit our public discussion forum.
you want to talk about the principles and suggestions in this article,
join me on Joel Spolsky's discussion site where I moderate a forum
called The Business of Software.
- If you want to talk about how great the Illini basketball team is this year, I sometimes hang around on IlliniBoard.com. :-)
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 http://software.ericsink.com/.
This article originally appeared on the MSDN website.