Is it a Product or is it a Solution?
How to tell, and why it matters
Something that is not well understood by most working in the software world is the difference between building a product and building a solution.
I want to help you understand this difficult distinction because the difference in how you go about: organizing for, funding, managing, designing and making these two things couldn’t be more different, as you can see from this comparative breakdown.
I hope to convince you to stop holding fast to the belief that you can get the same outputs, by using wildly different skills, process, tools and practices. That belief simply does not hold water in our industry. A duck is not the same thing as a chicken.
Product or Solution?
Language is important because it shapes the way we think, and therefore the way we act. So, before we go any further, I want to clarify what I mean by a product and a solution.
Unfortunately, for you and me, there are no canonical dictionary definitions, or industry standard definitions when it comes to this in the software world. Certainly not one that fits every case effectively, so in lieu of that, I’m having a crack at duck-typing these things for you instead:
Duck Typing: TL,DR; walks like a duck?, quacks like a duck? -> its a duck.
- building something to be sold to a large addressable market -> product
- building something that is already individually customized for every end-user -> solution
- building something to someone’s detailed specification -> solution
- building something to grow your own business -> solution
- getting paid now, per thing built, on a time and materials basis -> solution
- getting paid-back in the future for selling a bunch of them -> product
- consulting/services company (for their clients) -> solution
- enterprise (for their staff) -> solution
- enterprise (for their bosses/stakeholders) -> solution
- enterprise (for their organisation) -> solution
- enterprise (for their end-customers) -> product
- tech company (for their end-customers) -> product
- requires only developers/BAs -> solution (or badly done product)
- requires designers/product managers/marketing -> product
- requires no user research -> solution (or badly done product)
- does not prioritize usability -> solution (or badly done product)
- requires no marketing -> solution (or badly done product)
- get rich(er) quickly -> solution (or just very simple product)
- get (really)rich -> product (requires oodles of other stuff too)
- short term venture -> solution
- long term venture -> product (or badly done solution)
- can be finished or done (on time, on budget, etc) -> solution
- all planned up front -> solution
- built by an individual -> solution (or badly done product)
- small teams of cross-skilled people connected directly to their customers -> product
- larger groups of specialists roles coordinated by a manager of some kind -> solution (or badly done product)
Judge whether each of the statements applies to your context, add up the scores. Majority describes what you have, or are doing.
p.s. The “(or badly done product)” label above, is because even in 2022, a lot of tech/software companies (large and small) are still founded on the idea that software (and therefore tech) is a subservient division of their company that “serves the business”. Ironic right? A crazy and outdated idea carried over from corporations/enterprises where “tech” was at one time NOT their core competence, and the I.T services team (who manage their: networks, email, desktops, lights, power, etc) literally did serve the business (and quite rightly did). Companies founded upon this principle (of segregating their tech function) may in-fact be building real products for their end-customers, but are doing it with highly in-effective organisations, cultures, and management practices from the dark ages not appropriate for product development. Frustratingly, these dinosaurs still exist, and still cause a lot of dissonance to those working in them and with them.
In Conclusion
Now, this guide should have helped you make the distinction between the two types of offerings we have in software: product or solution.
Not in every case you can think of — of course — it is not a perfect model by any means. It is more of a guide.
BTW: No one says everyone is building product or solution in a correct/effective way (or even knows how to) all the time, and that makes it hard to make a model that everyone agrees with, or fits within. Our industry, and even those within it, especially those who enter tech late in life, are full of misconceptions, and generally have a poor understanding of effective processes and practices when it comes to doing product development. Whereas solution development is far more straightforward — for good reasons (see above).
So using this guide, I think its now safe to say something like:
If you are building a product to get rich quick, and you sell to only a small number of customers, and you are asking them “what you should build for them?”, and you just dictate those things to your group of developers — then you ain’t building a product. That’s all solution baby!
…and none of that can scale to product! not you, not your team, and not your tech.
