We talk about “software products” and “product teams.” What does this even mean, “product?” It is not the definition I learned in school.
Economics 101: the output of the economy is “goods and services.”
Goods, also called “products,” are physical items that you can buy, take home, and have. Like, if you buy a rug, you take it home and put it on the floor and walk on it and it lasts until you’re tired of how it looks.
Services are different, because they’re actions done by people. Like, you can pay someone to vacuum your rug. Then the rug is clean until you get it dirty again, and then you can pay them to vacuum it again. Every two weeks for the rest of its life.
Products have the potential to be vastly more profitable. The value consumers get from a well-designed object might be a lot higher than its incremental production cost. You ship a product, you get money, you’re done. Whereas: services cost a lot to provide, even at scale, because you have to pay a person to do each one.
Then again, services can be recurring revenue. You buy the rug once, and pay for vacuuming every two weeks. Getting money every two weeks is nicer than once.
Where does software fit into this?
Let’s limit this to consumer software for now. It definitely started out as a product: disks or CD-ROMs in cardboard boxes on the shelves of Office Max.
I could buy Quicken, say, and take it home and put it on my computer and track my finances. It lasts until I’m tired of how it looks… no wait. It lasts until I upgrade my computer and Quicken doesn’t run on the new OS. It lasts until my bank gets a new download format that isn’t compatible. It lasts until I hit a hateful bug.
In software, shipping is not the end. “It works” doesn’t mean it keeps working.
When I buy software, I expect patches that fix bugs, updates that keep it running on my devices, and interoperability that keeps up with the rest of my world. Without that, it is a crappy “product.”
Software companies don’t get to ship it, get money, and be done. A good software product comes with support, patches, updates. Ongoing costs, after delivery.
This is why a subscription model makes sense. Also: making software that keeps running on everyone’s machines is expensive at best, realistically impossible. So run it for them on your machines, and sell access! Now we have Software as a Service (SaaS).
You’d think SaaS would be called a service, like in Economics 101. But no, we call that a product.
Why? I’m not sure. Maybe because the profit model scales like a classical economic “product.” Well-designed software can be sold to millions of people at a very small incremental cost. Bonus: we get recurring revenue from selling it monthly.
When we talk about a software product, we talk about an ongoing level of quality and investment.
This makes it useful to people for years and years, like a well-made rug. Except more so: the software product gets better over time. It keeps up with the world (like my bank’s new export). It keeps up with rising expectations.
success does not come from projects, but rather from continuously working and iterating on an area until we achieve the necessary outcomes.
Marty Cagan
In software we don’t contrast “product” with “service.” We contrast “product” with “project.”
A software project follows the old model, the model of “put it on disks and ship it in a cardboard box.” The project gets to some definition of working, and then stops. The team disbands. It is done. Woe to any person who has to use this software for years and years, as it becomes more threadbare and the floor under it changes shape.
A project team works together for a fixed time, then disbands or moves on to some other project. A product team works together for an unbounded time, continuing to shepherd and improve the software product as customers benefit from it.
The current movement in software from projects to products recognizes that software is not done when it first works.
The world changes, our interfaces change, customer expectations change, our competition strengthens. The software needs continual improvement; it needs a team that sticks with it. This is a product team.
A hard part: the movement from projects to products changes more than software teams. It changes accounting. The cost of development moves from Capital Expenditure (a one-time investment) to Operating Expense (a recurring cost).
In Finance 101, we learned about balance sheets, with numbers in columns, denominated in millions of dollars. The balance sheet describes how much profit a company made and what they did with it. Operating Expense reduces profit, while Capital Expenditure is something they do with profit, an investment that looks attractive to stock purchasers.
The profit model for software is still ridiculously strong, since a few software developers can grow a product that serves millions of customers. But it looks different. Then again, if we sell software as a service, then recurring expense is balanced by recurring revenue, and when the recurring revenue goes up faster than expense — PROFIT!
The stock market is adjusting to this idea, that a software product is a new kind of thing with ongoing expenses and also high profit potential.