It turns out that it is pretty darned important. And, more and more (especially the attractive ones) product opportunities depend on technology as a key component supporting its ability to deliver it’s feature set. When Pat Allin and I were talking about the initial designs for Textura’s CPM product, the choice of technology was as important a part of the conversation as the functions that we talked about putting into the product. There were several reasons for this:
- Cost: We knew our customers (especially the sub-contractors) well enough to understand that they were not likely to invest in the purchase of dedicated computer hardware to enable their participation in the payment process. We needed a technology that would be cost effective;
- Stability: New technologies are sometimes unstable. I remember making a rule when I worked for PacTel Spectrum Services in the early 1980s that we would not deploy a version of Oracle until it had been in wide release for at least 4 months. At the same time, older (more stable) technologies tend to calcify and become equally unattractive. Many organizations that are still running Windows XP (and got clobbered by the recent ransom-ware issues) know exactly what I mean. At Textura’s inception, the internet was really just (barely) coming into its own for mission critical and highly sensitive (read, handling money) based transactions. I would suggest that a big part of the long ramp-up in Textura’s business was based on our target client’s unease with using web-based technology;
- Change Management: Generally speaking the industry the construction industry (circa 2000) was not technology savvy. Further, our experience from many years assisting clients implement computer software and the changes that implies suggested that if we were going to deliver a product in with as little effort (from our customers) as possible.
We had a compelling business case and we didn’t want to be frustrated in our sales efforts by the argument that the software was going to be difficult, time consuming and costly to implement. We needed to provide an easy to deploy and easy to use solution.
Never underestimate the power of the “status quo” when suggesting that a business change the underlying technology supporting a key business function.
- Barriers to Entry: This is a sticky topic and causes much heartburn. The question of intellectual property protection is at the crux of the barrier to entry dilemma. Without intellectual property protection, either on the underlying technology or the processes that you build on top of the technology, the risk is high that a well-funded competitor will swoop in once you have proven the concept and essentially steal your clients from you.
Those of you who are in touch with what has happened to process patents will know that this (process-based patents) are no longer being issued. I can tell you that we would never have been able to get Textura off the ground had it not been for process patents on the payment/lien-waver exchange process. Products that have patentable underlying technology have a real advantage in being able to erect real barriers and buy themselves critical time to gain scale and financial stability.
- Change Overload: This is a question about how many things you can change at the same time. We broke this rule with Textura. We changed both the underlying technology (to a web-based solution) and the business process (construction payment process) and it nearly cost us the company. Clients may be willing to deal with changes in one domain, but generally not two. This stalled adoption (until web-based solutions became more prevalent and less risky) almost to the point that we ran out of funding to keep the business going—note I said almost.
So, why did we push on two fronts? The answer: We had to. Remember, we understood that our clients weren’t going to invest (up front, or on an ongoing basis to maintain and upgrade) in the infrastructure to make a secure, efficient payment process work. So, without a web-based solution we weren’t going to get off the ground. There were other advantages to a web-based solution: 1) scalability, our clients could start slow, prove the concept and then fully implement without having to invest in capital equipment; and 2) the network effect, we were able to have our customers register once and work with any number of other partners without having to re-register as they would have to with competitors deploying their products on separate instances of their product for each customer.
That said, Textura was the exception to the rule and I do not advise following our lead on this point.
Technology choices can make or break an idea. Textura would not be enjoying the success it does without the benefits derived by the technology choices. The web-based deployment strategy made the product feasible for subcontractors and provides a positive ROI for all of its users.
Similarly, as we look to the future (for example), many big-data applications (the subject of my next post) will never reach their full potential (which can really change the dynamics of our economy) without the right (defined by the 5 bullet points above) underlying technology.
Finally, I would like to suggest that the choice of technology is a strategy level (where do you want to be in five years and how will you get there) decision. It defines products (in terms of their features), product sets (in terms of how they fit together and deliver value) and platforms (in terms of how internal and external components interact) at such a fundamental level that mistakes in choosing technology are almost always very, if not prohibitively, expensive to correct. And, the more broadly (number of users, or number of transactions processes) a solution is deployed the more important it is to get the technology (mostly) right in the first place.