During my first years as a software developer, I was incredibly lucky to be part of a team devoted entirely to developing a product. We even had people whose sole job was writing tests (which was a real luxury). That was a long time ago, and although we used technologies that are now obsolete or less widely used (Visual C++, ActiveX, COM, DCOM, and so on), the dynamics of creating a software product haven’t changed at all—even though I’ve since embraced agile development as the best way to build software.
For the last two years, to give a recent example, I’ve been entirely focused on leading a development team building a very specific software product for companies in the electricity sector. They were two very demanding years in which we wrote a great deal of code, successfully released around four commercial versions of the product (with established clients), and always kept in mind the need to refactor, work hard to improve and expand our tests, write proper deployment documentation, and maintain effective configuration management. Nothing is perfect, but in my opinion, the result suggests we did a reasonably good job.
Writing something that works is relatively easy; delivering a very specific project for one client takes some additional skills; building a similar but larger project with a team of several people adds another level of difficulty. But building a software product that’s suitable not for one client but for hundreds of different clients is an entirely different level, requiring a dynamic very different from that of working on a one-off project.
There are many technical and management differences between the two scenarios, and they’re not always clearly distinguished.
So what is the difference?
The dynamics are so different that sometimes people try to develop a product while also facing the pressure of delivering projects using that same product—with the same team doing everything. I’ve seen it, I’ve lived it, and it’s an absolute disaster.
Although every product and every project has its own particularities, in my opinion it’s much easier to deliver a project for a client who explains as clearly as possible what they need. Turning the needs of a group of clients into a product is another matter entirely: that’s what software product development is.
Very briefly, a project involves:
- Direct dealings with a client, who may be more or less difficult to work with (changing specifications, pressure on delivery dates, and so on).
- Clearly bounded functionality to implement (yes, I know—at least it should be).
- Configuration management—that is, defining workflows, managing development versions and the final production version, and so on—which is relatively simpler. I don’t mean it’s trivial, just that it’s simpler than configuration management for a product.
- Managing the team with a focus on delivering the project to the client by set dates.
- Client meetings that take up a lot of time, especially if you’re making early deliveries for evaluation and correction.
- No need for the development team or its lead to understand every detail of the world the client operates in or of their business.
- No need to make parts of the system flexible and adaptable to the preferences and different requirements of potential clients, since there’s only one.
- As for maintenance, we might get away with a solution that’s not the easiest to maintain (since there will only be one client), although ideally it should be extremely easy to maintain, without accumulating technical debt that later costs us time spent supporting the client, whether or not they pay for that maintenance. A project that’s difficult and time-consuming to maintain in production is a failure.
- Fewer constraints on the technologies we choose, especially if the project isn’t expected to evolve much over time.
- Since there’s only one client, we can find out in advance—or at least agree with them on—the environment where the project will be deployed (operating system, database type, hardware, and so on).
Product development, on the other hand, is a different and far more demanding level of software development, because:
- We need to understand the world of our potential customers deeply. The product has to solve something and provide functionality for their businesses, so we have to know those businesses very well. Not everyone on the team needs to know this, but the person leading the team or defining functionality does.
- We have to derive the functionality to build from what we know about potential customers’ businesses. Writing specifications is very, very difficult; writing them well enough to produce user stories or technical requirements is even harder.
- Configuration management has to be more thorough, especially if we eventually have different versions of the same product on the market.
- Since a product may have a very long lifespan, we need to put much more emphasis on software testability, with automated tests covering everything—or almost everything. Otherwise, testing the system can become such a drain on time that it may even put the product’s financial viability at risk.
- Choosing the most appropriate technologies is much harder, especially if we expect the software product to last for many years, as we’d naturally hope in order to make the development investment pay off.
- We have to put ourselves in potential customers’ shoes and guess or discover their specific, individual needs, then incorporate them into the product through integration capabilities, customization features, and so on.
- We need to define the product’s ideal deployment environment. This can be delicate, because it affects the product’s cost. The more different environments the product has to support, the more effort we’ll need to spend testing and testing again. A fundamental mistake is leaving deployment-environment decisions until the end.
- If we want to improve the product and gain market share, we absolutely need a great deal of feedback from the moment we have our first customer using it. Better yet, the sooner we release an MVP (minimum viable product), the sooner we can fix shortcomings and better focus the product’s development.
The person responsible for developing a project or a product needs to take these differences into account, but they also affect the day-to-day work of the development team.
I wonder why I’ve never seen a résumé mention something like “Software Product Developer” or “Developer of Projects for End Clients.” To me, the difference is enormous.
Without a doubt, developing a software product (or leading its development) requires far more experience and control over many more variables than building one-off projects, which are much more comfortable to manage (although dealing with clients is always difficult).