Business of Software Blog

What do you do if coding is no longer enough?

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.

Subscribe to the RSS feed

A reminder about the Red Gate million dollar challenge

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

Subscribe to the RSS feed

Pesky customers, and one way of handling them

 

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.

Subscribe to the RSS feed

Why there's nothing special about the business of software

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).

Subscribe to the RSS feed