Recently a software engineer proposed to use a hot new technology to address some problem that he was having. Actually there wasn’t a problem so much, as a desire to use the cool shiny tech. While there was a scramble to figure out if this should be used or not, it reminded me of many similar experiences I have encountered throughout my career.
Do any of the following scenarios ring true to you?
CEO – “Everyone seems to be talking about big data lately. We need to add support for Hadoop.”
CEO – The following week – “We really need to support big data. Have you added it to the roadmap yet. Cassandra sounds like the way to go.”
VP Strategy – “It is important that we incorporate blockchain to secure our client data moving forward. How much effort would that be?”
Front-end developer – “I don’t like the calendar control used in the other application pages. It is hard to work with. I am going to use this new library I found to speed up my work.”
Back-end developer – “I have been reading a lot about node.js and it looks cool. I am going to try it instead of our Python standard for this new add-on application I am working on.”
The first response to all of these requests should be No.
I know. I know. As a product manager, you probably want badly to innovate and deliver surprising value to your customers by using the latest technologies. Therefore, it is often harder to say no to playing with some hot new technology than it is to the 50 feature requests you get every single day.
In fact, everyone in your organization is often pushing for faster innovation cycles. So why is saying “no” by default the right approach?
5 Risks in Blindly Adopting New Technology
Below are some of the impacts I have witnessed over the years from chasing technologies. Sometimes more than one negative consequence applies.
- Not Needed
- Wrong Solution
- Lacks Maturity
- Added Cost
- Poor User Experience
1. Not Needed
As product managers, we should start with the Problem whenever possible. However, sometimes we have some specific technology available or requested. Just like when someone asks us to add a very specific feature to our product, we begin by asking why? The same needs to be true of requested technology. Adding tech for tech sake is rarely a good decision. It creates direct cost, opportunity cost, and technology debt.
As an example, big data technologies created a massive noise in many technology companies by 2010 as Hadoop was taking off. Within many large enterprises, they felt compelled to invest in big data technology and created data lakes. The idea was that you had to start collecting the data now and later on you will find the use cases to apply the data.
As tens of millions of dollars were sunk, limited benefits quickly emerged. Some started to refer to these data lakes as data cesspools. Over time redundant projects were created storing the same data multiple times. A partial redo of the data warehousing and data mart story of the 1990s but this time at a far great scale with rapidly evolving technology.
Over time, many of these projects have been shelved due to a lack of compelling ROI. Moreover, data privacy and security concerns turned a potential valuable resource into a big liability.
2. Wrong Solution
Just like you don’t design features then try to figure out if they will solve a particular problem for a customer, you should not start with a technology and try to figure out where it can help.
I worked with one startup who determined that their entire tech stack should be “big data” technology. So when they designed a workflow manager that had to handle a few hundred records a day, perhaps a few million a year across all their clients they started with a backend data store using ElasticSearch. Despite ES being designed for search across a massive distributed data this fit with the big data credo.
Developers quickly built out the ability to search for and list a beautiful set of records. Then they started to develop basic list management and workflow features that demand responsive displays, live data updates, and a variety of role based data permissions. At every turn, we found that this novel operational database required workarounds to make it support the fundamental features found in inexpensive RDBMS for 30 years.
The comparison with a simple MySQL database could not be more stark. The right technology may be the old and boring choice but it would have simplified architecture considerably and dramatically reduced the effort spent working around fundamental limitations.
The lesson from this episode is that you must start with your problem definition. Then find the best technology to support your solution.
3. Lacks Maturity
Sometimes you have a real problem that needs solving and multiple potential solutions with various trade-offs. This was the case many years back when we made the decision to store data records as XML objects. This was going to be the wave of the future and would give us maximum flexibility in how we manipulate the data for display, search, and other purposes. Plus we didn’t need to describe it fully at write time. We could just store any data and figure out how to display it later.
For a while after we made this decision it seems like there were no drawbacks. Then we started working on data archive requirements. For this, the only acceptable solution we found for our clients was to render data into PDF files for WORM storage. Here is where we hit upon technology maturity issues of the open source libraries we bet so much on.
Our global client base happened to use more than just English. Moreover, they used more than just left-to-right Latin based character sets. It became clear that any language that used UTF-16 character encoding would break our open source transformation engine.
We could have foreseen this problem if we focused on the reasonably expected scope of needs. Then we may have chosen not to store XML data. Alternatively we may have simply started with a different engine for rendering to PDF or several other paths we could have taken.
Having gone with the quick solution, that was not even considered v1.0 yet, cost us considerable pain later. Subsequent, client dissatisfaction and refactoring for a new engine easily cost us 4x our original investment. Was it worth it? Unclear but when we were battling this, we sure wanted to make the original decision over again.
4. Added Cost
One of the greatest problems with chasing the shiny objects all the time is the added cost to maintain a disparate stack of technologies. As we have moved to a world dominated by cloud based solutions, we have the luxury of not having to worry about meeting all the technology standards we used to have with on-premises software. For example, it would be typical to have to support an enterprise web applications on multiple J2EE Application Servers, multiple relational databases, and server processes on many different operating systems. Further, we would need to make sure multiple combinations of these technologies worked.
Today, these support permutations are a thing of the past. All are hidden in the cloud so we pick the tech stack that works best for us. Further, we have often broken out monolith architectures into a service based architecture that is simply reliant on APIs. This provides a great deal of flexibility that can be both great and costly.
Each service can use different technologies and different versions of the same technology. Use node.js in some service APIs and python in others. Run some services on containers and other on bare metal. Log and instrument each service in a locally optimized manner.
All of these decisions that work for flexibility and independence of design create other pain. In particular, the cost to train developers to work across technologies is higher. The cost to maintain all the technologies is higher. The cost to do things that optimize for the global good, like centralized logging or orchestration is either high or impractical.
Tackling data security issues can be a nightmare in such an environment – both diagnosing risk and mitigated it.
These problems are usually the result of a lack of architectural and technology governance. Individual developers making decisions based on personal preference which often leans towards the latest shiny object.
Experimentation is great. That is how you find your next best enabling technology. However, controls need to be in place to balance strategic needs with desirable local optimizations.
5. Poor User Experience
As product mature over multiple years, the frameworks, components, design best practices, and more improve. Similarly most applications grow more bloated with a history of design decisions that have evolved as well.
The result is often an application that have multiple designs to perform a similar function in different parts of the user interface. While trade-offs on the back-end of a maturing system can often be transparent to your customers, the front-end user experience never is.
In one situation, we had decided that we wanted to improve the capabilities around tables (aka grids) that show up in many places throughout the application. We needed to modernize sorting, filtering, formatting, and paging behaviors. The problem was that we had 6 different grid controls used throughout the application. Some of them one time, but most were used in multiple places.
Enhancing one or two would degrade the UX by making them behave differently. Updating all was cost prohibitive for the ROI we could readily estimate.
This type of problem is the result, again, of developers making local optimizations and choosing the latest useful component each time they were solving a problem.
The lesson here is that, for a UX perspective, it is often better to create a consistent experience across your application rather than going after the current best design. If we had done so over the years, it would have reduced our cost to enhance table support across the application in a single shot.
With so many negatives when should we adopt new technology?
New technology is great. Let’s face it, most of us are building new software products because we like to create solutions to our customer problems. We don’t think the current alternatives are good enough. Frequently, new languages, libraries, components, and frameworks are the best way to enable us to build a valuable solution to their problems.
The five risks should serve as a warning to not always jump to the latest technology at every turn. Instead we need to take a more measured approach with some degree of governance that is aligned with the maturity of your product, company, and the market you operate in.
In the end, a lot of those requests from your CEO and developers are the right thing to do. By starting with No, you give yourself and your organization, the space to evaluate the implications. Sometimes you will be convinced to jump on the new technology. Other time it will be clear that the answer is yes, but just not yet.