SharePoint Vendors – You’re Spamming Me!

Christian Buckley (@buckleyplanet) posted an article with advice for SharePoint Saturday event organizers on how to adjust their marketing mix to make events more feasible.

The advice in the article is great, but I was a bit thrown back by one comment he made regarding what sponsors should expect.

The gist of Christian’s advice is that sponsors at least expect to get a list with names and addresses of opt-in participants. If that was the end of it, then fine, but of course, that would make this a very boring blog article, so let me quickly quote directly from Christian’s advice.

I’m amused when I hear someone complain about getting emails from sponsors following an event, or of being “harassed” by sponsors as they try to move between sessions at an event. Some call sponsors a “necessary evil.” That’s a screwed up perspective, if you ask me. The sponsors are what make these events possible. As much as the organizers like to think of themselves as the catalyst, sponsor funds make it all happen.

– Christian Buckley

Even with the opt-in clause, this doesn’t resonate with me at all. You see, sending email to someone with content they haven’t requested is at best a shot in the dark, from the hip, at a very long distance, and at a small and fast moving target.

Simply put, it doesn’t work.

Welcome to My Spam Folder

Gmail has a wonderful anti-spam technology. I have absolutely no idea what happens behind the scenes, but I know a couple of things about what’s happening on my end.

Over the years, I’ve marked marketing messages I haven’t requested as spam. For example, if I’m forced to register to get a quote on behalf of a client and I later get messaging about how great the vendor’s product is, then all you will hear from me is the sound of the inside of my spam folder.

Over the years, I’ve also noticed that more and more messages from SharePoint vendors automatically end up in that same spam folder. I briefly see their names and carefully crafted email subjects before I click the “Delete all spam messages” link, and they’re gone forever.

This hurts the vendors more than me, and does so in two ways.

First, like I’ve commented on Christian’s blog article, the vendor has forever lost an opportunity to communicate with me. Their messaging may be the greatest news since the dawn of man, the cure for cancer, or a ticket to free sex and beer forever, but I won’t see it and I’m fine with that (I don’t really drink that much and I’m married so I don’t have sex in any case).

Second, you are giving out a very wrong message when you contact me about things in which I have no interest. You’re nagging me to get my attention. If I don’t respond (or even if I do) you nag more. Why would you treat me any different if I buy from you? You demonstrate that you’re unwilling to respect my time as a potential client, so why would you respect me as a client? I have on at least two occasions refrained from recommending two particular vendors to clients because their constant nagging really annoys me and I don’t trust that they will leave my clients in peace if I were to recommend them.

Why do I not simply unsubscribe? Well, I do, but that’s not the point here. I want to tell you, as a SharePoint vendor, that you’re at best not getting nowhere near your money’s worth and at worst, lose your ability to communicate with your potential clients and even worse, lose money on sure-fire recommendations. There are far better and more efficient ways to get new clients, and I’ll tell you how later in this article.

I work with a lot of clients and talk to a lot of SharePoint professionals. I recommend products all the time. No later than yesterday I explicitly recommended a particular company building an Outlook plugin to a consultant, and I’m fairly certain that client will make a purchase. You know what’s weird? I’ve explicitly asked them to contact me on at least two occasions, and I’ve never seen their names in my ‘about to be deleted’ list. In fact, I’ve never seen their names in my regular inbox either, except regarding the information that I requested.

It’s Still Spam!

The opt-in clause for email contact is important for several reasons. First, the legality is a factor, at least in many countries. You need to get someone’s permission to contact them through email with a marketing message. The US has CAN-SPAM and similar laws exist throughout many civilized countries.

You can certainly argue the technicalities of whether something is ‘spam’ as defined by any particular legal system, but if it is unwanted, uninteresting, and intrusive, it will still be perceived as annoying spam. That reflects on you, as the vendor.

The other factor, though, is what Seth Godin calls Permission Marketing, but sadly, it seems that only the title and maybe a brief abstract of Seth’s work have made it past the earwax of many SharePoint vendors.

You see, getting my email and ‘permission’ is not a carte blanche for talking to me all the time. When you say something to me, you’re taking up my time, interrupting me in whatever I was already doing. That means that it should be worth something to me too in order for me to be interested in reading your next message or the message after that.

When an event, for example, has a checkbox (and far too often checked by default) to get information from vendors, you have no idea what I want. I also have no idea what to expect, except ‘information’. What normally happens is that your address is added to an ‘opt-in’ list and sent the exact same message as anyone else received from any other source of email harvest.

I’ve been to some events where for whatever reason I get added to these ‘opt-in’ lists, and vendors I’ve never even met send me messages afterwards saying how great it was that I stopped by their booth, and by the way, here’s some information about our products.

Then there’s the infamous ‘put your business card in this bowl for a chance in a raffle‘ scheme. Why would you want my business card? You can get 250 of them for free over at Vista Print. What you want is my email address so that you can start sending me information I have not requested.

What a complete waste of your resources and my time! How is that possibly going to interest you in what you have to say, when you’re not just harvesting my email with no information about what I can expect, but you continue to send me at best badly targeted messages, and then churn me into a grey mush of people to which you feel permitted to say what you want at any time?

What if you were honest about your intent? “Give me your email address so I can send you information you have not requested, and you get a chance to win a 50 cent per copy piece of dead tree product” Do you think you’d get many takers? Maybe, but I’m fairly certain you’d get only those who want the book for free, not your information. You shouldn’t care for those people, you should care for those that want your information, at yelling at everyone in the hopes that someone listens, well, it doesn’t work anymore.

Ask Me Before You Abuse Me!

Permission marketing may not be the end to all marketing problems, but it does state a few interesting ideas.

First, you, as a vendor, need to get permission from people before you take the next step in your messaging. I’m not talking about a checkbox where you can be multi-added to a bunch of vendors during an event sign-up, I’m talking about how you need to ask me whether you can send me more information. If I don’t explicitly give you that information, you do not assume you have that permission.

Second, you can never abuse one permission to get another permission. For example, if I’ve requested a quote for your product, you have my permission to give me that quote. You have permission to follow up that quote until I either purchase or tell you that I won’t. However, you do not have permission to email me product information, great offers, new releases, or anything like that. Possibly, but even this is stretching it a bit, you have my permission to ask follow-up questions about why I chose or didn’t choose your quote.

This way, your marketing becomes a conversation with me rather than you saying what you want to say to a bunch of people who most likely aren’t listening. This way, I get something of value from our conversation.

Don’t get me wrong; you always have my permission to ask me for my permission. Ask me “Bjørn, although you didn’t go for our quote, may we send you an occasional newsletter containing information about our products?” or “Bjørn, sorry you didn’t bite this time, but may we send you product information when we’re releasing new version of said product?”. Perhaps even “Hi Bjørn, thanks for attending the SuperDuper SharePoint Event. We got your email as part of a sponsor deal, but want to make sure it’s OK with you to contact you further. Are you OK with us sending you a couple of product links and a video describing our products?”

By all means, have a huge Yes button available, but respect it if I don’t click it. And if I do click it, make damn sure you send me what you said you would send me, no more, no less.

Promises and Expectations

Think about it. If you buy a product for $10 and you get something completely different than what you expected, would you be likely to want to keep doing business with that vendor? How about if you purchased something for $10 and got exactly what you wanted? I know that at least I’d be much more likely to both recommend and continue business relations with the latter company, the one that gives me what I expect and you promise.

Now, what changes if the prices goes down to $1? Am I more happy to get something that doesn’t do what it says on the tin?

What if the price is zero? Why would I be more happy with getting something other than what you’ve promised or I requested, if the price is below a certain point or even free?

You’re not getting happy customers, you’re getting people who feel they’re not getting what they want or worse, something other than what they expected and you promised.

Think about it once more and keep doing that until you realize I’m right, as always.


Found this article valuable? Want to show your appreciation? Here are some options:

a) Click on the banners anywhere on the site to visit my blog's sponsors. They are all hand-picked and are selected based on providing great products and services to the SharePoint community.

b) Donate Bitcoins! I love Bitcoins, and you can donate if you'd like by clicking the button below.

c) Spread the word! Below, you should find links to sharing this article on your favorite social media sites. I'm an attention junkie, so sharing is caring in my book!

Pin It

New USP Journal Issue SPInvoice Explained Available for Pre-Order

I’ve been spending the holidays relaxing and writing (I find that relaxing, so sue me…). I’ve been writing on a new USP Journal issue called SPInvoice Explained.

Well, I’ve decided to open up for pre-orders of this new issue, and it’s available right now.

The full issue should be out in early February, but to whet your appetite, you can purchase now and receive a pre-release bonus package consisting of:

  • Draft version of first three chapters, notes and comments included
  • Development version of SPInvoice (Visual Studio 2010)
  • 30 minute video walkthrough of the solution and the techniques used (not the same as the one below)

After final release, the pre-order package will no longer be available. However, as a pre-order reader, you will of course get the full and completed version as soon as it’s done.

SPInvoice is targeted at fairly advanced developers. In this issue, you’ll learn advanced SharePoint development concepts such as

  • Building solutions that upgrade across SharePoint versions
  • Understanding custom configuration options in SharePoint
  • Developing advanced user experiences with delegate controls and state management
  • Building rapid taxonomy solutions
  • Creating advanced user interfaces using jQuery and SPServices

You can check out a preview video of the user interface of SPInvoice here:

Ready to pre-order? Here’s the issue page:


Pin It

Become a SharePoint Professional – What Is a SharePoint Developer?

So you want to become a SharePoint professional and have come to one of the most tricky questions to answer: What is a SharePoint developer?

Actually, the question is rather easy to answer, once you have some common and basic understanding of what SharePoint development entails.

What Is a SharePoint Developer?

If you look at the term, and throw away any personal feelings for what you think words should mean, then it becomes quite clear what a SharePoint developer is. Let me illustrate.

If you want to get your hair dressed, you go to a hair dresser, and from that we can assume that a hair dresser dresses hair. If you want something baked, you go to a baker (or your local medical marijuana outlet, but that’s for another blog), so a baker is someone who bakes. If you want to get something moved, you hire a mover, and a mover is thus someone who moves.

Now, if you want to get something developed on SharePoint, what could we possibly call the person that does that task? You should get this right on the first try; we call them a SharePoint developer.

Another commonality between the hair dresser, the baker, and the driver, is that you are rarely interested in the tools they user to perform their task. You don’t say to a baker that you only want to buy his bread if it’s made with a specific stand mixer. You usually aren’t interested in the brand of scissors your hair dresser users, and the lifting support the movers use, well, as long as they get that piano up the stairs, you don’t really care, do you?

And even if you are interested and specific about the tools used for whatever valid or invalid reason, you’ll still call them bakers, hair dressers, and movers, even if they user different tools. The reason for this is that their job titles describe the tasks they perform, not the tools they use. You don’t have KitchenAid bakers or a Shiro hair dressers (yes, I had to Google that). You may have a heavy items mover, but you would still call other people who move things movers, even if they don’t have specializations in moving heavy items.

So, a SharePoint developer develops in SharePoint, as simple as that. If, or rather when, you start picking up the conversations that have been ongoing for years in the community about whether people using specific tools are allowed to call themselves developers, well, ignore them and think about what makes sense.

The first duty of any SharePoint developer is to solve business problems. As long as you do that, and you do so in a professional manner, the tools you use or the title you put on your business card is largely irrelevant. If you think that the term developer is too ambiguous, and honestly, even the SharePoint community cannot really agree on what it means, then feel free to call yourself whatever you want.

By solving business problems, I mean that your first focus isn’t necessarily to work with a business owner or client, but that the ultimate goal of your solutions is to cater to the needs of the business. Many developers may never see much less talk to an end user or business owner, but SharePoint is a business platform first and foremost.

However, SharePoint development is a complex profession. In fact, it’s not even a profession, it is a class of professions that to some extent are defined by the tools they use.

SharePoint Developer Tiers

In broad terms, you can categorize SharePoint development methods into three tiers.

Note: This tier division is the brain child of luminary Marc D. Anderson, detailed in his Middle-Tier Manifesto.

The first tier deals with development using the web interface and client software only. First tier developers utilize the web interface to build taxonomies for business objects, create user experiences using web parts and maybe a few simple pre-made scripts, installs and configures Apps and Sandbox solutions, builds information panels for Office, and so on. First tier developers benefit from the most rapid development methods at the expense of freedom and power.

The middle tier of SharePoint development starts utilizing specialized tools and uses scripting and markup to develop solutions. Typical tools are SharePoint Designer, InfoPath, and maybe Visual Studio for script development. Middle tier development produces more flexible and customizable solutions than is the case for the first tier, and middle tier developers have more freedom and power at the expense of having to do a lot more work and be somewhat limited in terms of solution portability.

The third tier developer focus solely or mainly on developing WSP solution files and managed code solutions using tools such as Visual Studio and extensions such as WSPBuilder, VS Tools for SharePoint, and STSDev. Third tier development offers the greatest degree of freedom and options and also gives developers the most power of all the tiers. However, this comes at a price, of having to build all the ‘bits’ they need and also of needing the discipline to harness all that power.

What is important to know is that these tiers are not mutually exclusive. Although most seasoned SharePoint developers spend most of their time in one of the tiers, they also utilize the other tiers when required. A middle-tier developer may build a prototype for a solution taxonomy before building a web part in SharePoint Designer to display or manage that taxonomy. A first tier developer may utilize SharePoint Designer to modify or create scripts or style sheets to build their sites, and a third tier developer will more often than not start a project by prototyping the solution in the first tier.

What is absolutely critical to know, however, is that none of these tiers are better or worse, nor that developers that specialize in any of the tiers are better than the developers of other tiers. What matters to your skill level is what development skills you have, not the tools you use. Any SharePoint developer regardless of favorite tier will need skills and understanding of development topics such as source control, debugging, data modeling, event handling, security, and so on. Tools are there to make these tasks easier, not to save you from having to know these topics.

Also not that the developer tiers is a broad categorization. Once you get familiar with each tier, you will likely want to focus even more. For example, first tier developers may specialize in taxonomy or client applications, middle tier developers may specialize in InfoPath or DataView web parts, and third tier developers may specialize in workflow or web part development.

How To Become a SharePoint Developer

Regardless of what type of SharePoint developer you want to become, you need a good understanding of what SharePoint is and what problems it solves. If you are using SharePoint in your job, for example, you may want to start exploring the possibilities that exist. Ask whoever is responsible for SharePoint (or ask a mirror if it is you) to give you a site collection in which you can experiment.

Start going through the list and library types available to get an idea of the tasks SharePoint can handle. Explore the existing web parts, look up the site and site collection features, explore the permissions model, and so on. In short, play with it to see what it can do beyond what you already do.

Note: There are plenty of resources available to learn SharePoint, but rather than recommend any specific resource, I encourage you to start practicing your Google skills and find the resources that make sense for you.

When you decide to start your SharePoint development career, focus on learning the tools and methods in which you have prior experience. You should already be well versed in using SharePoint and understanding its capabilities, and if you have no other development experience, this is a great starting point for first tier development.

If you have prior HTML and JavaScript experience, then looking at the options in the middle tier may be appropriate for you. If you know XML and its related technologies, that’s even better. Get yourself a copy of SharePoint Designer (it’s free) and start looking at your site or site collection through the eyes of that tool. Also, start looking at the client-side object models.

If you have prior programming experience, defined as building compiled code in some form, then the third tier will likely give you the most familiar starting point. You’ll need to get Visual Studio, and you need to start learning the SharePoint object models (server and client-side, so no cheating). Further, if you don’t already dream in XML, you haven’t used it enough.

Note: Beyond XML, your language and tool choice in the third tier is largely up to you. In fact, you can build third tier solutions using Notepad if that’s your fancy.

Since I’m the one writing this, let me modestly take this chance to blatantly promote my own book on learning third tier development, Beginning SharePoint Development, as a great resource to get you up and running. You can pick it up from In fact, all of my USP Journal issues will help you become a better SharePoint developer.

SharePoint Developer Myths Debunked

As your development career moves along, you’re bound to come upon many myths that may or may not sound plausible. Let me wrap up this article by debunking some of them.

First, SharePoint development is not harder or easier than developing on any other platform. You’ll find plenty of statements from developers saying that development on SharePoint is too hard. The fact is that the hard part isn’t any harder in SharePoint than it is on other platforms. Like any other platform, SharePoint has its bad and good sides. Any task you know is easy and any task you don’t know seems hard, at least when you get beyond the “how hard can it be” stage.

Second, a SharePoint developer does not have to do compiled code programming. One of the most common myths is that to be allowed to call yourself a developer, you need to be a programmer of compiled code. See the initial sections of this article for an explanation of why this is bollocks. If you develop, you’re a developer. If you bake, you’re a baker. If you move, you’re a mover. If you dress hair, drive, build, paint… Well, you get the picture.

Third, third tier SharePoint development is not your last resort. You’ll also quickly find a plethora of claims that building third tier solutions should be your absolute last resort, after trying everything else, including prayer. The arguments are often that third tier solutions are difficult to maintain and upgrade.  The fact is that well-built SharePoint solutions not only upgrade excellently, but can actually work across SharePoint versions, making upgrades easier than for other development tiers. Note the emphasis on well-built.

Finally, no SharePoint developer is an expert in all SharePoint development tasks. SharePoint is a complex mistress, and its developers need to focus to satisfy her needs. The less you focus, the less you become good. Each development tier takes years to master. If someone say they are experts in more than one or two tiers, they are probably just experts in pulling your leg, or they’re just plain ignorant.

Note: The same applies to recruiters. A clear sign of a recruiter who has no idea about how to find SharePoint developers is one that looks for experts in multiple tiers or even specializations.

Final Thoughts and a Warning

A SharePoint developer is a resource to any organization, and a career in SharePoint development can yield both material benefits and great personal rewards. At the time of this writing there is a great shortage of skilled SharePoint developers and since a SharePoint developer’s first duty is to solve business problems, as long as businesses have problems, you’ll have a job.

In fact, take this as a warning. Right now, you can get a job as a SharePoint developer if you manage to spell SharePoint correctly.

However, having a job is a far stretch from being an expert. Don’t expect to quickly become a SharePoint developer expert simply because you can rapidly churn out solutions that impress your boss. Any skill in which you want to become an expert requires you to focus and dedicate considerable time to both learn and practice.

Before you develop these considerable skills, remember that what you are doing is ultimately what the business will use to remain profitable. Your failures or lack of skill may cost the company much in terms of lost efficiency or revenue, or cost employees their jobs. Start with what you know, practice before you go into production, and make sure you learn the basic skills of software development.

This isn’t unique for SharePoint, though, so take it as general advice. Expect to spend thousands of hours increasing your skill if you want to become an expert SharePoint developer.


Pin It