Product Development and Solution Development are different in almost every dimension — Part 2
Other than the fact that they both involve writing code!
Welcome to part 2 of this short series.
If you want the highlights of this article, please jump over to the end of the first part of this series.
In this part, we jump straight into the weeds on “why” this stuff matters.
The Basics
Let’s say that most software professionals (there are exceptions, of course), but most people in the software development game, get into creating software either by joining a Product company (think: Goggle, Slack, Miro, or Facebook) or they start creating software in a Solutions Provider company (think: Accenture, DataCom, KPMG, CapGemini, Wipro or Infosys).
This is, of course, not true at all! Most people are not working in those specific companies above. They are working in many, many more, much smaller companies you and I never heard of that are either one of those types. I had to name the big ones to get the idea across of a clear difference between them.
The point is that although both product companies and solution provider companies are both making software, they are both entirely different business models, requiring different skill sets. Also, at the software level, wildly different engineering practices and processes in every way imaginable.
Sure, from 10,000ft they might be using the same tools and programming languages and technical services, but they are not doing it the same way, for the same reasons or for the same outcomes.
Solution Development not the same as Product Development
Simple Economics
Product companies create generalised software products that typically lots of people/businesses (in a market) will pay for and use, and in some cases extend/customize for their own needs (a.k.a platforms).
In fact, multiple products will be combined together into custom solutions for any person or business. For example, Your laptop is a product from one vendor, your web browser is a product from another vendor, and so is your smartphone. The apps that you use are products from yet other vendors. Together you use all these products together as a custom solution (for you, by you) to get the things you do, done every day.
The fact that many people buy these products is how the makers of them make enough money to keep going (paying their staff to work on each product).
Product Companies: Build it once, sell it multiple times, and get paid for each user/use.
Solutions companies create specific unique, bespoke, custom software usually unique for each client/business they work for, under contract. To survive, those services companies need to get work from many businesses to make enough money to keep going (paying their staff to continue working on each contract).
Solution Provider Companies: Build it once, sell it once, and get paid once for each client.
Do you now see the difference? Simple economics.
Get Smarter
Both business models create one-off engineering feats of bespoke software — that aspect is really no different. But, you will likely never “see” the actual software of the solutions that are built unless you worked within the business it was built for. Very few people actually experience the solutions that are built. Software products however are much more generally available and used in an open market and therefore more likely to be “seen” and experienced by many many more people.
OK, so what’s the difference, really?
Isn’t it all just software? Well, yes it all boils down to just software (inside a computer), but only if you are only comparing the software outputs of what was created in both solutions and products. But not if you are accounting for all the other work that goes on around “why” they are built, for example in research, sales and marketing outputs of product work. These differences in the context of “why” are vitally important to how the two kinds of activities are executed.
Have you ever considered any of these aspects of building software in these two contexts?
- Who pays for the software to be built, and how is it funded? (per: thing or per: use of the thing?)
- Who owns the intellectual property (IP) created? (those who paid for it or those who built it?)
- Who is the software designed to be used by? (those who paid for it to be built, or those that actually use it?)
- Who decides what features are needed and how should the software work, and for whom? (those who paid for it, or those that get value from it?)
- What tools and engineering practices are needed to “build it right”? (good enough for now, or good enough for change for years from now?)
- What people and processes are needed to build the right software, and what do those people do? (do you see any skills/roles missing on either side?)
- When is it done? (is it ever done?)
- Who supports/maintains it once it is being used?
Doesn’t ALL of this really, REALLY matter, more than just that fact that it is ultimately just writing code?
Not a lot of people know this
If you really know the difference between building software products and building software solutions, you also know that the answers to the questions above will be entirely different for building a product than for building a solution.
The real problem is that: not a lot of people know these answers.
What is even more shocking is that even when those people intellectually come to learn or read about these facts, when they move to execution, they still fail to appreciate and apply them to the output of the software being built.
Especially true when the people building the software change from working in a services or solutions company to working in a product company. To most of them, it is just another company doing things differently (again), but not appreciating why or how you achieve it.
Let’s face it; our industry is littered with shitty valueless software and failed tech products/solutions because of misunderstandings like these fundamental differences.
For example, let’s say that you have been in solution-land as a software consultant for many years and have done enough diverse work and have seen that many customers are using similar products and have similar needs in the same space you are working. Over the years, you’ve had to learn how to use and customise those products, and you may have even become an expert in applying them in that space to many customer scenarios.
You might therefore feel like kind of an expert in those kinds of products in that field. You may also have identified gaps in the market that are underserved by those products/services and maybe you are thinking that you could identify a product that could fill those gaps! So you think to yourself, why don’t you go and create a product in that space that fills those gaps? People will go nuts for it and will certainly buy it — to ease their pain.
Well, fair enough. This is actually a very common pathway and origin for many product companies. Nothing wrong with that, of course.
But what is wrong is failing to recognise how your product should be funded, engineered and supported differently than you are used to building those solutions you were once building before this time.
OK. Let’s dig into some of these more important aspects above and identify some of the hard differences, and then see just how different building software products and solutions are, and why is it insane to think that these pursuits could be the same in any way at all (except that both involve writing code).
Difference 1: Funding/Intellectual Property
The party that pays to build the software will want to own the IP for it.
In Solution Development, it will be the contracting business that is paying you (the solution provider) to build the software, that will want to own any IP that results from the software you make.
They are literally paying you to create the IP they so desperately value for their business. To them, the IP is the most important asset they will have from this engagement with you as a solution provider.
In most of these scenarios, the business knows that building software is not a core competency for them so they outsource that to a solution provider to do for them. As justification for that spend they will almost always want to own the software IP that is created. They treat the IP as a business asset, and as a competitive advantage in their respective markets. They will not want to share that IP asset or license it to any other business (in most cases). There are always a few exceptions to this standard model.
Funding this kind of venture is viewed as a fixed cost like it is considered a fixed cost to build a house or a car, or a piece of artwork (frankly, like making anything made of molecules really!) The cost is thought to be in the building of the software, little consideration is made for the costs involved after the software is first created.
Solution Development is a game where you build software for another business that takes all the risk of funding the creation (and ultimately the support) of building the right thing that gives them some business advantage and ongoing increased revenue. The return on investment is all the contracting businesses, and it is usually calculable and calculated in advance of the investment they make in building the software. The only risk for the solution provider is to build the right thing (as defined by the customer) and build it on time within budget.
Delivering software is the business you are in
In Product Development, it will be the company that creates the product that will want to own that IP because the IP is the reason they are in business, to begin with (if they succeed that is).
Building that product is their whole business. Product companies understand very early on in the game that they are going to have to build and change, and support the software with money they don’t yet earn or have before they have actually sold the software. It's an upfront capital investment (to pay for salaries, rent, services etc), that is ongoing as long as the business is in business. When the money runs out the product dies, and often the company dies with it.
Product development is a game where the product company invests upfront and takes a high risk building the right product and supporting the product that was built right in the hope that at some time in the future they will return x times the money they already invested in selling the product to many buyers. In this way, the investors in the product, and the people who build the product collaborate with a shared goal to make more money in the future than they invested upfront.
We can say then, that there is a very strong correlation between paying for the product to be built and ownership of the IP that is built. We can also say that the funding, risk and reward profile of building products and solutions is wildly different as well.
Difference 2: Requirements
I’m using the word requirements here reluctantly, because in this industry we know requirements by many names, so for the purposes of this discussion, I’m going to use this word to represent ‘requirements = any idea/desire/outcome that the software needs to realise/do/deliver’.
In Solution Development, if you think about it, the requirements for building a software solution [almost] always come from the same party that pays for the software to be built! — understandable, they think that they know what they want and they make sure the right stuff is built for their money, of course.
Usually, they won’t contract the build of software for their target audience (usually their own staff) without figuring out precisely what their target audience requires first. Usually, that is defined by a group of business analysts and refined over the course of several months of planning. This common risk-averse approach has led to all kinds of failures in delivering valuable software to the target audience. Where the software to be built has been specified in great laborious detail long before the target audience of the software gets to actually see and use it. Only then do those people affected by its evolution get to solve their real problems effectively. Something the industry has learned the hard way and fought to change almost 20 years ago with the agile movement.
Solution Development always begins with a set of Requirements!
Unfortunately, businesses still invest a great deal of time and money into creating beautifully complete and precise requirements documents and specifications that they then hoist upon solution providers with a deadline to complete. Before their actual users get any say in how useful it is going to be.
I think this form of intellectual arrogance (thinking a manager of any kind knows exactly what the people doing the work need, better than they do) is still rife in many businesses, causing many of the fouls we see today in software. Most solution providers have seen all this and they are given no impetus or stimulus to create or even hire the right capabilities to build and deliver software that is tailored for the actual humans that have to use it. With that constraint lifted, it frees those building the software to just focus on making only the software that was asked for and making it functional (i.e. that it just ‘works’ for this business) within a fixed time frame.
The good news is that this approach is slowly changing in the industry today, but as long as businesses outsource software and assume they can specify upfront exactly what the software should do for their target audience, they will unlikely end up with something that is unusable, or remains in a constant break-fix cycle, that eventually gets thrown out or even worked around by its intended users. This quite rightly leads to project funding blowouts, slipped schedules, re-writes and distrust between businesses and software organisations. Another thing that the agile movement was specifically designed to help fix.
In Product Development, you simply don’t get any requirements documents to start with! If you did, that ain’t a product you are building! You likely start building a product for a clear opportunity, and by defining a broad set of capabilities based upon actual problems actually experienced by a specific target market of customers (buyers/users). Notice who defines what is actual value here?
Product Development discovers what is valuable to its customers
In product development, you may have varying levels of understanding of that specific market or the product that should be built, so you may come up with some loose opportunities that the product should go after — a roadmap for example. Then you build something in that domain, put it in market in front of real customers (hopefully: early and hopefully close to your target market) and then experiment with those customers directly to find out what else they need from the product. In this way, the requirements are implicitly controlled or influenced by real customers, who might start to begin to get excited about the further development of your product. They may even pay for it now or at some point in the future if you build the right thing. Requirements come and go because they are just ideas (some good, most bad). Good and bad here are measured in effectiveness, not in intrinsic intellectual value. Customers also come and go, and the roadmap changes as you go — the longer the better of course.
Do you see the obvious difference there? Product development is a critically and necessarily a journey of discovery of what actual users want enough that they will actually pay you for it. Solution development is typically about building something that someone else has already specified ahead of time, or whatever the client felt was important to them, isolated from anyone else.
After all, product development is an investment into building a product once, and then selling it to many customers — that’s how you scale your revenue. Whereas solution development is all about building it once for a specific business context and making the revenue once from building it.
The key point here is that you can be very successful in solution development without ever seeing a real user of the software you build. But if you want to be successful and survive in product development you have to be laser-focused on what your customers actually want. We will talk more about this later in the Customers section below to drive that point home.
Difference 3: Project versus Product
Oh boy! my biggest pet hate about the software industry. Failing to recognize and understand the difference between projects and products.
Actually, my opinion is that the root cause of this ongoing tragedy stems from an Edwardian mindset (think: industrial revolution period) that still prevails in most businesses today as the de facto way to optimize any kind of manual labour. One that favours overspecialization, division of labour, and mass-production optimization, rather than: multi-faceted, cross-functional, collaborative mass-customization optimization.
If you don’t understand that writing software is a creative design pursuit and is not manual production, and therefore people cannot be fungible parts in a machine, then shame on you! Refer to Brooks’s Law circa 1975.
Need to understand this better? See my article on Mass Production and Product Development to clear this distinction up.
If you are building software products using projects, you are doing it very wrong!
A project mindset is all about short term compromises and optimizations to reach a specific known goal, often in a specific time frame (fixed cost). A product mindset is all about investing in creating something of durable value that continues to have a higher value over a long period of time.
Projects are a ‘tool’ used by people/businesses to try something new or get something delivered incrementally. If you have ever tried in any company, perhaps the one you work at, to start a project for something like a new initiative you care about, you will by now know all about: committees, stakeholders, business cases, scope, project managers, managing risks, estimates, sign-offs and status updates. Welcome to Project Management and business change. Everything about this kind of venture is about getting it DONE (on time and on a budget)
A Product is only done when the last person stops using it
A Product is never done! [Well that’s not entirely true. A product is done when the last person using it stops using the product, and it goes away.] Products are long term ventures of continual discovery and refinement of valuable stuff that is constantly driven by customers and markets. If you have done products before, you will know all about: customer journeys, road maps, markets, marketing, sales, revenue, research and development, engineering, etc. Welcome to Product Management. Everything about this kind of venture is about making the right thing, making it better, and doing more of it in the future. The heavy-handed project ‘tool’ and all its assumptions, overheads and aspirations has no utility here.
OK, so let's look at this in the context of Solution Development and Product Development.
In Solution Development the work is almost always influenced by projects, since that is primarily the mechanism the business paying for the development is using to remote control the solution development of their latest innovation. Solutions are often specified upfront, time-boxed and budgeted with a pre-defined set of requirements and scope. The solution providers mimic this mindset because they have to closely operate within their constraints, and comply with contracts, timelines, deadlines, status updates, stakeholders' expectations etc. that the contracting business must use.
Some solution providers even hire their own project managers internally to manage the development of their solutions because it makes it easier to fall into lock-step with their customers’ processes. Fair enough. Sometimes, it is because the business has outsourced the project management as well as the development work, so it's just another value-added service that the solution provider can provide. Whatever the drivers, projects become the normal mode of operation for solution providers for whatever software work they do. And, with that comes the respective practices, mindsets and compromises that are all too common in solution development, like:
- Wanting to live on the bleeding edge of the latest and greatest technology, relying on applying new technologies and trends (created by others) to create the best, and most modern solutions.
- Getting it working in time, and on budget, and leaving things like testing it on real people for effectiveness, to the people who are dictating what to build instead.
- Shipping software that is functional now, but possibly unmaintainable and hard to change in the future.
- Moving on to the next project as fast as possible and hopefully not having to look back.
I don’t actually blame the solution providers for these behaviours, they are simply doing what they are incentivised to do by their customers.
In Product Development, on the other hand, is all about applying a set of disciplines that ensure that whatever gets worked on is valuable to its users and is changeable by its creators. Since it will be required to be used in many different customer/industry contexts and must still work and be supported long term. Making the kinds of compromises that projects may accept in the short term cannot be tolerated in the long term in product development.
You can get away with these shortcuts in the short term, but the debt rises pretty fast and rewrites are often the only un-economical way out of the legacy.
In Product Development, there are no Project Managers in sight! Shock horror! You may have Program Managers and Product Managers, but unless your software company is of a large enough size, and it does special management projects to explore new markets or diversify its core business, you won’t ever see a Project Manager in the organisation, and you will definitely never see them managing product engineering (right!?).
Difference 4: Risk Minimization
How do software companies minimize the risk of building something that customers don’t want to buy, or will accept paying for? This is about getting the most value out of your expenditure.
In Solution Development, the contracting business (the one that is paying to outsource the development of their solution) minimizes this risk by having high confidence in their belief that what they asked for is the right stuff for their business — after all, who knows their business needs better than them?
They spend months and huge costs on analysing their business needs and then creating complete/precise sets of requirements that they can go to market with to find a software provider. RFP anyone? Then, they believe, it's just a matter of paying someone else (like a solution provider) to follow the specs, responding to their business analysts, and just building the software they said. Oh, and do it in the time and budget they pre-specified upfront of course — it's a project, people!
Why does that not work so well for goodness sake?
Well, I think we as an industry now know well why that does not work, and we have known for a long time. There really is no excuse for this nowadays. You know this is going on when you see roles like project managers, business analysts, testers, developers, etc. you don’t actually measure any real users, and “the business” says so whenever the “why” question is raised. The bottom line is that this risk minimization strategy (assuming you know for sure what tools people will find useful and valuable upfront before you’ve made them and tried them) is a very poor strategy, and seldom if ever ends well in practice.
In Product Development, the product company minimizes this kind of risk by necessarily shipping software and necessarily mining feedback from their real customers and iterating on it. Hopefully, they are doing that fast enough so that anything they built is validated quickly so that they minimize the wasted effort if it did not work out and have to change it.
Not always the case. It’s a careful balance and trade-off that plays out over time. Product companies take more risk with this process because they are constantly innovating and trying things out to try and impress their customers (and distinguish themselves in the market). They spend a great deal of time, money and effort (cost) to make sure they build the right thing for paying customers, that actually pay for it. You know a product company is doing this well when they have roles like engineers, user experience experts, user researchers, and marketing and sales teams. Focuses and roles you rarely see in many solution provider companies. Primarily because solution providers are simply not paid by their customers to spend time and effort on those kinds of activities or disciplines, that are vital to staying alive in a competitive product marketplace.
Difference 5: Risk Mitigation
How do software companies mitigate the risk of running out of money and ensure they return on their investment in building the software? This is about protecting or preventing against over-spending.
In Solution Development, the contracting business (the one that is paying to outsource the development of their specified solution) mitigates this risk, well frankly: by paying 100% for the software and 100% for all rework that will be needed on the solution to change it, when it does not work or does not meet the needs of their target audience. That’s a pretty poor strategy for them in the long run. Welcome to: hard-to-fund business cases that attempt to get support/money from company stakeholders to get a piece of critical business software changed, fixed or supported.
In Product Development companies mitigate this inevitable risk upfront by spreading the cost across all their paying customers with software licenses, subscriptions etc. Since product development is an ongoing venture and it's never done, it costs money for as long as the company is building and supporting the software. Research and development, ongoing maintenance and support are all obviously built-in as part of the deal and funding of building a product in the first place. Product companies die if they run out of revenue from building the software wrong, or building the wrong software, so they have to get it right all of the time. They use all kinds of strategies to ensure this. Like: not assuming they know what to build, and asking customers instead. Like: releasing new features and measuring their effectiveness on real people, and adjusting appropriately. Like: innovating new features and testing them on real users and getting feedback on the product. Like: building the software to be supportable and maintainable so that it can change easily without breaking it in some other area of the product.
Interesting side-note: Projects in solution development actually should need the same kind of stuff, but it is all too often overlooked as not important enough by the contracting business ahead of time. Most solution projects simply don’t want to recognize the complexity of that kind of ongoing investment and cost. Instead, the business contracting the solution with think something like this: Once the project we defined is delivered and everyone is loving it — project success! We will then either plan to create a new business unit to take over the support for it, or perhaps it goes to an existing business unit or goes to the IT department to be supported and maintained there — obviously. Either way, the business can fund that ongoing support and maintenance with opex, the project does not care! Let's move on and do another one!
Difference 6: Customers and Created Value
Customers, users, consumers, fans, admirers. Those people who every software engineer/designer desires to get some value from their creative labours.
In Solution Development, the contracting business figures that this new solution is going to make a bottom-line business difference to some part/people in their business. That could be to internal staff or even to external customers to their business. If it is to build an internal tool for their staff or partners (as it more often is) they will have already identified the people/staff/partners that are going to receive this software that is likely to automate some aspect of their current roles.
If it is for external customers, they have already assumed that the software being delivered is going to instantly be usable and desirable to those customers. These ‘users’ as they are often called in this context, are defined and known upfront long before the software is ever built or requirements are lined up. They are getting the software no matter what, whether they like it or not. The business has already decided that because it's part of the business case that funded the project to build the software in the first place. That’s often why those users find the software totally unusable when they finally get their hands on it. They simply weren’t asked whether the software is good enough so that they would buy/use it, as it was being built. It is hoisted upon them to deal with whether it's usable or not — and the project and funding are now over, so it can’t be changed. Those users had no free market choice about using this solution.
Some businesses today now recognize this difficulty in their waterfall design processes usually transferred straight into the solution development and try to get their users involved earlier to mitigate that issue. That’s great and makes a huge difference, but it still does not mitigate the fact that those users are a captured market, and they are “buying” the built software the way it is built regardless. The business is basically saying: “No! you can't choose a better solution thanks, we have decided on the best one for you!” It is too easy to build the wrong thing for that kind of audience.
In Product Development, unless you have some kind of product that is mandated by a set of users (i.e. for compliance by a business) you probably need to work very hard to impress your users with your product so that they like it enough to keep using it, or even buy it. This is why you ask them for feedback early. They know best what works best for them.
Your job in product development is not to do what they ask you to do but to create/innovate value for them. Not always, but quite often, those users are also the same people who decide whether to purchase your product or decide to go with another option in the market. In those cases, those users are your customers. If you want to succeed in selling your product to them it had better be a more desirable product than others they can get their hands-on, and it had better be usable, otherwise, they are simply going elsewhere to get that.
There are few captured markets out there for product companies. That’s why product development programs can’t avoid the fact that they must be customer-driven, and simply cannot lose direct touch with their customers changing needs.
Whereas most solution development projects can usually comfortably ignore this constraint, and instead focus on providing other forms of value since the solution engineers rarely ever see their real customers. A common focus can be, trying to stay on the bleeding edge of the latest technologies, since that brings in added value. Surprisingly, a lot of solution developments focus on over-engineering their solutions and liberally applying trendy and expensive bleeding-edge technologies to address their pre-supposed customers’ future problems. Why do they do that?, because if your customers are not directly driving you to create software meaningful to them, why not put all your energy and focus on learning how to bring the latest and greatest technologies to bear in this wiz-bang solution? Perhaps your peers will admire your creative labours! Besides which, in creative industries, everyone wants to be engaged in learning the new tech stuff which is very meaningful to them, and their future careers.
I like to point out to tech people that, if you have technical ‘architects’ driving customer requirements for the engineering teams (as the proxy for dealing with real customers), you are likely to have already fallen into this tech-fest trap. Watch out! it is called “the bleeding edge” for a very good reason.
Difference 7: Support/Maintenance
Once it is built, who is going to change it?
In Solution Development where project thinking is rife, the focus is to get the solution built and used quickly so that the business can declare project success. Job done! The temptation is to believe that once a solution has been built, it's a little like a piece of art in the reception of their premises. It is complete and will never change. That would be the case in most other engineering disciplines like building a bridge or building a hardware device for example. Once it is complete and deployed, changing it is very difficult and expensive. Those kinds of engineering ventures necessitate a lot of upfront planning in what to build so that the thing being built works flawlessly when it is deployed, and replacing it will be years away.
Part of the reason a business does software is because of its innate ability to be ‘soft’ and malleable — so it can be easily changed, and it will need to change. If change had been the focus at the start of the software building, then the engineers may have put more effort into creating more easily maintainable and durable software, but this will be highly unlikely and instead, getting it working on time and on budget would have been the primary driving focus instead.
Working software is just not enough!
In Product Development, creating working software is simply not enough. Sorry to disappoint. The fact that software works is only one small part of engineering durable, malleable product software. Software in products has to also be: easily read and understood by other engineers, even for some time after it has been written — it is always a team sport. It has to be easily changed over time without breaking it elsewhere. It is required to change over time — to stay from rotting with the ever-changing technologies it runs upon, many of which it has dependencies on when it is first written, and they will be changing too.
Furthermore, it is not even well known by veteran software engineers, that writing code is far easier than reading code — even your own. What does that mean? Well, if you are very fluent in writing code, then when you encounter other code that is hard to read, you are likely to want to re-write that code rather than you are likely to spend the time required to read and understand and then change that code. Writing readable code requires a lot of extra discipline and additional technical practices than normally necessary to just write code. If code has not been written in a way that is easy to read, understand and then change when it is encountered, then it's a foregone conclusion that the code will be re-written instead. Whether the engineer or the product or business desires that or not. Every seasoned software engineer knows that, even if they are not aware of why it is so.
Writing code is far easier than Reading most code.
That’s why it is imperative for product companies to invest far more money and time in making their software more maintainable from the get-go, and why product development is always necessarily a team sport — because you have to write code that others will have to understand. Whereas, in solution development, individual solo coding efforts are accepted as the general norm for expediency.
Those businesses contracting Solution Development do not experience the kind of financial pain related to this issue until long after the software is built. Only when it comes time to actually change it later on. The original project just didn’t care about that! Therefore, those businesses rarely, if ever, invest upfront in the extra cost and effort required in their projects to guard against this issue by incentivising the solution providers to create maintainable and supportable software from the get-go. The fact is, that most solution providers are unlikely to have the necessary capabilities in place to enact that extra discipline for their customers because it is not paid for most of the time. It is then, inevitable that re-writes and expensive re-engineering of solutions is the norm, and those tactical efforts are again driven by more projects. We go round and round in very expensive break-fix re-engineering circles, and the quality of the software decays over time.
Product Engineers are required to enact a set of disciplines and practices that Solution Engineers rarely ever practice.
Wrapping It Up
There are more critical differences in how Solution Development and Product Development are executed than most people in software actually understand.
It is these differences and others like them, that make all the difference between the successes and failures of both Solution Development and Product Development.
Trying to minimize or normalise these differences by assuming it's all just software, is just naïve and not business prudent.
Specifically. If you are either: a solution provider thinking that you can just embark on building a product the same way you have been building your customer's solutions, OR you are in fact a product company and you are not using a product development mindset, structures, and disciplines to engineer your product: then your product is likely to fail in the short-medium term for the reasons outlined above.
Pay special attention to differences in ‘Funding’, ‘Project vs Product’ and ‘Support/Maintenance’ because the durability and long-term maintainability of your product and the cost of running your business in the short-medium term are directly related to these differences. That’s because unlike building a bridge, your software is going to change forever more.
If you are (against all the odds) extremely lucky to create a killer product that makes you a ton of revenue very early on in the game, you may get the second chance to afford to re-engineer your product from scratch again (whilst still supporting your legacy dog of a product). As a very small number of well-funded product companies have done at a very high ongoing engineering cost. Otherwise, your legacy, hard to change and brittle product is going to slow down your business agility to a grinding halt in the short-medium term and eat up all your revenue and investment capital. Either way, long term neither of these two choices are economical options, and you will need deep pockets from your customers and investors to achieve them.
It is far more economical in the short and long term to invest upfront in a disciplined product engineering mindset and practices that specifically guard against high medium-long term maintenance costs so that you stay agile and financially fluid through the short-medium and medium-long term.
Originally published at https://www.linkedin.com.
