As the title says. The deadline is 1st September.

See here for more information.

“I know kung fu.”

In the Matrix, when Neo wants to learn kung-fu all he has to do is upload a fighting module. A few seconds later and he’s sparring with Morpheus in a virtual dojo. Living in a computer simulation and being bred as an energy source for a machine master-race has its disadvantages, but at least you get to learn stuff fast. Here in the real world, much knowledge is gained the hard way – by doing. You can’t just upload it. Or store it, index it or e-mail it around.

This is one of the factors behind what Jeff Pfeffer and Bob Sutton call ‘the knowing-doing gap’. In their book of the same name (‘The Knowing-Doing Gap’, available new for under $25 from Amazon), Pfeffer and Sutton examine why companies don’t do what they know they should. The first problem is language. ‘Knowledge’ is a noun, so we treat knowledge as a concrete object we can manipulate, like steel or books. In reality, it’s a process; the process of riding a bike, speaking French or running a company. Hence companies don’t truly know what they claim they do. They might have their mission statements written down on small, laminated cards; and they might say – and even believe – that people are their most valuable assets, but this isn’t true knowledge, and won’t become so until they act.

Pfeffer and Sutton give plenty more reasons too. An emphasis on talk, rather than action, for example. It’s easier to judge people on what they say than what they actually do, and that’s often how we hire, reward and promote. The guy with the quick put-downs, rapid-fire banter and sarcastic comments is perceived as smarter than the quiet one in the corner who bothers nobody, knuckles down and gets stuff done.

The weight placed on talking means that planning, documenting and presenting are considered substitutes for concrete action. They’re certainly easier. Action is difficult, and can go wrong. That’s when another factor comes into play – fear. If people use their initiative, or challenge an assumption, then they often fear they will lose their jobs or the respect of their peers or their boss. Unfortunately, high-profile, charismatic asshole CEOs (Pfeffer and Sutton use the example of ‘chainsaw Al’ Dunlap, but there are plenty more) propagate the myth that fear is a great way to motivate people.

If action is harder than talking, then mindless action is harder than thoughtful action. When organisations hit a problem, rather than think it through afresh they tend to follow the path laid down before, often by people long-gone and in circumstances lost in history. Processes fossilize and are never challenged. Sacred cows get fat when they should be slaughtered, just because “that’s how we do things round here”.

Yet another cause for the gap is that companies send the wrong signals. They might say – and the managers might know – that they should hire great people and spend time developing and keeping them, but they measure short-term financial performance. What are managers expected to do? Free up a good sales person so she can work on a cross-divisional project that will benefit her – and the company – in the long-term, or hit the numbers? By measuring – for example – quarterly revenues, companies signal that they expect the latter, even though the former is what they really want. No wonder it doesn’t get done.

Finally, internal competition, whether it’s bonuses determined by forced-ranking or having an employee of the month, is often a zero sum game that benefits some individuals but that harms entire organisations. In such competitions, there are two ways to succeed. The hard way is to out-perform your coworkers. The easy way is to sabotage them, or belittle their achievements. It’s no surprise that many people settle for the easy option.

This is a fantastic book. Like most of Pfeffer and Sutton’s work, and as you’d expect from two Stanford professors, it’s based on solid research. Case studies are used to illustrate theories and bring them to life, rather than to ‘prove’ them as many business books do. As well as explaining why the knowing-doing gap exists, the book gives ideas on how to fix them. Is your organisation paralysed by internal fighting? Then find an external enemy to focus on – that’s what Apple did with IBM when they launched the first Macintosh in 1984. Is your company trapped by its history? Examine, make explicit and challenge the assumptions that lie behind its sclerotic procedures. Are your people afraid to make mistakes? Make it explicit – with your deeds and not just your words – that there is a soft landing available for those who try and fail.

The beauty of this book – like other works of Pfeffer and Sutton – is that much of it seems like common sense once you’ve read it. Pfeffer and Sutton have a knack of articulating ideas that you feel you already half know, but that are just – but only just – out of your grasp. As you read, you can sense them coming into focus, crystallizing out of the fog of your mind. Of course concentrating purely on short-term financial success can kill a company’s culture. Of course you should commit to metrics that reflect, and don’t contradict, your underlying philosophies. Of course pitting colleagues against each other is going to backfire, and of course the absurd idea that this could ever work is based on sloppy sporting analogies. But it’s only once Pfeffer and Sutton have made these points – and many others – lucid that they become obvious.

This is an excellent book, but as Pfeffer and Sutton acknowledge explicitly throughout, it contains one flaw. A text whose thesis is that knowledge can only be earned through action, and then hopes to teach it through words, is bound to have only partial success. Read this book – and if you’re running, or working in, any organisation larger than a handful of people then you should – and you will only have taken the first step to learning about the knowing-doing gap and how to fix it. The next step?

Action.

Enjoyed this post? Then follow me on Twitter (I’m @neildavidson)

In one corner of Red Gate, next to the giant mural of the coloured pencils and about 20 feet from where I sit, you’ll find a curious bunch of people:

Curious? Why curious?

Martin and Conrad are working on a start-up called go-test.it (Martin’s also starting his PhD in the Cambridge University computer labs in a few weeks’ time – topic of ‘analysing the social web’). Peter, Lee and Jamie are working on Broadersheet.com. They want to change the way you get your daily news. Jamie is also working on his own start-up (Binary Cake), and is running the Cambridge Geek Day later on this year. Sam, Rahul and Stew were working on mo.jo. Unfortunately that didn’t work out so now they’re figuring out what to do next. Mat and Amir are working on webticketing.net. Mat is past the start-up stage: he’s also the founder of mixcloud.com (soon to become the youtube of radio) and wakari, and his Facebook apps (including the ones for Rambo and Quantum of Solace) have been used by tens of millions of people.

Martin, Conrad, Peter, Lee, Jamie, Sam, Rahul, Stew and Mat might work at Red Gate, but they don’t work for Red Gate. We’ve accidentally built ourselves a start-up incubator, and it’s going pretty well. The Accidentals (as we’re calling them) get free food (from our awesome canteen, the SQL Servery), a free desk and the chance to mix with other start-ups and people here. We get the benefit of having even more smart, energetic people we can beat at foosball. It’s a great people cocktail: take smart people from us and them, add free food, internet access, and shake.

The next step is to take what we’ve learned so far, mix in some brazenly stolen ideas, and formalise our accidental incubator into something we’re calling Springboard.

Here’s how it’s going to work. If you’re a UK or European start-up and want to spend three months in Cambridge, UK turning your idea into a product then go to http://springboard.red-gate.com. If your application is successful, we’ll provide:

• A three-month program with weekly talks over pizza and beer with the likes of Joel Spolsky, Ryan Carson and Dharmesh Shah. We’ll also hold half-day seminars with world experts on topics such as usability, software sales and product management.
• A free place to live (if you want it) as well as some cash to keep you going.
• A place to work, full of smart people, free food and fast Internet access
• Advice

In return, here’s what you have to do:

• Be good

That’s it. No strings, no legal work, no giving us stock. No seat on the board, no paperwork. None.

Here are some questions you might have:

Why are you doing this? What’s in it for you?

We think that getting to know smart people doing interesting things will, in the long term, be good for Red Gate. In the future, we might end up licensing your technology, investing in your company or maybe even buying it. Or maybe we won’t. Ultimately, all deals come down to relationships. So we want to build them.

Plus, it just feels like a good thing to do. We don’t know what they’ll be, but we think interesting things will happen

Why won’t you take a stake in my start-up?

Frankly, we don’t need the hassle. Introduce lawyers and things get complicated. People get hung up on valuations, deal structures. The paperwork increases. We have to think about incorporating companies, or restructuring them. We don’t need that. If Red Gate succeeds it’s not going to be because we take 10% stakes in start-ups. It might, however, be because we manage to build long-term, meaningful relationships with people creating the products of the future.

What’s the ideal start-up profile for you?

Ideally, two or three people working on business-to-business software. We’ll give priority to start-ups working in markets adjacent to Red Gate’s since that’s where we can be the most useful Take a look at the Red Gate website if you want to find out more about what we do.

We’re looking for people who can ask us great questions and who are interested in learning. People with something to contribute.

Where can I find out more?

Visit http://springboard.red-gate.com to find out more about the program and to send in your application. The deadline for applications is 1pm on Friday 28th August so it’s not for away.

You can also stay up to date with Springboard updates by following @springboardnews on Twitter. I’ll be posting updates too (I’m @neildavidson), as will @amirmc (he’s doing all the hard work – thank you Amir).

Back in 1999, after quitting a job I hated that involved working on products that sucked and with and for (with some exceptions) people I didn't respect, I found myself in the small life boat that was Red Gate, with Simon as co-navigator, a small contracting revenue as a paddle and no hat.

Bob Walsh's slightly mistitled "The Web Startup Guide" is the chart we never had. And it's a damn fine chart, with land, rocks, reefs, currents, winds and pirates clearly marked. Why mistitled? Because it’s suitable for all product-based startups, not just those on the web.

This book, wisely and following its own advice, is targeted very specifically. If you're a software developer, are thinking about setting up (or have just set up) a product-based start-up, and are prepared to work – damn hard – at something you love doing then this book is for you. Equally importantly, if you're more than a few months into your start-up, or if this is your second start-up, or if you aren't a geek, or if you want to set up a consulting business, or if you want to get rich quick, then this book isn't for you.

It is split into ten chapters. The first couple of chapters explore the different types of startups, talk about how to choose a problem to solve and provide a handy checklist for your startup idea. Too often, startups bite off too much they can chew, or not enough worth chewing. Follow the checklist and you'll avoid these, and other, errors. Equally important is the list of ten startup antipatterns ('the me-too! startup' and the 'outsourced startup' to name just two).

Chapter three discusses possible platforms and works through their pros and cons. Should you create a standalone online application, or base it on the Amazon or Google platform? Or use a higher level platform such as salesforce.com? Or maybe a Facebook app would be more suitable? This chapter will help you decide.

Chapter 4 is about the tools and groups you might find useful. As a developer, you'll know some of this already (you use source control, right?), but will learn something new too, whether it's about site analytics, user feedback sites or testing tools. Starting up a business can be lonely, and the online forums and physical meet-ups covered here will prove useful.

Chapter 5 covers main funding options – friends, angels, VCs and incubators (but ignores other options such as government grants, bank loans and joint ventures). It is agnostic about what sort of financing you should get, but, as an earlier chapter pointed out, if you are reading this book you are unlikely to seek, find, or even need VC funding. The assumption that startups must follow the Silicon Valley approach of seed, series A then series B funding is rightly challenged here. This chapter also includes a brief section on payment processing.

Chapter 6 is about social media and the tools you should be using to track what people are saying about your product online, the role of your startup's blog, Twitter, press releases and their more modern equivalents.

Chapter 7 covers the basics of creating a web site that works. Follow the guidelines here – hook people, be credible and have a clear call to action – and you can't go far wrong.

Chapter 8 takes a detour to explain David Allen's Getting Things Done program and its five core principles. If you struggle with time management then you'll benefit from this.

Chapter 9 contains interviews from 'six wise people', and chapter 10 wraps everything up with some more good advice and a final, quick tub thump.

On the whole, this book is outstanding. There is a lot of information here, but its fast-paced, colloquial writing style make it digestible. What's more, the book is well thought-out, balanced, well structured and accurate. It's an excellent combination of fact, anecdote, theory, analysis and practical advice. The interviews alone (Joel Spolsky, Dharmesh Shah, Eric Sink, David Allen and Guy Kawasaki are among the fifty in-depth, thought-provoking interviews in the book) make it worth reading.

There are, however, a handful of cavills.

Firstly, the interviews are included verbatim. It would have been better to edit them – clarity is more important than word-for-word accuracy.

Secondly, the book gets a bit starry eyed about social media. Although traditional print, TV and radio-based advertising might be dying, social media is just one – not the only – tool left in the modern marketer's toolbelt. Furthermore, it's not true that every company must build a community around its product to succeed. Logistically, it's not possible. I happily use hundreds, if not thousands, of products, yet can only – almost by definition – belong to a handful of true communities. When I fly with my favourite airline, or surf with my favourite browser or buy my favourite sausages I do so because of the awesomeness of the product and the marketing, not because I feel a deep need to engage with the Virgin / Firefox / Musks Sausages community.

Thirdly, it's clearly impossible to include absolutely everything relevant to a start-up in a single book, but it's a shame that Bob chose not to talk about sales and talks only minimally about marketing. Finding people who like your product and persuading them to actually buy it is the single biggest issue that your startup, bogged down in the technology, will forget about. On the other hand, there are plenty of other resources that cover that (Jay Conrad Levinson's Guerilla Marketing, Seth Godin's Permission Marketing, Joe Sugarman's Adweek Copywriting Handbook and Jeff Cox's Selling the Wheel are readable starting points).

But these are minor niggles. Overall, this is an excellent, must-have primer for any geek wanting to set up a product-based business. Buy it.

Bob Walsh's "The Web Startup Success Guide" is available on Amazon for a bit under $20.

Enjoyed this post? Follow me on Twitter (I'm @neildavidson)

We’ve got a bunch of great speakers lined up for this year’s conference (Joel Spolsky, Geoffrey Moore, Paul Graham, Ryan Carson and Kathy Sierra, just to name a handful – the full list is here).

There could be one more name on that list. Yours.

We’re holding a pecha kucha competition. Interested? Send me an e-mail to explain why you should speak (see here for hints). In a few weeks’ time Joel and I will pick a handful of finalists. They’ll each get a free conference pass, and the chance to present 20 slides, 20 seconds each, at BoS 2009 in San Francisco in November.

Want to find out more details, and see the winning entry from last year? Go here.

Liked this post? Follow me on twitter (I’m @neildavidson)

The hardest part of learning something – whether it's quantum
electrodynamics, a foreign language or sketching – is getting past the
stage of total freaking hopelessness.

Read more on my other blog:

http://blog.neildavidson.com/2009/07/the-chasm-of-total-freaking-hopelessness.html

When somebody downloads software from our web site we follow up a few days later with an e-mail asking how their trial went. Sometimes people write back. Here's a reply that made me smile.

From: ***** [mailto:******@*****.com]
Sent: 17 July 2009 19:03
To: Red Gate
Subject: RE: Red Gate Customer follow up

I did not, in fact, enjoy my trial.  Nor did I enjoy the fact that my attorney slept through half of it.  And the only answer I got was to the question "Where will Adam be spending the next five to ten years?"

I was set up.  I had no idea she was 13.  She looked 15.

Now I have to register as a sex offender in every state, and they won't let me entertain at kids' birthday parties with my "Pockets the Clown" character's "Guess What's In My Pocket?" routine.

Oh, wait–

You mean the software, right?

Sorry, I thought you meant–

Anyway…

Yes, the software was wonderful.  Stupendous, in fact.  Truthfully, in a word, it was glorious.

*****

Enjoyed this post? Follow me on Twitter (I'm @neildavidson)

I've set up a second blog where I'll be writing about topics other than the business of software. I've already put up a couple of posts. Here's the link:

http://blog.neildavidson.com

In any sale, you spend a lot of your time listening. You find out what your customer’s problems are, explain how your product fixes them and help him through his evaluation. But there comes a point when you need to ask for something. It might be money, or a favour: for him to talk to his boss, or to kick off an approval process.

When’s the best time to do this? It’s when his goodwill is at its peak – when he feels warm towards you and your product. When he wants to help you, in other words. But when exactly is that? It depends on your product. Here are some examples.

If you’re selling a product like Word 2007, then the time to ask for something is after the ‘hey, a shiny new toy’ phase, and before the ‘dang, why did they change that?’ phase. If you miss it, then you must wait until goodwill returns to neutral. Since the first stage might be extremely short and hard to hit, waiting as long as possible might be the least risky approach:

[Click on this, or any, image to see a larger version]

If you’re selling a product that people hate and buy because they need it and not because they want it (Norton Antivirus, say), then the goodwill curve is different. You should ask very fast, before the dip, or very late, long after it:

The goodwill curve of most web 2.0 apps mean you need to act fast, before it returns to boredom. iPhone apps are like this too (in fact, the curve peaks so fast you get to pay before the curve even starts and the goodwill has been created entirely by anticipation).

One reason that Application Lifecycle Management tools (and other shelfware) are a hard sell is because they generate very little goodwill, and it’s hard to know when that goodwill will happen. You need an aggressive sales force to shift stuff like this:

The goodwill curve of some software shows an initial kick (the shiny new tool phase), then a dip (the dang this is hard phase), followed by a prolonged rise as the user understands the benefits of the tool. Development tools and databases are like this:

Here’s the goodwill curve of some software we sell at Red Gate. People try it, and they like it. Then they don’t use it for a while, but some of the goodwill sticks. It peaks again the next few times they use it, and then slowly deteriorates into familiarity. The best time to act? At the first peak.

Finally, this doesn’t just apply to selling software. Here’s what – I hope – your goodwill graph from this blog post looks like:

I hope I’ve generated enough goodwill to ask you a favour and get you to act. If you enjoyed this post, then please follow me on Twitter (I’m @neildavidson)

In a post last week, Seth Godin explained a problem with giving people feedback about their work. In essence, what happens is this. You say ‘I don’t like your logo / artwork / project plan*’, but they hear ‘I suck’ since the work people do is so tied into who they are.

There is a neat way round this though. It’s a trick I learnt from Bill Buxton’s excellent book about sketching, but it applies to much more than just product design.

Rather than asking for a single outcome (‘Tell me how you’re going to market X’), ask for options (‘Give me three serious ways of marketing X’**).

At this point, the person who’s done the work has no motivation to defend their sole proposal beyond all reason. The conversation stops being an argument of “I’m right / you’re wrong” and, instead, becomes a de-personalised deliberation of “here’s a bunch of different ideas; let’s discuss, together, the pros and cons of each one.”

It works, really. Try it.

Enjoyed this post? Follow me on twitter (I’m @neildavidson).

*Of course, you try to be constructive about this, but the message is the same

** Note that the ways need to be serious – not two obviously bad ideas and one good one that they guide you towards

Running a software business is like crossing a river by feeling for the stones. You take one pace, and then a second, and then you search around with your toes for the next stone. You lean on it gently, testing its smoothness and seeing if it wobbles. It it’s a good stone, you slowly shift your weight across and then seek the next step. If it isn’t, you search elsewhere.

You always have your eye on the far bank of the river, but your path zigs and zags, you hit dead ends and you back track, but eventually – hopefully – you make it across.

If this metaphor holds – and I think it does – then what’s the point of a business plan? First of all, here’s one thing a business plan does not do:

A business plan does not give you a precise set of instructions for how to cross the river. It does not tell you where each stone lies, and how to move from one to the next. It does not give you a mechanism for tracking your actual progress against your plan.

Instead, the point of a business plan is to answer a handful of fundamentally important questions:

Can the river theoretically be crossed? How fast does it seem to be flowing and how wide does it look? Would even tempting a crossing just be a dumb-ass thing to do?

Is it worth crossing? What’s on the other side? Do you really want to get there?

Where are the crocodiles? If you slip, will your feet get wet, or eaten?

Are you crossing it from the correct point? Or should you move a few hundred yards downstream? Maybe somebody’s already built a bridge there.

Where is the first stepping stone? And can you reach it, and will it bear your weight?

Of course, all these are essentially calls of judgement. Do your best to answer them, then reach out your foot, open your eyes and make that first step.

Enjoyed this post? Follow me on Twitter (I’m @neildavidson)

Last week, Wil Harris spoke eloquently and convincingly about how ChannelFlip launched. Off the shelf software, string, sticky tape, some CSS, plenty of tea and a spare afternoon* was all it took to create and get this top-notch video magazine off the ground.

That anybody can launch a successful web site or business is a common message. Just release early and often, and be embarrassed by version one, and you’ll surely succeed. But I find it hard to reconcile this with my experience that writing software is hard, dirty and time-consuming. Our Exchange archiving tool took an awesome team of fine people well over a year to build. How come?

There are a number of reasons – ChannelFlip launched into a market with few competitors; if they screwed up they had no existing customers to disappoint or brand to stain; what they were doing wasn’t technically difficult. I doubt these are accidental though – they’re the results of extremely smart choices that Wil and his team made.

But I think these reasons miss the point. ChannelFlip succeeds not because of the technology, but because of the videos. What distinguishes ChannelFlip from competitors current and future is content, not software. And like most companies, they have constraints. Every hour and dollar spent creating video is an hour and dollar less spent on technology. But – for now – the benefits of spending on content outweigh the costs of scrimping on technology.

If you think you’re in the business of software, here are some questions worth asking about your company or product:

• Of all the things you do, what really matters? What will delight your customers? What will make you damn hard to compete against?
• Of all the things you do, what doesn’t matter?
• Where are you focussing?
• Are you any good at what matters?

Maybe the answer to the first question is software – its quality, technical excellence or performance. But maybe it’s something else.

Enjoyed this post? Comment below, or carry on the conversation on Twitter (I’m @neildavidson)

* OK, so I’m exaggerating a bit

The first computer I ever programmed was my uncle’s Sharp PC-1211. Keen for me to hone my skills on Forth, away from what he considered the mind-softening influence of BASIC, he soon gave me a Jupiter Ace, the first computer I ever owned. It was 1982 and I was ten years old.

These two computers uncovered an itch. It took over twenty years – programming the Acorn Electron, BBC Micro, Acorn Archimedes and then, reluctantly at first, the Wintel platform – for me to finish scratching that itch. I still code now and then, but I no longer feel the same compulsion that I once did.

By the time my urge had dwindled I’d found a new obsession – Red Gate – to fill the void. But I sometimes ask myself what I would have done had I not co-founded Red Gate, and what my advice would be to other people who find themselves faced with the same realization that coding is longer enough.

Obvious, but – for me – wrong, choices would be project manager (I’m just not organised or disciplined enough), technical architect (flow charts and diagrams aren’t my thing) or technical lead (not a big enough jump away from the coding).

The unobvious – but correct – choice would have been product manager. Why unobvious? Because it’s a role that’s often misunderstood. Why correct? Read on.

Product managers help decide what products get built. They don’t necessarily generate the initial idea, and they don’t make the final call, but it’s their job to flesh out ideas and turn them into proposals so solid they can withstand any sticks and stones others can throw. Not only must they make sure the product solves a pain that people really have, but they need to work with developers to make sure their proposals can be – and do get – built, with marketeers to make sure that customers can be found and with sales people to make sure those customers will buy it.

Being a product manager is a bit like running your own business, but with much of the work that is overly familiar (actually building the product), frustrating (project management) and unpleasant (firing people) removed. If you do your job well, you can easily connect what you put in (defining the product) to the end result (happy customers), and that makes it a satisfying role*.

What can you do if you’re a top notch software developer but your passion for code is starting to fade? If you’re looking for the next step in your career, and if you don’t want to manage people or projects?

The first step is to learn more about product management and understand if it’s right for you. Here are three things you can do:

• Look at the Pragmatic Marketing web site
• Subscribe to one or two, or even three blogs
• Immerse yourself in the product management twitter stream (#prodmgmt).

The second step is to do it. If your organisation doesn’t have product managers, then it needs one. Become that person. If your organisation does have product managers, then talk with them and get involved.

Have you considered product management as a career? What are the pros and cons of this particular path? Post here, or carry on the conversation on Twitter (I’m @neildavidson, or tag with #prodmgmt).

Red Gate are hiring product managers. Check out our jobs page.

###

*The more Machiavellian of you will spot the flip side: if you do your job badly, there’s always some other factor to blame too, whether it’s changing market conditions, a recalcitrant development team or just pure bad luck.

If you’ve got a micro ISV or software product that you want to sell then we’ve got a million dollars to spend. The deadline for applications is on May 31st. Read more at the original post:

http://blog.businessofsoftware.org/2009/04/the-red-gate-million-dollar-challenge.html

Employee: “Boss, this gentleman’s got a Word document he’d like to print.”

Boss: “Damn him. Microsoft? Microsoft?! What sort of person uses Microsoft software? Why doesn’t he use a Mac? Out! Out! Tell him to get out!”

Employee: “But he’s the tenth person today who’s asked for that. And we are a print shop.”

Boss: “Yes, and I’m sick of telling these people to sod off. I bet he brought his document on a floppy disk too. Pah! A luddite as well a philistine.”

Employee: “Maybe we should stop saying no? Printing Word documents might even be a money-spinner. Enough people seem to want it.”

Boss: “I’ve got a better idea. I’ll put a big sign on my window to keep scum like this out of my shop. I’ve got principles, you know.”

Employee: ”But aren’t you worried that you might scare off genuine, Mac-using, pen-drive-toting customers too?”

Boss: “The cowards, you mean? Why would we want to serve cowards? They’re as bad as philistines and luddites.”

Employee: “Yes, boss. How big do you want that sign?”

You wouldn’t do this, right? Or would you? Post here, or carry on the conversation on Twitter (I’m @neildavidson). I’ll give $20 of Amazon vouchers to the best comment or tweet.

Dharmesh builds on his 2008 talk and tells us how to build better software businesses.

http://businessofsoftware.wistia.com/medias/3cjc7fu2kc?embedType=async&videoFoam=true&videoWidth=640

Software businesses should be infinitely scalable, right? You've done the hard work. You've built your product, your money making machine. All that's left is to turn its frictionless handle and churn out uncountable quantities of dollar bills. After all, the cost of shipping your creation's sweat-filled bits and bytes to your next customer, and the customer after that, is zero.

But that's not what happens in real life. Take a look at this graph of revenue per employee*, generated from the 2008 Software 500 data:

The median annual revenue per employee is around $160,000. Almost all (90%) of software businesses generate under $300,000 / employee. By comparison, General Motors has revenue of $600,000 per employee; Walmart $200,000; Intel $450,000; Exxon $5,000,000. It turns out that shipping electrons is no easier than building cars, selling cereal, building chips or drilling for oil. There's nothing special about software.

How come?

In 1980, Theodore Levitt – Harvard Business School superstar professor – wrote that there is no such thing as a commodity (or more accurately, there need not be such a thing as a commodity). In 1986, Bill Davidow – erstwhile product crusader for Intel's 8080 and 8086, now venture capitalist – expanded this theme beyond commodities and wrote about the concept of 'device' vs 'product'. In Davidow's terminology, a device is the good that, at first glance, you sell. It's the coffee beans, the silicon chips or the bits and bytes of your software. But the product is what you really sell:

• Trivially, bits and bytes
• Reassurance that you won't rip off your customers and that they're doing the right thing ('nobody ever got fired for buying IBM')
• Reassurance that your software will work as advertised, and that you will be there for customers if they get stuck (Rackspace's fanatical support)
• Reassurance that there is a roadmap, that you will continue fixing bugs, refining the product and releasing new versions (Intel's chipset)
• A statement about your customers (anything from Apple)
• The chance to belong (ditto)

Of these, only the first is scalable and easy to supply. The rest require people to deal with customers, communicate with the market, investigate new opportunities, build brands, grow communities, write documentation, create a company culture and so on. Those are the activities required to decommodify the bits and bytes. They're not cheap and they don't scale.

But if you want to grow, they're the most important things you need to do**.

I'd like to hear what you think. Post your comments here, or carry on the conversation on Twitter (I'm @neildavidson).

(* Yes, I know that revenue per employee isn't as important as profit, but they're the numbers I've got. Also, these numbers are from the Software 500 so may not be truly representative. But they illustrate my point that software businesses don't, on the whole, scale).

(** Assuming you've done the hard – and it is extremely hard – work of building the bits and bytes already).

Professor Noam Wasserman at Business of Software 2008 introducing the concept of, ‘Rich’ or ‘King’.

Are you a micro ISV or do you have a software product you want to sell? We’re setting aside a million dollars to buy the right desktop and web apps. Here’s why, and what you have to do if you want to sell.

In November 2006, Red Gate purchased SQLServerCentral. In the two and half years since then, we’ve invested several hundred thousand dollars in the site, quadrupled its traffic and continued, with Steve Jones, the great work that Steve and the other original founders – Andy Warren and Brian Knight – started. Everybody – Red Gate, SQLServerCentral users current and future, and the original founders – was a winner.

Over the past decade we’ve purchased a number of technologies from third parties and brought them into the Red Gate fold: SQL Server Central, Lutz Roeder’s Reflector, PromptSQL (now SQL Prompt), pInvoke.net and Mini SQL Backup (now SQL Backup). In all cases, we’ve tried to do the same thing: introduce the products to a wider audience, and help them fulfil their potential beyond the means or ambition of their original creators.

We’d like to do this some more, and now seems like a good time. So we’re going to run a competition.

We’re setting aside a million dollars to purchase third party technologies. We might buy a single thing for a million dollars, or ten for a hundred thousand, or any other variation. We might decide to spend more, or less, but a million dollars is our target.

Interested? Here’s what we’re looking for:

• You’ve got to have a product. We’re not interested in prototypes. You must have customers. Happy customers, who – ideally – are happy to give you money for what you’ve built.
• If you’re giving away, not selling, your product then we’re looking for high numbers (10,000+) of users.
• It’s got to be software aimed at software developers or sysadmins. We specialise in Microsoft platforms, but will consider others too.
• The product might be a desktop app or a web-based app. We don’t mind.
• if you’re selling your product then it must have at least a 10% conversion rate. In other words, if ten people download it, or trial it, then, on average, one person should buy it. For us, this is a sign that you’ve got a product that works. We don’t care how many customers you’ve got – the fewer the better, in fact. It’s the ratio of trials to purchases that counts. If you’re not charging for it then we’ll look for a sign that a significant proportion of your users are actually using it regularly.
• Now is a good time for you to sell. Maybe you’re struggling with marketing your product, or maybe you’re worried about the recession we’re in. Or maybe you just need the cash, or are bored.

If you’re interested, here’s what you have to do:

• Send me an e-mail at neil.davidson@red-gate.com explaining what your product is and why it fits what we’re looking for.

The closing dates for entries is May 31st 2009.

Here are some questions you might have:

Will Red Gate invest in my company?

No. We’re interested either in buying your company, or buying the product you’ve built. We won’t take a stake in your business.

Why should I sell?

You might have a number of reasons. The emotional ones might involve fear, boredom and excitement. Maybe you’ve taken the product as far as you can, or want, to and would like somebody else to continue to make it succeed.

Rationally, if your product is worth more to somebody else than to you, then it’s economically sensible to sell. Say you’re making $10,000 a month profit with your product. That’s a decent salary. It means that, over your product’s lifetime, it might generate you $300,000 – $400,000 profit, but with a high risk (since competitive products might emerge, you might fail, and so on). If somebody offers you $400,001 with no risk, tomorrow, then you should sell.

Why should I sell to Red Gate?

We’ve got a track record of buying products and, frankly, not screwing up.

Who is Red Gate?

Here’s Red Gate’s web site

What’s the process?

Send me an e-mail at neil.davidson@red-gate.com explaining what your product is and why it fits what we’re looking for. The closing date for entries is May 31st 2009. We’ll get back to you shortly after, either to let you know we’re not interested or to ask for more information. At some point, we’ll meet up with you, make a yes or no decision, and sort out the details. It will probably take a month or two to go through the process.

Will you sign an NDA?

Not at this stage. If we decide to take things further, and start asking for sensitive information, then we might do.

Will I be able to carry on working on my product?

Maybe, maybe not. It depends a lot on you – why you’re selling, and what you want to do long term. Sometimes we’ve bought technologies and people have carried on working on them, but sometimes they prefer not to.

Why is Red Gate doing this?

We’re always looking for new ideas. We get e-mailed them occasionally, and stumble across them sometimes, but we figured it’s better to be systematic. If buying technologies is a good thing to do, then let’s do it well.

Liked this post? Follow me on Twitter.