Software < software products < software product businesses

This is a letter to Teenage Me about the art, craft and business of software.

On software programs and software as a medium Link to heading

Software is a wonderful medium to work in. So malleable. So cheap. So fast. At least, at the outset it is, when you begin work on a program. It’s deliciously easy to set fingers to keyboard and flow your ideas into working code. The letters on the screen compile into working software, your creation comes to life, and the feeling of reward is immediate and intense: edit -> build -> run -> it works!

Loop.

Immediate gratification, repeatable endlessly.

Software has its own aesthetics: ugly or beautiful, wasteful or elegant, verbose or concise. Given the time and opportunity, most developers strive for beauty, elegance and brevity.

Software is a close cousin of ordinary human writing; it’s like prose in many ways, but with stricter structural rules to follow. A well-written legal contract has a lot in common with a well-written software program, for example. So does a poem. I think this is why we say we are “writing code”.

There are, of course, caveats. Programming isn’t always an uplifting experience. Software can be cryptic, and brittle. It can be maddening, like a puzzle missing a piece. It can absorb all your attention, to a fault. And worse. But when it works, everything just snaps into place with an oh-so-satisfying click.

So, drawbacks aside, I love making software. It’s good fun, and the craft of software-making gets more enjoyable every day as our tools and methods improve.

Individual software programs are the building blocks of software products. And a single program, a.k.a. piece of code, is a much simpler entity than a software product. Let’s talk about that next.

Software products: joyful bundles of software programs Link to heading

A software product is a coherent, self-contained bundle of software programs that, as a whole, gets one or more “jobs” done for its end users.

Bringing a bunch of individual software programs up to a marketable quality level and then assembling them into a product is Hard. Here’s why:

First, software products must be made ready for the real world. Thus we put a lot of energy into making each individual software component within a product reliable, secure, performant, and so on. We try to eliminate all but the least important defects (bugs). And then we repeat that all over again for the software product as an assembled whole. Products often have to comply with standards, too. And be compatible with at least some other software.¹ We intend software products to be long-lived – months if not years and decades – rather than ephemeral. And so while it’s perfectly normal for programmers to write smaller individual pieces of software that are casual, flimsy or throwaway, software products are almost always treated as serious, robust, durable artifacts.²

Second, software products are hungry. They demand ongoing maintenance in the form of bug fixes, upgrades, and new features. They must be supportable, and supported. They need care and feeding from their developers and operators, resources from their hosting environments, usage and feedback from their end users. Products consume resources, sometimes in a continuous stream of sips and nibbles, and sometimes in big episodic gulps, until they are finally retired.

Third, unlike standalone software programs, software products have durable identity: names, versions, look and feel, branding.³ Defining this identity is a non-trivial task that typically requires a great deal of careful thought and effort to do well. If you scoff, then think about the last time you tried to come up with a good name for something. It can be surprisingly hard.

Lastly, and most importantly, software products are designed to solve real world problems for customers, and this entails talking to and studying customers and creating a feedback loop to be sure the product does the job properly. Lone software programs often don’t have this requirement; the “value proposition” of a lone sofware program may simply be the joy of writing the code, and the “customer” is the developer.

That’s a lot. And you won’t learn it in school; universities and colleges don’t teach you how to make software products. I learned this stuff on the job, first as a co-op student and then as a full-time employee. I had the great fortunate of learning from many talented designers, developers, testers, operators, program managers, product managers and other subject matter experts, all working together to make software products. It’s a magical and wondrous craft, and by the time I was 25 or so I had a decent understanding of it. (Not saying I was great at it, or even good, just that I understood by then what was needed!) But it took me many more years to learn about the businesses I was working in.

On software product businesses Link to heading

In the same way that a single piece (program) of software is a much simpler thing than a software product, software products are much simpler beasts than software product businesses.

By “software product business” I mean a commercial entity that produces, sells, and supports one or more software products. Importantly, this type of business sells one-size-fits-all products, not special snowflake software made bespoke for each new customer.⁴

There are many elements that make software product businesses complex. I’ll touch on just three.

To begin with, while a software product business obviously dwells a great deal on the products it sells, it also has an additional, broader set of concerns. The business must consider willingness to pay, pricing, marketing methods, sales and distribution channels, revenue, costs, operating margins and profit margins. Employees. Payroll. Cash Flow. Partnerships. Regulations. Insurance. Taxes. Licensing and lawsuits. Handling all these concerns skillfully is both fascinating and Hard; in my experience, equally as interesting and difficult as the most challenging aspects of building the underlying software products.

Next, the communication gap between a software product team and the surrounding business can be quite hard to navigate, especially in larger companies. Sometimes the product people don’t understand the business people’s needs. “At our current burn rate we have 90 days of cash left in the bank. That means we have about 30 days left to release this product and start generating revenue, or we will go out of business.” Or, “Hey, I closed the sale! We just have to build this one little feature. We’ll be done in a jiffy.”* Or, “That feature you’re working on may be cool but it is not important (to the business).”

And sometimes the business people don’t understand the software people’s needs. “The product has serious technical debt. We can paper over it for now, but we must fix it soon or all forward progress will grind to a halt.” Or, “The release date doesn’t matter. We absolutely cannot ship with this flaw.” Or, “We can’t safely touch that old code. Nobody on the team really understands it fully.”

In smaller companies these gaps in understanding are typically much narrower, and even nonexistent if the business people ARE the software people.⁵ Regardless of size, though, companies must bridge this gap in order to graduate from creating software products to creating successful software product businesses.

Third, truly great software product businesses have very low marginal costs, approaching zero. A key enabler of this is designing a single version of the software product to serve all customers. The product may have features that enable customization to meet individual customer needs, and in that sense, it can be tailored (configured). But it is absolutely not bespoke: you are not creating a new product version for each new customer. This posture – one product for all our customers – is very valuable, and can be very hard to achieve.

Software product businesses are complicated.

Add it up Link to heading

Here’s the essay title again:

software < software products < software product businesses

Hopefully by now my meaning is clear: in general, creating individual software programs is much less complex, effortful, and potentially impactful than creating software products, which is in turn much less complex, effortful, and potentially impactful than creating software product businesses.

I realize that for the more business-minded readers among us this may seem blindingly obvious. Well, trust me, this concept wasn’t obvious to me in years past, and I know plenty of other people who didn’t understand it either. In particular I think it takes most techies a while to fully comprehend the vast difference between a software product and a business wrapped around that product.

Why write all these words? Link to heading

Because I wish I could give this essay to my teenage self.

I learned early how to code, later how to build software products, and much later how to build software product businesses. It’s been a fascinating journey, often very enjoyable, but also crushingly humbling and painful at times. I can think of at least three separate occasions, for example, when I worked really hard on a software product and ended up having to throw it away because it wasn’t fit to be a business. Probably there are more such, and I have buried the painful memories.

For software nerds, “just write code” is the most natural thing to do. It’s a reflex action… when unsure what to do, just start writing code and you will feel better. Immediate gratification! Don’t worry about customers, or problems, or profit. And for many years that’s exactly what I did.

Now, to be clear, great things can come from “just write code”, and I much prefer to be programming – running in some-direction-any-direction – than sitting still. But days, months, and years can also be wasted if what you were really hoping to achieve with all that typing is to create a killer business. When you next embark on a new coding project, don’t wait too long to ask yourself: am I trying to create a software program, a software product, or a software product business? It’s fine to change your mind from time to time, but just be clear with yourself and your co-workers which goal you’re after at any given moment in time.

Dear Teenage Me: Keep learning how to build software programs. They’re terrific. But carve out a bit of time sooner rather than later to learn how to build software products, and software product businesses. They’re terrific too!