SmoothSpan Blog

For Executives, Entrepreneurs, and other Digerati who need to know about SaaS and Web 2.0.

Archive for March, 2010

Three Deadly Sins of a Startup CEO

Posted by Bob Warfield on March 30, 2010

I have had the unpleasant experience of being involved with or hearing quite a bit of the blow-by-blow associated with the replacement of a CEO at one company or another.  While I have not experienced the ultimate displeasure of being replaced myself (despite “ousted” rumors to the contrary!), I can tell you that it is a very very messy business.  So much so that I resolved at one point just to leave any company if the CEO was replaced.  At Helpstream, I had not counted on the Board tapping me to take up the role.  Caught like a deer in the headlights when they approached me, I did not resign per my plan.  I don’t regret that, and have since amended that plan of action, and not just for the case where I get to be the CEO.  The reason I had made the plan in the first place was that in the past I had always seen a tremendous loss of momentum that could take years to recover if it ever came back at all (in fact it didn’t in most other examples).  But with a startup, things are nimble enough that it may be possible to use the opportunity as a catalyst for change.  VC’s must think so, as I have read that up to 75% of startup CEO’s are replaced at some point.  My new plan involves staying if there are some very clear changes in strategy and execution that will be made immediately and that have the promise of immediate impact.

This brings me to the point of this post: the Three Deadly Sins of a Startup CEO.

There are many more than three deadly sins, and a host of venial sins, but these three, if allowed to continue for very long, are almost invariably fatal for the tenure of a startup CEO:

1.  Thou shalt not miss thy numbers.

2.  If thee misses thy numbers, thou shalt have an explanation and plan broadly agreed upon by Ye Olde Board.

3.  If thou hast no such plan, then thee will be humble and willing to accept and act on any advice or coaching thy Board may provide.

Pretty simple.  If you make your numbers, the Board leaves you alone for the most part.  BTW, many of them will be from the school of “Let’s raise the bar if it looks too easy” and you’ll be judged against peers who may not be especially fair comparisons, but dems da breaks, kid.  If you don’t make your numbers, you had better have a plan your Board believes in or you’d better be willing to take their advice and act on it ASAP.  BTW, all startup CEO’s will commit one or more of these sins unless they are supernaturally lucky.  They may even violate all three.  It’s a matter of not violating all three at the same time for too long.

Also note that violating all three doesn’t necessarily make the CEO a bad person.  It may simply mean they don’t know why the plan didn’t work, and don’t believe the VC’s plan (cut your staff in half and hunker down until it blows over) will help either.  Sorry, this is about political capital, not who is right.  It melts and runs away like butter on a hot tin roof so long as you’re violating all three.

The CEO has a lot of perks from the perspective of the ranks below.  Good Boards give them quite a lot of autonomy.  The VC’s don’t really want to run your company.  But as Bob Dylan said, “You’re gonna have to serve somebody.”  In this case, it is you Board, and if you lose sight of that, it’s going to be rough for you.  I’ll talk about the whole issue of the numbers and the Board in a later “Learnings” post.  This is also quite fascinating and can seem confusing until you understand where everyone is coming from.

Posted in business, venture | 2 Comments »

Minimizing the Cost of SaaS Operations

Posted by Bob Warfield on March 29, 2010

SaaS software is much more dependent on being run by the numbers than conventional on-premises software because the expenses are front loaded and the costs are back loaded.  SAP learned this the hard way with its Business By Design product, for example.  If you run the numbers, there is a high degree of correlation between low-cost of delivering the service and high growth rates among public SaaS companies.  It isn’t hard to understand–every dollar spent delivering the service is a dollar that can’t be spent to find new customers or improve the service.

So how do you lower your cost to deliver a SaaS service? 

At my last gig, Helpstream, we got our cost down to 5 cents per seat per year.  I’ve talked to a lot of SaaS folks and nobody I’ve yet met got even close.  In fact, they largely don’t believe me when I tell them what the figures were.  The camp that is willing to believe immediately wants to know how we did it.  That’s the subject of this “Learnings” blog post.  The formula is relatively complex, so I’ll break it down section by section, and I’ll apologize up front for the long post.

Attitude Matters:  Be Obsessed with Lowering Cost of Service

You get what you expect and inspect.  Never a truer thing said than in this case.  It was a deep-seated part of the Helpstream culture and strategy that Cost of Service had to be incredibly low.  So low that we could exist on an advertising model if we had to.  While we never did, a lot was invested in the critical up front time when it mattered to get the job done.  Does your organization have the religion about cutting service cost, or are there 5 or 6 other things that you consider more important?

Go Multi-tenant, and Probably go Coarse-grained Multi-tenant

Are you betting you can do SaaS well enough with a bunch of virtual machines, or did you build a multi-tenant architecture?  I’m skeptical about your chances if you are in the former camp unless your customers are very very big.  Even so, the peculiar requirements of very big customers (they will insist on doing things their way and you will cave) will drive your costs up.

Multi-tenancy lets you amortize a lot of costs so that they’re paid once and benefit a lot of customers.  It helps smooth loads so that as one customer has a peak load others probably don’t.  It clears the way to massive operations automation which is much harder in a virtual machine scenario.

Multi-tenancy comes in a lot of flavors.  For this discussion, let’s consider fine-grained versus coarse-grained.  Fine grain is the Salesforce model.  You put all the customers together in each table and use a field to extract them out again.  Lots of folks love that model, even to a religious degree that decrees only this model is true multi-tenancy.  I don’t agree.  Fine grained is less efficient.  Whoa!  Sacrilege!  But true, because you’re constantly doing the work of separating one tenant’s records from another.  Even if developers are protected from worrying about it by clever layering of code, it can’t help but require more machine resources to constantly sift records.

Coarse-grained means every customer gets their own database, but these many databases are all on the same instance of the database server.  This is the model we used at Helpstream.  It turns out that a relatively vanilla MySQL architecture can support thousands of tenants per server.  That’s plenty!  Moreover, it requires less machine resources and it scales better.  A thread associated with a tenant gets access to the one database right up front and can quit worrying about the other customers right then.  A server knows that the demands on a table only come from one customer and it can allocate cpus table by table.  Good stuff, relatively easy to build, and very efficient.

The one down side of coarse grain I have discovered is that its hard to analyze all the data across customers because it’s all in separate tables.  Perhaps the answer is a data warehouse constructed especially for the purpose of such analysis that’s fed from the individual tenant schemas.

Go Cloud and Get Out of the Datacenter Business

Helpstream ran in the Amazon Cloud using EC2, EBS, and S3.  We had help from OpSource because you can’t run mail servers in the Amazon Cloud–the IP’s are already largely black listed due to spammers using Amazon.  Hey, spammers want a low-cost of ops too!

Being able to spin up new servers and storage incrementally, nearly instantly (usually way less than 10 minutes for us to create a  new multi-tenant “pod”), and completely from a set of API’s radically cuts costs.  Knowing Amazon is dealing with a lot of the basics like the network infrastructure and replicating storage to multiple physical locations saves costs.  Not having to crawl around cages, unpack servers, or replace things that go bad is priceless. 

Don’t mess around.  Unless your application requires some very special hardware configuration that is unavailable from any Cloud, get out of the data center business.  This is especially true for small startups who can’t afford things like redundant data centers in multiple locations.  Unfortunately, it is a hard to impossible transition for large SaaS vendors that are already thoroughly embedded in their Ops infrastructure.  Larry Dignan wrote a great post capturing how Helpstream managed the transition to Amazon.

Build a Metadata-Driven Architecture

I failed to include this one in my first go-round because I took it for granted people build Metadata-driven architectures when they build Multi-tenancy.  But that’s only partially true, and a metadata-driven architecture is a very important thing to do.

Metadata literally means data about data.  For much of the Enterprise Software world, data is controlled by code, not data.  Want some custom fields?  Somebody has to go write some custom code to create and access the fields.  Want to change the look and feel of a page?  Go modify the HTML or AJAX directly.

Having all that custom code is anathema, because it can break, it has to be maintained, its brittle and inflexible, and it is expensive to create.  At Helpstream, we were metadata happy, and proud of it.  You could get on the web site and provision a new workspace in less than a minute–it was completely automated.  Upgrades for all customers were automated.  A tremendous amount of customization was available through configuration of our business rules platform.  Metadata gives your operations automation a potent place to tie in as well.

Open Source Only:  No License Fees!

I know of SaaS businesses that say over half their operating costs are Oracle licenses.  That stuff is expensive.  Not for us.  Helpstream had not a single license fee to pay anywhere.  Java, MySQL, Lucene, and a host of other components were there to do the job.

This mentality extends to using commodity hardware and Linux versus some fancy box and an OS that costs money too.  See for example Salesforce’s switch.

Automate Operations to Death

Whatever your Operations personnel do, let’s hope it is largely automating and not firefighting.  Target key areas of operational flexibility up front.  For us, this was system monitoring, upgrades, new workspace provisioning, and the flexibility to migrate workspaces (our name for a single tenant) to different pods (multi-tenant instances). 

Every time there is a fire to be fought, you have to ask several questions and potentially do more automation:

1.  Did the customer discover the problem and bring it to our attention?  If so, you need more monitoring.  You should always know before your customer does.

2.  Did you know immediately what the problem was, or did you have to do a lot of digging to diagnose?  If you had to do digging, you need to pump up your logging and diagnostics.  BTW, the most common Ops issue is, “Your service is too slow.”  This is painful to diagnose.  It is often an issue with the customer’s own network infrastructure for example.  Make sure to hit this one hard.  You need to know how many milliseconds were needed for each leg of the journey.  We didn’t finish this one, but were actively thinking of implementing capabilities like Google uses to tell with code at the client when a page seems slow.  Our pages all carried a comment that told how long it took at the server side.  By comparing that with a client side measure of time, we would’ve been able to tell whether it was “us” or “them” more easily.

3.  Did you have to perform a manual operation or write code to fix the problem?  If so, you need to automate whatever it was.

This all argues for the skillset needed by your Ops people, BTW.  It also argues to have Ops be a part of Engineering, because you can see how much impact there is on the product’s architecture.

Hit the Highlights of Efficient Architecture

Without going down the rathole of premature optimization, there is a lot of basic stuff that every architecture should have.  Thread pooling.  Good clean multi-threading that isn’t going to deadlock.  Idempotent operations and good use of transactions with rollback in the face of errors.  Idempotency means if the operation fails you can just do it again and everything will be okay.  Smart use of caching, but not too much caching.  How does your client respond to dropped connections?  How many round trips does the client require to do a high traffic page?

We used Java instead of one of the newer slower languages.  Sorry, didn’t mean to be pejorative, and I know this is a religious minefield, but we got value from Java’s innate performance.  PHP or Python are pretty cool, but I’m not sure they are what you want to squeeze every last drop of operations cost out of your system.  The LAMP stack is cheap up front, but SaaS is forever.

Carefully Match Architecture with SLA’s

The Enterprise Software and IT World is obsessed with things like failover.  Can I reach over and unplug this server and automatically failover to another server without the users ever noticing?  That’s the ideal.  But it may be a premature optimization for your particular application.  Donald Knuth says, “97% of the time: premature optimization is the root of all evil.” 

Ask yourself how much is enough?  We settled on 10 minutes with no data loss.  If our system crashed hard and had to be completely restarted, it was good enough if we could do that in less than 10 minutes and no loss of data during that time.  That meant no failover was required, which greatly simplified our architecture. 

To implement this, we ran a second MySQL replicated from the main instance and captured EBS backup snapshots from that second server.  This took the load of snapshotting off the main server and gave us a cheaper alternative to a true full failover.  If the main server died, it could be brought back up again in less than 10 minutes with the EBS volume mounted and away we would go.  The Amazon infrastructures makes this type of architecture easy to build and very successful.  Note that with coarse-grained multi-tenancy, one could even share the backup server across multiple multi-tenant instances.

Don’t Overlook the Tuning!

Tuning is probably the first thing you thought of with respect to cutting costs, right?  Developers love tuning.  It’s so satisfying to make a program run faster or scale better.  That’s probably because it is an abstract measure that doesn’t involve a customer growling about something that’s making them unhappy.

Tuning is important, but it is the last thing we did.  It was almost all MySQL tuning too.  Databases are somewhat the root of all evil in this kind of software, followed closely by networks and the Internet.  We owe a great debt of gratitude to the experts at Percona.  It doesn’t matter how smart you are, if the other guys already know the answer through experience, they win.  Percona has a LOT of experience here, folks.


Long-winded, I know.  Sorry about that, but you have to fit a lot of pieces together to really keep the costs down.  The good news is that a lot of these pieces (metadata-driven architecture, cloud computing, and so on) deliver benefits in all sorts of other ways besides lowering the cost to deliver the service.  Probably the thing I am most proud of about Helpstream was just how much software we delivered with very few developers.  We never had more than 5 while I was there.  Part of the reason for that is our architecture really was a “whole greater than the sum of its parts” sort of thing.  Of course a large part was also that these developers were absolute rock stars too!

Posted in cloud, data center, ec2, enterprise software, platforms, saas, software development | 5 Comments »

Freemiums for SaaS

Posted by Bob Warfield on March 25, 2010

Time for my first Learnings post about my Helpstream Experience.

Freemiums are a fascinating subject.  Whole books have been written about the concept of extracting value from something that’s free.  The FOS (Free Open Source) movement is all about free, and we benefited tremendously from it at Helpstream.  Not one single software license fee was paid in the making of that software. 

Helpstream has been my first experience with a Freemium, and it was a contentious one.  The original CEO at Helpstream put the Freemium in place for a variety of reasons.  First, having worked in pricing for IBM, he wanted to price everywhere along the demand curve so as not to leave a flank exposed at some price point.  Interesting idea and strategy.  Second, he wanted to use it as a forcing function to make sure the software was built in such a way that the cost to deliver the service was extremely low.  Again, interesting.  I’ve written in the past about cost of service being critical to SaaS success.  We ultimately achieved a cost of 5 cents per registered user per year of our service, which is extremely low, so I would say he accomplished his goal on that one too.  Third, I was given to understand that there was a point earlier than my arrival where some thought was given to the possibility of having to make a business off ad revenue. 

The contention came from Sales, and to a lesser extent Marketing.  Sales was not particularly interested in any of the goals the CEO had set forth.  One of the things one learns about Sales (and I came to Helpstream knowing this full well) is that they are carefully selected and trained to be entirely coin operated.  If it doesn’t contribute to their commission they are not interested.  If they decide it is taking away from their commission, they are actively hostile.  In this case, Sales felt that the Freemium was competition: it was taking sales commission out of their pockets.  Hence it became almost impossible to talk about the Freemium without polarizing armed camps, which eventually made it a sacred cow.  This is particularly difficult when the same executive is responsible for Sales and Marketing (more on that, perhaps, in another Learning Post).  The CEO and I could chat about it, but its darned hard without the whole team on board and trying hard.  BTW, this is not that uncommon in Executive Staffs, and it is one of the roles of the CEO to manage the discord lest it become dysfunctional. 

Our Freemium had some other difficulties that would surface whenever we could get past Sales’ desire to just shut it down immediately.  The biggest problem was that it was not attractive to the right kind of customers.  Attracting the right kind of customer and repelling unsuitable prospects is a subject about which I will have more to say in a later post because it is critically important to startups.  Even the negative aspect of repelling unsuitable customers is important and not something that even occurs to most people to try to do.  In this case, our Freemium consisted of full-featured product with an exception–branding was disabled.  You could apply a logo, but you did not have fine grained control to present a portal that reflected your brand.   This turns out to be important for a Customer Service product with the types of companies we were selling to.  They needed that branding capability.   A couple of other factors played in as well.   Customer Service is by definition Customer-Facing.  Very few companies are progressive enough to conduct experiments in Customer Service, and those that are will not do so without a lot of thought and deliberation.  This is not a departmental land-and-expand application.  This is your fundamental Customer Service Experience.  So, prospects would get a free workspace and play with it a bit, but it was sterile and did not give them an ability to see it in the context of their intended use. 

Lastly, that point about being sterile, goes to the issue of content.  Lots of Enterprise Software and Social Software requires content before it becomes clear how it is used.  We had the ability to instantly provision a workspace, but we were not stocking those workspaces with interesting content.  Essentially, prospects were getting into a new house that had not yet had finish carpentry done.  They could see it had a solid foundation (“good bones” as the house people say), but they couldn’t tell if it was going to be a Mediterranean-style villa or a Western Ranch style house, let alone whether they liked the colors and carpet choices.  I had a plan to fix this in the same way builders do.  I wanted to create a “Model Homes” section on our web site where people could prowl model homes that were set up with content and so forth based on their industry.  We would also put selected customer workspaces in as Model Homes given their willingness to present their portals to non-customers.  Alas, we never got the time or budget to make that a reality, but I think it would have helped us out a lot.   I haven’t really seen the Model Home concept done anywhere, but I suspect someone does it.  ServiceNow has a cool fully functional version of their product available for anyone to play with, and this is pretty close, albeit not specifically targeted at industry verticals.  We also did create a Best Practices Community called the HelpExchange that was a much better trial experience than a bare workspace.

The long and the short of it is that we got a ton of Freemium users, but they were mostly not customer prospects.  We were not getting as many Customer Service users as we were Internal Collaboration users.  Helpstream was great for that too, but it wasn’t our market.  In addition, the Freemium was self-selecting customers who were most likely to be willing to pay, well, nothing!  This is a big problem for the Open Source world, and makes me wonder how viable Open Source even is as a business model, much as I appreciate all that they have done.  We had lots of schools, churches, and other non-profits.  We had government organizations, including the US Army, where getting actual budget and project approval is extremely difficult, so the users would simply sign up to a free solution and get on with their work.

Would I recommend a Freemium to other SaaS companies?  Absolutely!

Or at the very least a comprehensive trial opportunity.  We got a lot of value from our Freemium.  It helped us shake down our system.  The free users gave us a tremendous amount of feedback and testing.  It enabled us to show some momentum in terms of numbers of customers.  Interestingly, while we wound up with 200 businesses using the free version and 40 paying customers, the number of seats involved was never large for the Freemium.  Very small businesses used us for Customer Service and larger businesses used us as departmental collaboration hubs.  Lastly, it made our software better.  The things we had to do in terms of making sure it was cheap to deliver the service so the Freemium wouldn’t be too costly, or making sure provisioning could be automated (along with other self-service aspects) were all good things for a SaaS architecture.

What would I change about the Freemium to make it more successful?

I’ve already mentioned the need for Model Homes and more content.  An automated guided tour would also be very helpful with a complex SaaS product.  In the end of the day, I prefer a trial to a Freemium though for a company like Helpstream.  When I took over as CEO of Helpstream, the first thing I did was to limit the Freemium.  I looked at the usage statistics to determine who was deriving real value.  A hospital using the Freemium to deliver an IT Help Desk to hundreds of people was clearly deriving real value.  Based on these statistics, I set limits on the Freemium.   A free workspace could have a total of 50 users, including both administrators and end users.  Any workspace that exceeded 50 users had 30 days of trial before that workspace would be shut down.  Out of 200 free customers, many of them unsuited to becoming paying customers, we actually got about 5 to convert to a paid plan with this change.  2.5% is actually not too bad as a conversion rate, all things considered.  In essence, we had a free product for very small organizations and a 30 day trial for larger organizations.

The last thing I would look at doing is lowering the adoption friction in a variety of ways.  Letting the free customers access the branding and perhaps the single sign on (the two most common professional services engagements for installation) and making that super easy as self-service would be very helpful.  Reducing transaction friction would be helpful too.  Here’s a standard order form, enter you credit card here, and you are done.  Above a certain deal size, nobody will do business that way,  but in the original spirit of pricing along the whole demand curve (a good idea, Tony!), it’s worthwhile to stake out that territory and make it so easy that sales does not even need to be involved.

Posted in saas, strategy, venture | 12 Comments »

My Startup Track Record

Posted by Bob Warfield on March 22, 2010

Success.  Success.  Failure.  Success.  Failure.

That’s it, that’s my story.  It’s been my heartbeat.  I’m a Serial Entrepreneur with a 60% track record, which is comforting, except that I’m coming off my latest failure at Helpstream.  60% is way in excess of what most any VC ever gets.  It’s way better than anyone I know, in fact.  But nothing is ever really very comforting at a time like this. 

What do I mean by “Success” and “Failure” in the first place? 

It’s pretty simple.  For me, a happy return in dollars is a “Success”.  Having no such return is a “Failure”.  One can weasel around, or be difficult about whether money is a good defining characteristic, but in the end I am a capitalist, and I believe the market decides what is Successful and what has Failed.

The Successes involve two acquired startups and one IPO.  Acquired.  Acquired. Failure.  IPO’d.  Failure.  IPO’s are nice to be sure, but I’ve made more money by far off the acquisitions.  That’s a good thing, because in this world we live in today, IPO’s are increasingly hard to come by and acquisitions are the more common exit strategy.  FWIW, the two happy acquisitions were companies I founded.  The IPO I joined in motion, while it was still a startup.  One Failure I founded.  One I joined in motion.  So my track record is better on things I found, for whatever that’s worth.  Probably not statistically significant.

As fun and exciting as the Successes are, its the Failures I take to heart and brood over.   Wasn’t there some way to avoid that Failure?  I’ll be chewing on that bone years later, and I seldom have found a critical change I could have made.  Fine tunings perhaps.  Let’s face it: startups are hard and many will fail.  A fellow executive has a hard time framing what happened at his recent Failure to prospective employers.  He worries about it a lot.  But, he says that for many employers, they look at it as part of the Startup Thing.  Startups Happen.  True Story, that.

What’s next? 

Almost certainly another startup of some kind.  It’s in my blood.  I love startups, though I’ve had a lot of fun at large companies too, particularly the stint I did at Borland back in its heyday as VP of Engineering.  That was a blast. 

I plan to take at least a month off before I start to look in earnest, although I already have calls that I need to take.  I don’t like thinking of my successes as luck (funny, it’s not so hard to put the failures there though!), but the truth is you need a little luck for a great success.  So I can’t afford to be unresponsive lest I let the right deal knock without answering.  Nevertheless, its important to recharge your batteries at a time like this.  Startups proceed at a frantic pace as they must.  It’s part of the joy of a startup, but you have to undertake one in a state of mind appropriate to the pace.  Hence, always recharge the batteries before launching once more unto the breach, dear friends.

Fortunately, the recharge doesn’t take me long.  I get bored easily.  I start talking to people, networking, and pretty soon the Startup Energy is flowing in my veins again.  In the meanwhile, I will have time to be an active blogger once again.  This is a happy synchronicity, because I will have a lot to say.  While it’s fresh, I want to go over my latest learnings from the Helpstream experience.  It’s good therapy for me, and perhaps just a little bit helpful for you, dear reader.  I wanted to pen this initial story for the series on my first work week day of unemployment. 

I am fond of saying you learn a lot more from failure than success.  Call it a consolation prize, but I do learn a lot from the failures, though I also learn from the successes.  Since I am just off a Failure, clearly I have not yet amassed enough learnings to have a perfect picture of how to navigate the treacherous waters a startup sails on to success.   Hence there are new learnings to be discussed.

I’ll walk though it all again in more or less random fashion.  I’m going to write about the signposts that I use to guide my startup decisionmaking and strategy moreso than about the specifics of Helpstream, though I intend to illustrate with examples from Helpstream and the other startups I’ve participated in.  There are definitely some worthwhile new learnings to add, especially in the area of Venture Capital, Mergers and Acquisitions, Product Market Fit, Crossing the Chasm, and Sales and Marketing strategy in general.  Heck there’s even some new learnings on the Technical side, so it’s never too late to teach an Old Dog some new tricks.  Some of the learnings are profoundly new ground, some are refinements of old ideas, and notions made concrete.

I’m not promising any particular schedule for these ramblings, it’s strictly stream of consciousness.  I know when I wake up whether I’m going to pen a missive and what it’ll be about.  By the time I’m out of the shower, I’ve got most of it crafted in my head at which point its just a matter of getting it out via the keyboard.  Please join me for this catharsis.  And by all means, please get in touch to discuss the finer points of Startups.  If we all pool our Learnings, we all Learn.

Postscript:  The Helpstream Learnings Series

Freemiums for SaaS

Minimizing the Cost of SaaS Operations

Three Deadly Sins of a Startup CEO

References and Pricing for SaaS Startups

Posted in strategy, venture | 17 Comments »

Joel Spolsky and Kathy Sierra are Close, But There is More to Blogging

Posted by Bob Warfield on March 20, 2010

Joel Spolsky has succeeded brilliantly with blogging as marketing medium, and he says he only learned why a year ago based on something Kathy Sierra said at the Business of Software Conference:

To really work, Sierra observed, an entrepreneur’s blog has to be about something bigger than his or her company and his or her product.

Tantalizingly close.  Being about something bigger than the self-serving marketing of your product, your company, or even yourself is a key ingredient.   But it’s not enough either.  Spolsky’s examples hint at the greater purpose, in other words, what is this thing that’s bigger than the pedestrian marketing messages so many corporate blogs spout–don’t talk about the camera attachment you’re selling, talk about how to become a better photographer.

There is a phenomenon familiar to astronomers and stargazers called peripheral vision.  Some heavenly bodies are too dim to be seen directly, even with the aid of a telescope.  If you stare at them, they disappear.  But, tantalizingly, if you merely look near them but not at them, you can see them.  This blogging that Spolsky and Sierra speak of, is sort of a peripheral voice.  It is about finding a bigger picture to talk about, but it isn’t just bigger.  Many subjects are related bigger, but not interesting.  This is why I say the message is tantalizingly close, but incomplete.

The missing ingredient is to give something of value.  Your voice, opinions, and writings do not automatically have value, even if you are Joel Spolsky.  You have to convey that value in your writing.  You have to give something of value away for free to your readers.  That is really the entire secret to marketing with the Internet:

You have to give in order to get.

Conventional marketing has a hard time getting its head around that.  They’re entirely focused on what they’re going to get.  At best, they want to place whatever they’re willing to give inside a snare.  Here’s this nice juicy piece of cheese, but as soon as you take it, the trap snaps shut and I will compell you to become my customer!

But what if we leave juicy cheese in the same place day after day, week after week.  What if the availability causes a happy community to spring up?  Isn’t that community even more valuable than the little bit of game that was getting snared before?


Reading Spolsky’s post, he seems equal parts trying to convey that he has mined all the value blogging has to offer and now has no more time for it, and equal parts revealing of another important problem he has to solve:

We have the undisputed No. 1 product among the 5 percent to 10 percent of programmers who regularly read blogs about programming. Meanwhile, we’re almost unknown in every other demographic.

It’s an interesting question.  What are the missing demographics?  He alludes to great products not meant for programmers that are unnoticed because his audience is programmers.  He alludes in the quote above to programmers who don’t read blogs.  Will a cessation of blogging and a switch to other channels bear fruit?  Has the Internet changed the world enough, especially if you want to sell software, that the give-to-get mantra is now a requirement for selling to anyone with even a little bit of the way the web works influencing their thinking?   He says Twitter has a lousy blog, but clearly they understand giving-to-get very very well.

I wish Joel well in his journey to open other channels.  But in the end, he has spent 10 years building a brand.  The issue isn’t the blog and that it is only reaching the subset of programmers reading your blog, Joel.  The issue is the brand.  Marketing is as much about driving people away as it is about bringing people in.  Your brand does that.  It is a signalling mechanism.  Rolls Royce can’t just slap a hybrid engine into their cars and suddenly appeal to the Berkeley Greensfolk.  And those other channels you want to bring to bear may or may not take another 10 years to bear fruit, but the best they can do is convey the brand you’ve already built to new places. 

As for changing that brand, be careful what you wish for, and be careful what you give up.

Posted in Marketing, strategy, Web 2.0 | Leave a Comment »

%d bloggers like this: