New Things In New Ways, or Same Old Things In Old Ways?
A framework for evaluating the innovations in your product’s portfolio of features and technologies
One of the most important elements in delivering innovative products to market (and the search for product-market fit) is a keen understanding of just how new and innovative your product might be. As trivial as this sounds, taking a hard look at product plans, architecture, and experience can offer insights in how to deliver the most value to customers and to be genuinely innovative.
The vast majority of work on any product — a brand new one or an update to an existing and successful product — is relatively incremental innovation. I know that sounds like a bummer, but that’s just how it is. Even the most inventive products — I’m using inventive specifically versus innovative (more on that in a bit) — are filled with features and code that we’ve all seen before. Your company might have invented an entirely new way to solve a problem or even an entirely new problem to solve, but you’re still going to have a ton of work to build out the mundane aspects of a full product (authentication, management, integrations, security, and so on).
Therefore, a full product offering is a portfolio of features and technologies as well as problems solved. Taken together those form the overall solution — what problem is being solved for customers and how is it solved. It is these aspects that can form a useful lens or tool with which to view your product (or proposed product).
The key question is does your product do new things in new ways? It is also a much more challenging question to answer than most think, primarily because we all like to think everything we’re doing is new and we’re certainly using the latest and greatest tools and techniques to do the work. So why is this so difficult? Why is this important?
Let’s first look at a simple way to view a product through a framework. What has worked for me in the past is to look at the portfolio of features and implementation that make up a product and placing the main elements of a product in buckets that reflect what is being done and how it is being implemented:
- The “what” — things. Things are the features or user experience elements of a product. What does a product do? How do customers experience the product? What work products (artifacts, reports, analysis) does the offering produce? What are the main tasks accomplished by the product? Things can be thought of as the product experience experience, tasks accomplished, or the work products produced by the customer.
- The “how” — ways. Ways are how the features or product are implemented. What are the key technology assumptions? What is the product architecture? What implementation techniques are used to build the product. What are the scale/performance attributes? Ways usually get thought of as the tools and technologies used to build the product and the scalability, security, and flexibility those provide.
A question then is how “new” or “old” is a product along these dimensions. That’s the fancy drawing above.
In deciding how a product is new or old across these dimensions you have to simultaneously decompose it and also take a broad, macro view of the entirety of the space.
New things in new ways is the default mode of working for startups.
New things / New ways — Invent. The upper right is where everyone wants to be. In this quadrant we see products that are enabling new scenarios and doing so using new technologies and approaches. AWS, in particular S3 and EC2 when they were launched, showed radically new models for compute and storage. That’s an easy one though. Salesforce CRM is a product that shows the subtlety of defining newness. While hardly the first CRM product, Salesforce up-leveled the whole notion of CRM and took it from an after-the-fact task to record motions or a tool for sales analysts and turned into a real-time, sales-driven tool for sales-person productivity. Of course, it was also built on the nascent cloud architectural approach, and subsequently focused on mobile. Even though it was not the first CRM product, it is clear that it invented a new approach to sales productivity using cloud software for the enterprise for the first time at scale, so clearly a new/new offering.
New things in new ways is the default for startups. This is always said with a sense of caution as cloning an existing product but doing it in a new way such as mobile or cloud, but without a unique point of view of what a product can do is generally a high risk/low value strategy. This is one reason why as a startup you need to do more than simply have a SaaS offering of an existing feature set in order to have a sustainable moat. While new/new is a good ingredient for a moat, it does not necessarily lead to one — a go to market strategy needs to be part of this as well.
Old things / Old ways — Increment. Few want to be in this space, but realistically most products end up here quickly after achieving product-market fit and most features are built here as well. It is when a product is in this space that the company and organization are scaling and maximizing return on what was previously new/new. This can seem strange, but products can’t be new forever and there’s nothing wrong with that. What one needs to do is have a clear view of where investments are being made in R&D and how the organization overall is gearing up to build new things. If you’re simply adding depth or adjacent breadth to your existing product for your existing customers (or customer type) then this is where you categorize those investments. The most common mistake with continuing on old things in old ways is over-estimating the impact these product additions have on obtaining new customers or retaining customers.
When your product is established and maturing but a new implementation approaches or experiences start to catch on, there’s a strong desire to keep trying to do new features and implement new scenarios while continuing to use existing architectural approaches.
New things / Old ways — Repurpose. When your product is established and maturing but a new implementation approaches or experiences start to catch on in the broad market, there’s a strong desire to keep trying to do new features and implement new scenarios while continuing to use existing implementations.
An example of this is how Google continues its focus of browsing on phones when so much of the experience (touch, interaction, etc.) is superior when using apps.
Many on-prem server products attempted to add features like cross-company collaboration or mobile access to server implementations but quickly found the ability to add these next generation features on top of an on-prem, firewalled server was not possible. In general, much of the hybrid cloud or private cloud worlds are where the hope is you can be “cloud-like” while still running things in your own data center or trying to stick to standing up servers and managing them yourselves. Just as importantly, the idea is you can be “new” but by changing very little even though the new architectures arose to solve specific problems.
The idea of building mobile apps that reuse the web site/browser implementation is very much in line with this notion of doing new things (a mobile app) in old ways (using a framework that hoists the script into a client app). While tools and languages don’t know much about the platform, once the frameworks you use make those assumptions you are risking doing things in old ways.
The early days of the internet when client-based software tried to add internet connectivity features are good examples of this such as online banking in Quicken that to this day remains fragile, especially compared to a modern mobile banking app.
The appeal of this type of solution is very high with product development though because of the perceived ability to leverage skills and experiences to build new features. In many ways, trying to do new things in old ways is like someone wearing clothes just a bit too young. Doing new things old ways is almost always the incumbent approach to a startup.
One of my favorite negative examples of this is the addition of ActiveX to Internet Explorer. In this case a legacy technology that was highly popular in one old domain, client/server Windows apps, was integrated and applied to an entirely new domain, the browser. The result was a highly unsatisfactory user experience as the metaphors were just jumbled combined with an unsatisfactory architecture. Ultimately the real impact was that for all the comfort that developers (at Microsoft and elsewhere) had with this approach, the applications were just “off” relative to where native web apps were going. In the enterprise world, where change happens more slowly, the early adopters were severely penalized by their investments and took a decade to unwind with more native applications. While ActiveX was not so great, it is worth noting that many powerful, existing, companies approached the browser as a place to host their “old” strategic assets. Adobe’s Flash was one of those and no “take-down” of old versus new was ever better than Steve Jobs’ Thoughts on Flash.
The appeal of old things done in new ways is always high with customers in the enterprise.
Old things / New ways — Redo. Whereas the appeal of doing new things using existing technology approaches is high with the development team (who won’t need to learn new technologies and can preserve their knowledge), the appeal of old things done in new ways is always high with customers in the enterprise. Customers see a big advantage in not having to worry about the suitability of a product for the organization, since they’ve already established that. Instead what buyers (or IT) can focus on is how the product takes their company into a more modern architecture while minimizing churn, retraining, testing and so on.
The most common examples of this approach are porting apps to new environments (eg from VM to containers, or hoisting a server VM to the cloud) or what we’ve seen with many on-prem companies moving to “off-prem” cloud services. When taking this approach, the bet is that there is immense value in the experience and feature set of a product and those looking at the same “category” with a new implementation will be focused on copying existing features. This bet also presumes that the porting is not lossy—will the product still have the old capabilities and will the new product blend effectively in the new environment. For example, porting server products to the cloud does not usually get the scale-out performance one might expect.
The key warning sign for customers, that as mentioned really tend to love this approach, is that it delays inevitable architecture transitions. These solutions are almost always a hedge at worst or a bridge at best. If you’re not sure of a platform transition then don’t do anything. If you want to spend the time building a bridge and thinking it will be smooth, consider how much better off it would be to do nothing for a while and commit to a full transition later when things have shaken out. Customers that look for bridges invariable end up moving from bridge to bridge always a step behind.
What is interesting about this is how the economics can be easily conflated with the technology or architectural shift. In a previous post Competing With BigCo: 2018 Edition (sorry for the self-citation), I talked about how Adobe “transitioned to the cloud” when in practice the vast majority of Creative Suite is exactly the same as “before cloud” for their customers except for the task of license management. In this case the old/new economics were far more demonstrable than the old/new experience or technology.
A postitive example would be how Office 365 shifted the IT buyer experience significantly by hosting Exchange and allowing IT to get out of the very expensive business of managing servers, data centers, and buying crazy things like SANs. In this case, the user experience remains unchanged, but the IT user experience is dramatically improved and thus justified the migration (for new end-user functionality). The rest of the Office suite remains very much the same for end-users making this an ideal candidate for old-new. The important work, unseen, is whether the costs and complexity pulled back into Microsoft will allow for ongoing innovation and generally keeping up with what a new/new approach (as in Gmail) can accomplish — scale, flexibility operating costs, and so on. We might see this demonstrated if the rumored Google collaborative software makes its way to the market.
Execution Risk, Market Uncertainty
As you’re settling on characterizing the work (or proposed work) you want to evaluate the risk (ability to execute) or the uncertainty (what you can’t know until you put the product in customer hands).
Marco Iansiti at Harvard Business School once taught me, innovation = invention + impact.
Not surprisingly there is risk and uncertainty for each of these worth noting:
Why is this so tricky? Because almost nothing we use is entirely new,an invention. Facebook was not the first social network. Instagram wasn’t the first way to share photos. Google wasn’t the first search engine with ads or ad network. Windows wasn’t the first graphical OS. Word, Excel and more were hardly the first productivity tools in those categories.
Yet those products were all very innovative. Innovative products are a portfolio of new and old that lead to creative solutions. Marco Iansiti at Harvard Business School once taught me, innovation = invention + impact. The impact can be to solve new problems, changing market perspectives on categories, or causing customers to consider new ways to use technology.
Importance
As you’re reading this you were probably considering many past efforts and trying to categorize them in this framework. The general bias is to think of how things are new, though in reality most products have a mix of new and old features and architectures. The role of leadership is to make sure that the mix reflects a long-term strategy while meeting short term market needs.
The framework is important in forcing leadership to confront the R&D investments being made relative to long term goals. Most every team I have ever been part of would, absent pushing a new/new agenda, would tend to keep doing what they are doing — adding more features in the same vectors as they were done previously. This goes for startups as well as leading incumbents.
The momentum in thinking about how to innovate on a team is closely tied to existing features/scenarios and architectures. We often joke that eventually every product will share photos or add messaging, and while that is a joke you can look around and also see this happening. It is because those “new things” get added to the “old way” of doing things pretty regularly. The reality is that most always these types of features get ignored by current users because they don’t see your product as a place for that experience.
Perhaps the biggest value of this framework is to catch yourself trying to get too much out of existing architectures and technologies that are no longer relevant in a new environment.
A very interesting example in this regard is looking at how G-Suite (Google Docs, Sheets, Slides) chose to compete with Microsoft Office. The initial releases were very much an “old things, new ways” approach — that is take the existing Office scenarios and modules (even menu structure of File, Edit, View, Insert…) and just move those to the browser. In fact, this had previously been tried and failed with Java Office as well. The problem was that they could never do all the old things and the new way while marginally or potientially interesting, was not enough to switch. As G-Suite expanded with more collaboration features the product started to look more like new things done in new ways and thus created a wedge to compete with Office. But still for many people, the primary lens of the product remained doing the same type of work as Office, but just less capable. Thus the opening for Office 365 to offer its view of old things done in new ways aimed at the administrator.
This type of dynamic is playing out in the cloud space in spades as there are many new services and companies coming out all the time that either compete with more entrenched cloud companies (“head on”) or are trying to displace on-prem products by being “less” but at least in the cloud. There are some pretty big headwinds for these companies as a result. The importance of knowing what you do that is new and improved needs be a big part of why you exist, and just being implemented differently isn’t enough. While the new technologies and platforms might offer new things to do, does your product truly exploit those advantages? That’s really the key. Yes you can be self-service or always up to date (things on-prem vendors keep improving), but are you enabling cross-enterprise, better security, easier integrations, better ability to report and analyze large data sets, etc.?
Customers won’t be standing still with their legacy products and someone will always be there doing more in new ways than those products.
Perhaps the biggest value of this framework is to catch yourself trying to get too much out of existing architectures and technologies that are no longer relevant in a new environment.
Every product has a long tail but trying to intentionally extend the tail by bolting on new scenarios has proven a limiting strategy for both the product team and customers. For the team, the constant fight with an old architecture limits both the time and creative energy put into doing new things. For customers, while there is short term comfort in either stable products for end-users or maintaining a stable infrastructure, these moves tend to be time consuming and expensive and yet you end up with little by way of modern products or modern architecture. Any wins will be short term at best.
In managing R&D efforts I found thinking about investments as a portfolio of old and new, across both features and implementation. It is never a simple subject because at the core this is about a changing landscape — the technology underpinnings and platforms are changing while at the same time customer needs are changing.
