When is software done?

This is something I’ve been thinking about recently.

First, let me clarify that when I say software being done, I mean a particular feature. I don’t mean an entire package of software. A standalone application or SaaS software package is never actually done; there’s always new desires and demands from human beings, and all pieces of software must expand until they either send email or build their own messaging inbox because they can’t be bothered to interface with email. The most successful communications protocol in history; but I’m not bitter.

I’d argue that a holistic view of software success actually looks at the user and asks when a certain percentage of them — say, 7% or 15% — are using it. What that exact percentage should be is a matter of art and depends on the feature being built. Not everyone is going to use every feature of every piece of software. You won’t always use every feature of software you write for yourself.

But people are using this feature, and critically, they were able to discover it, and they’re happy that they discovered it, or at least not actively angry about it. Discovery, usage, and happiness. (Look ma, it’s a framework!). If you don’t have all three, you’re in trouble.

What people mean when they say software is “done” depends on where they are in this picture. If you’re a developer focused on a certain set of features, deep in a codebase, whether you’re writing code manually or using some kind of tooling or agents to write code, you might consider the software done when it’s merged to main, or more likely when it’s deployed. That is, when people can interact with it and learn the code the same way jessitron talks about in this beautiful piece. That’s deployment, but it’s only the first step. If you’re a marketing person, you might consider the software or feature done when you’ve launched it: submitted the press release, sent a bunch of emails about it or otherwise tried to engage people and teach them about it. If you’re a business person, you might look for the first deal that was signed because of this software feature, or maybe the first incremental bit of revenue you can point to. If you’re an end user, you might consider a feature done when you use it for the first time. Each of these is really pointing at one leg of the same framework without necessarily covering all three.

So let’s take the “discovery, usage, happiness” framework leg by leg.

Discovery. The cost of creating software has decreased drastically (ahem, AI, ahem). And when the cost of one component of something decreases, what happens to the other pieces? I think you can’t lose track of the ultimate source of value, which is: a user discovers this particular feature, whatever it is, uses it, and is happy about it. Discovery means you have to have users, which is why the go-to-market or distribution side of software is so important. After all if someone doesn’t have your entire software package, they won’t be able to find the cool new feature you just shipped.

Discovery also means your users need to be able to find the new feature of their software. Lots of options for helping them:

• in-app notifications
• email
• a pop-up on a related feature
• targeted communications because you’ve seen a user explore related features
• hopping on the phone with them (if you’re a smaller company)
• a face-to-face conversation and show people what’s new
• release notes

There are a lot of different ways to do it, and the truth is that you aren’t going to be able to do just one of these. Inform folks the way they want to be told; everybody wants to be communicated with in a different manner.

Usage. After discovery comes usage, which means someone actually trying the feature out, at least a few times. At a base level, it needs to work the way they expect it to. No surprises. If it doesn’t, people won’t get past this stage no matter how well you nailed discovery.

But usage isn’t just about whether it works; it’s about whether it’s worth the effort. The friction of using the feature should be calibrated to the perceived value someone will get from using it. Not the value, the perceived value. And not value for you, the software provider, but for the end user.

For example, if you are adding a feature to enable better recommendations, don’t have a 100 question survey. Ask one or two questions.

Happiness. Happiness is a step beyond usage. It’s someone incorporating the feature into their normal workflow. People don’t use software just to use software; they’re using it to accomplish something in their lives, whether that’s communicating with friends, doing part of their job, or just amusing themselves.

Once something becomes part of how they actually get things done, that’s happiness. And that means it needs to not be a constant churn of change.

If you push too much churn on them (constantly pushing out features, changing interfaces, tweaking things, and not letting people turn new features off) you’re going to make them dissatisfied, and they’ll never fully incorporate it into how they work.

Maybe “happy” is too strong a word. Or maybe you just want people to be content, or at least not upset — it depends on the kind of software you’re using.

And it’s worth saying that people hate change. I hate change myself, so some percentage of your users are always going to be grumpy about it. Don’t want to measure happiness just at the moment they encounter the new feature; that’s usage. Some people, early adopters, will be thrilled to be exploring new areas, while others will be pretty pissed off. So you want to gather that data after a certain period of time has passed.

Have I ever worked somewhere that has this kind of maturity around it? No.

Would I like to? Yeah. I think that if you can close the loop on discovery, usage, and happiness, you can build software that people love, and that becomes a sustainable business.

It doesn’t matter how much your competitors churn out software because it’s cheaper to do; you’ll win if you make software that can be discovered, that people use, and that they like.