IYKYK
Standard offerings and products OOTB (out of the box) are easier to sell, and often have a lower price point and higher profit margin. (Gulp!) Many times, they are more robust. There is a fine line between positioning critical functions in solutions and risking the process stir in an organization.
What appears to be good enough may not be.
Although the advancements in technology have accelerated tremendously since I punched cards and wrote Assembler, the impact of an organization’s size has remained the same. I have seen firsthand how the size of an organization impacts its ability to consume “standard” software. Size affects structure since large organizations are usually tall with multiple complex management layers. In larger companies, tasks are often subdivided into separate jobs, with a high degree of departmentalization.
From a provider perspective, standard product offerings are economical, and streamline the delivery and management of the products. Building it once and selling it 1000x allows the provider the luxury of skimming over abstruse requirements. They can eliminate the need for custom network configurations, or one-off compliance requirements that increase the price and decrease the likelihood of getting the business. They can reduce the need for specialized skills, or niche integrations only used by a few customers.
Is "standard" good enough?
Three prime arguments for using custom software are:
1 Differentiation in the market
2 Formalization/Departmentalization
3 Internal compliance requirements (in addition to industry standards)
If a customer can differentiate themselves in the market, they may be able to survive even with more and more competition.
One example that resonates is a state government software solution I wrote that was used in multiple states. Since each state is legislated to adhere to their own rules and regulations, what started as a software “package” quickly became “customized” software. By delivering this custom solution, the agency could implement what reflected on their legal obligations and automate/scale to maximize its effectiveness.
The balance between the critical path of an organization and the standard delivery of software and technology is a balancing act filled with trade-offs. The customer has to determine whether they are willing to accept the extended development time, up front costs and skills to land at the level of specialization required by their business processes.
Arriving at the middle ground could be as simple as finding the “crowd-pleasing” capability that sets you apart as a provider and to use technology decision points to accentuate the essential values of your standard offering.
Comments