Product Development and Solution Development are different in almost every dimension
Other than the fact that they both involve writing code!
The above line is my all-time favourite pun articulated by my friend and former business partner — a.m.kissling. He’s fabulous at distilling these kinds of one-liner observations.
He came up with it during our write-up of one of the many Built For Speed (BFS) discoveries we have been doing over the last few years for Callaghan Innovation, in New Zealand. Where we’ve gone in to assess the product development competencies, capabilities and cultures of various software companies around NZ who are trying to scale their product businesses, funded by Callaghan.
In that process over 4 years, we’ve lifted the hoods on all kinds of software companies, of different sizes, in lots of different industries all over the country. They are ALL definitely making revenue from building and selling software to their customers. But, perhaps surprisingly, some of them are also earning revenue from unwittingly building custom solutions for their customers too!
If you are interested in the results of this significant programme of work, here is the representative state of NZ product tech industry, after assessing ~150+ of these tech companies:
The way to understand this image is that: the darker scores represent the average scores across all ~150 companies assessed, and the light grey scores represent the score of the best company in the group. There is a giant gap that no one is talking about!
There was one common major problem in almost all these companies, and it's representative of other tech companies in all developed countries, not just NZ. Many of these tech product companies don’t know that they are, in fact, creating their tech products using the same: mindsets, technical practices, and management processes that are adopted by other Enterprises and Solution Providers/Services companies, who also make software. The same kinds of companies that build software solutions for their companies/clients— which, if you don’t know yet, is an entirely different game in software than building products for your customers!
Many of the founders and management teams of these tech companies came from the kinds of companies where the ‘solutions’ (Service Provider model) mindset is dominant (i.e. most corporate Enterprises). They brought that baggage with them into their product company, because it is what they knew and learned over there, and they just assumed that products are built the same way. For founders with a non-tech background, it seems that they just thought that the Enterprise IT way is the de facto way to build software products. Both founders are wrong to think that building tech products is like how other industries produce their products; i.e. following the same basic process of production that you might follow for, say, building your own home. In other words, they conflated production with development. They think that it is just a process of knowing exactly what you want, you then plan it, then quote it, estimate it, get the funding, and then deliver it, and you are done. Get rich quick!! super easy, right?
These people are all possibly either just ill-informed or poorly advised, which is a crying shame, because their businesses suffer long-term, and they often fails to scale, petering out over the course of a decade or two. Ultimately, pissing off their hard-earned early adopters.
The net result is that these tech businesses are unwittingly failing to scale their businesses, and they don’t understand why that is the case.
Certainly, none of the business owners thinks it has anything to do with how they’ve set up the execution within their business, nor due to the effects of having execution dictated from the top of the company.
They tend to blame the people inside their businesses for incompetence instead.
Let’s now see how building products and building solutions are fundamentally different.
But first, if you want to understand what is meant by a Product and what is meant by a Solution, jump over to that article to explain this first, then come back here.
Mismatched Expectations
OK, so this is how most of the business people who start or own these product companies “see” and interpret the process of how they should build a product.
Much like they imagine the process of building their dream home.
It goes something like this for building your own dream home:
I’m definitely simplifying for the sake of brevity, and I’m not accommodating for regional differences here either.
- You hire a good [civil] architect and a good [civil] construction company/builder to make sure that your home can be built, and at a reasonable price for you.
- You come up with some land
- You come up with some ideas for your property that the architect will validate and rework for you into a blueprint and some plans (to ensure that your ideas work in the real world with human design factors and that it meets the local building codes).
- Plans that the [civil] builders and [civil] engineers might validate for the architect (that can actually be built with materials and tools that can be obtained in your marketplace and within your budget).
- You get a quote and an estimate, a schedule and a start date from a construction company/builder.
- You get it all approved and signed off with local authorities, who verify other factors like the zoning, utilities, regional plan etc.
- You secure the money to pay for the land and all this estimated work. You have basically planned away most of the risk of failure of not getting a livable comfortable home that suits your customized individual needs, where you want it.
- Once all the planning and bureaucracy is over, and you have the permissions, permits and money together, you pull the trigger and buy the land, and get the home built by someone else (a builder) to some schedule that you negotiated with them.
- Eventually, as long as everyone does what they promised to do, you get a functional and comfortable home you can live in that suits your specific needs as a new homeowner.
Tada!
Surely, building a tech product should look something like this reasonably complicated process?
Wrong!
It just does NOT happen this way when you are building any software, solution or product. Why not?
Primarily, because you are building something unknown, from unknown parts, with unknown materials, for an unknown audience who then have to “live” in it comfortably. And worse, all those aspects are changing over time as they evolve and are discovered. Very little is able to be reliably planned ahead of time.
What’s worse is that in software, there are no standard materials, no standard practices, and no regulating authorities. But even if we did have all those things, we are still trying to create something unique and fit for purpose, either for a company or for a market.
And most importantly, unless the people (who are going to “live” in your new software thing) are there all along the journey (to ensure that the right thing is built for them and that it is built right), then you are forever going to be dealing with their issues using it and making it work for them (i.e. poor usability, and poor functionality), and forever fixing issues with it (i.e. poor quality and broken parts).
All that stuff applies to building any software, solution or product — building either is not at all like building a house.
Building a Product or a Solution?
Now, the differences between building products and solutions in this world depend largely on who you are in this analogy?
Are you the one doing the building of the software product for your customers, or are you the one contracting the software solution to be built for your business/users?
Across a couple of decades of doing this kind of work and caring about its outcomes, I see the same fundamental mistakes made over and over again by similar businesses. Having seen this in all the places I have worked all over the world, I know it is not an exclusively NZ thing.
but it sure feels like there is more of it here in NZ than in other countries I’ve lived and done this work in. Perhaps it's the DIY culture here, perhaps it is a small scale affected thing, or perhaps there is still way more solution development around here than product development still in the 2020's.
Regardless, the base incorrect assumption I see being made all the time seems to be that building software Products is the same game as building software Solutions!
This is what most people think:
Its all just software, right?
Nope! Wrong, it is not.
It is such a prolific assumption in tech that you can take almost any successful tech Solution Provider/Solution Integrator, and it is likely that after about five to ten years of playing the services game, the founders or their board will want to start building products.
Why not? Of course, financially, it makes total sense because those solution providers know that building solutions only scales one project at a time (i.e. it does not scale). There is no recurring revenue or revenue multiplier in the Solutions game. Products can give you that revenue multiplier with economies of scale and things like subscription-based licensing.
Particularly for those who own these services businesses, it is a clear path to retirement, once they stop putting their bodies on the line delivering their services.
Those doing the work
For the designers/developers working in these services businesses, it seems that building products have far more sex appeal than building the solutions they are used to working on.
No wonder, right? All creatives/makers desire more people appreciate their carefully crafted handy work. They are all essentially “designers”, not artists remember. So, products offer a way to have a far larger impact on the world than solutions do.
In reality, however, building products is far harder, more rigorous, and to some degree with less creative freedom than building solutions. Certainly less variety than working on solutions.
I would also say from experience, that there is a real tangible difference in capability required for developing solutions and engineering products, and not all software developers have that capability. As they find out only when they interview at the large software product companies.
One other interesting side point, there are some interesting and identifiable personal career paths in the software industry that many take. For example, many solution developers aspire to move from solution development to product engineering, perhaps wanting to have more impact (on more people) or to hone their skills in a specific technology domain. Product engineers also desire to move to solution development (as independent consultants) to get more variety and the opportunity of applying bleeding-edge technologies, and perhaps to get paid more for their time. Then there are the solution consultants who, after five years or so, want to create their own consultancy to fund the building of their own new products.
I guess the grass is always greener on the other side. These kinds of movements have all been going on for decades, of course, and they are good for those people’s careers and experience of course.
Transitioning
The solution integrators/providers that do embark on getting into products seem to initially approach it like it is a special internal company project of theirs that they will manage like any other piece of their services business. They are very confident and convinced that their target customers will buy this product since they are doing it in response to the real opportunities they see in their consulting work.
In some cases, their customers might actually commission them to do that work indeed! But regardless of what the opportunity is, the unfortunate outcome is often failure in delivering a durable product to market economically that earns them any ROI on the venture from enough actual customers. There are all sorts of motivations that drive them to dive in, but they are seriously missing on the “how” it gets done piece, which is also vital for success.
They might say: “we already have all the technical skills and experience to ace building this kind of product” they have indeed been specialists working with these kinds of products/solutions for years. They might say: “let’s build a product and we can staff it with our technical consultants when they are on the bench and have no billing revenue” these guys and gals might after all be experts in these specific technical fields. They will propose that: “we will fund it all from our services margins” to avoid investing any capital upfront.
These are all very enticing ideas from the viewpoint of a solutions provider management team and board, but they are all flawed assumptions. None of these things are what you really need to be successful at building products.
A Disconnect
You might think everyone in the software industry is well-read enough to know the clear difference between building a solution and building a product. As clearly identified by Fred Brooks in his seminal work The Mythical Man Month from 1975! But alas, I’m constantly confronted by software business owners, software managers, CxOs and engineers alike who know precious little about these real distinctions. It is all just writing software to them.
Clarity
I’ve been wanting to write this article for several years now and have actually scrapped the idea several times.
Why? because the things and nuances that this article talks about are so broadly misunderstood today by so many people in the software world, and there are so many conflations and variations of these two different worlds now, that almost anyone can claim that the distinction is not so clear to them anymore — and they could be correct.
For example, they might say a non sequitur like, “We build products for our clients”. Or “we build custom solutions for our customers at my product company”.
For example, I actually have very respectable and highly capable friends of mine building actual products, for actual software product companies, but as consultants hired from a solution provider, for example!
For example, In my own career, I was a consultant in a product company (Microsoft) helping solution providers build solutions for their customers.
Good grief! There are all kinds of bastard children business models out there today. It is just no longer crystal clear who’s working in what context anymore. So, no wonder that it is hard to get people to agree on what qualifies as building products and what qualifies as building solutions, and what makes that any different.
But alas, I am going to give this article one more go. I hope you have some time to get through what I have to share.
TL;DR Summary
I decided to split this article into 2 articles so that you can choose where to invest your time. The link is at the end of this article.
Below is the short-form summary of this long-form article and the next article. The next article gets into all the details about “why” these things are true if you need those details. Below are just the highlights:
- Much of what you could learn in this article has already been known for more than 40 years. Not much new here. What is surprising is that still today not a lot of people in software actually know much about this stuff.
- The vast majority of people building software companies today come from services companies (any industry) or from experiences building software solutions. If their company is a product company, they don’t recognise that it will be a very different kind of company.
- There are far more people in software building solutions than building products. I estimate (anecdotally) about 50:1
- Many product companies start out life thinking that building software products is the same as building software solutions (because that’s what they are used to doing), and then they use the same mindsets, practices, processes, and management optimizations to run their businesses. This is often expensive and disastrous long term. If you do this, you will be joining the league of other solution providers/integrators, before you, who have failed to build successful products in the pursuit of recurring revenue.
- Building software solutions and building software products are dis-similar in-reality in every way possible, including their: practices, processes, mindsets, skills, roles, focus etc. For many non-obvious reasons, some of which you may know, and most you won’t. (Unless you are experienced in both kinds of businesses).
- The success rate for building viable solutions companies is orders of magnitude easier to accomplish than building a successful product company, for good reasons. Building new products and selling them is far harder than selling existing and known solutions.
- Solution development is always driven by another business (usually using ‘projects’) that then grossly underestimates the time and money required to build robust, durable software products to sustain their own business in the long run. Because their core business is already stable (in the long run), they are focused on optimising changes to the business for the short term. They are experimenting. At the same time, they desire all the cost savings and power that software can bring them. They believe all the cost is in building the software (hence using projects to get them “done”), and many ignore the cost of changing, maintaining and supporting the software long term.
- When it comes to buying solutions, it is naturally assumed that someone in their organisation (usually an executive instructing a BA) can then come up with a solid plan for exactly what the other humans (in their org) will need to get to automate their jobs, and they act as a proxy/advocate for those people and the business for what should be worked on — they dictate the features. Then they assume they can just pay some other specialist company (the solution provider) to build it for them to some kind of specification (requirements) from them.
- When it comes to building products, we make small informed guesses about what to invest in building and test that on markets to see what is actually effective in-market. We don’t assume we know what is needed. We test real humans to see if they want it and will they actually buy it. If you are using projects to build products, you are definitely doing it wrong!
- In solution development, many of the disciplined practices that are required to build durable, scalable, robust software for long-term change are skipped/ignored in favour of getting the software done and delivered — on time and on budget. The result of building solutions is software that is unsupportable, not maintainable and varies wildly in terms of its quality and robustness. Software products (and software solutions, for the most part) are never done, they must continuously change over time, and they must be made to be easily changed over time — as they evolve. Otherwise, you are in for a long and expensive cycle of rewrites they perpetuate themselves. There are several key indicators to watch for to know when this is likely happening in your product — like having far too many developers on one codebase, rushing to deadlines, and never doing any discovery work.
- The way you: fund, specify, own, manage risk, support, and what you focus on in building products and solutions is wildly different. You should know how they differ before you get into product development. They are not obvious and they are different from how you go about them in solution development.
- Suppose you build software products by outsourcing the development of it to a team of developers somewhere remotely. Nothing is wrong with that, perse. However, if you distrust them and want to maintain control over what they build, then you are likely doing that by providing them with some requirements and deadlines. Therefore, they neither have what they need to build the right thing nor will they have the correct motivators to build it right. Your product will fail for you, and it will fail all your future aspirations for it, very painfully, in ways you cannot yet imagine. — You have been warned.
OK, if you are still with me, Let’s get into the details of why this stuff is true.
Rewritten from the original article found here by the same author.
