Mo problems, mo money?
Startups, incumbents, and the need to reallocate budgets to accelerate innovation
Last week, I attended the Commercial Lines Innovation USA hybrid event hosted by Intelligent Insurer. The conference consisted of two days of virtual content online and one day of in-person networking in downtown Chicago. I moderated two panels on Day 1 featuring top executives from incumbent insurance brokers and carriers talking about the challenging market environment, while Day 3 primarily featured several presentations by insurtech startups as well as roundtable discussions.
Over the past several years I’ve been in leadership roles at two insurance carriers with teams reporting to me, budgets to spend, and a mandate to innovate. I haven’t counted the number of sales pitches I’ve seen over the past decade. Suffice it to say, it’s in the thousands at this point so I’ve come to be a bit inured to how great a given startup’s products or services are. However, leaving corporate life last fall has lessened the number of pitches I’ve been subjected to. Additionally, fewer in-person events has meant that when I now listen to pitches in person, I’m more focused than on Zoom calls with the distractions of e-mail notifications, texts, Slack, etc. As a result, I see pitches in a newer light today and have a few thoughts on incumbents, startups, and how to accelerate the pace of innovation within established firms.
Real problems and real solutions - what’s the catch?
In reflecting back upon the thousands of pitches I’ve seen over the years, three things stick out. First, rarely did I ever feel the problem(s) that a startup has identified and purported to solve weren’t really an issue for my company. It would be nice in deciding where to spend precious resources to easily dismiss the startup by saying, “you know, that’s not really a problem that we have here”. However, I can only think of a handful of times where either we truly didn’t have that problem or felt that our current solution set was superior to theirs. Certainly there were times where I would discuss with team members and subject matter experts and we would conclude that the problem wasn’t big enough to warrant further investigation. But in general, the problem(s) existed and potential improvements were worth looking at further.
Second, the solution(s) to solve the problem(s) developed by the startup at a high level appeared at first glance to be a clear improvement over the status quo. Again, in an initial pitch from a startup, I’m typically not at the point where I’m looking to poke holes in their story, find out what’s being left unsaid to help formulate a fuller picture, or talk with in-house experts to determine why this may or may not work. When scouting startups, I’ve developed a decent “B.S. meter” where I can detect whether a startup isn’t serious or is too early in their maturity to keep the conversation going. There is certainly a due diligence process that takes place with many steps and sign-offs, but I found that more and more startups were able to pass muster even after closer examination. As more venture capital funds are raised and more entrepreneurs gain experience and are emerging technologies such as AI develop, my sense personally is that the general level of maturity at startups has risen across the board. As a result, there are more viable solutions in the market today that genuinely reflect significant improvements over the status quo and will return a meaningful return on investment. In short, they are worthy of establishing a relationship.
Third, there is a gap that is largely unexplored: if startups have identified real problems and possess real solutions that are quantifiably better, why aren’t incumbents adopting startup solutions at scale? There are a myriad of reasons, some which are clear to me but others which are not. Some reasons include concerns with IT security and governance, lack of specific features or other desired customizations, and lack of available implementation resources such as necessary experts and skill sets due to competing priorities. For example, I’ve seen deals fall through due to the lack of qualified project managers even when the business is bought in and IT does not have any concerns. There are two barriers in particular that are worth highlighting because of how often they occur: 1) the lack of buy-in from the people who would be the primary users and beneficiaries of the new solution(s), and 2) the lack of budget available to purchase the new product(s) and service(s) from startups.
Beware of the “gate agent problem”
Perhaps the biggest challenge I have faced in leading innovation efforts is what I refer to as "the gate agent problem”. You likely have spoken to an airline gate agent in your life about an issue - checking in, inquiring about the status of a flight or seat upgrade, asking about the whereabouts of your luggage, etc. You have also likely noticed in passing that virtually all gate agents still rely on a “green screen” legacy system similar to the one pictured above. Why don’t airlines upgrade their systems and provide gate agents with a modern graphical user interface (GUI), with drop-down menus, radio buttons, and the like? A more modern system would have the added benefit of more easily rolling out new features and reducing training time for new hires who would prefer a more intuitive system that doesn’t rely on obscure transaction codes, tabbing from field to field, and knowledge of function keys.
There are likely a few reasons why these systems haven’t been upgraded, likely due to the significant cost as well as change management and inevitable bugs that could impact customer service. But one reason is because the current gate agents aren’t asking for a new system. Why? They know the current system well and can easily navigate it based on their years of experience and tacit knowledge of tips and tricks to optimize the experience. If the airlines introduced a new, modern system complete with a shiny new GUI, ironically it would slow the gate agents down - at least for a period while they became accustomed to the new system. So the users who would most benefit from a new solution aren’t advocating for it.
This leads into another critical point: too often, systems dictate processes - not the other way around. It’s one thing to whiteboard what the process should be, but another thing entirely to ask how the workflow can be improved given existing solutions. In the example above, if you ask current users to help design a better solution, they will struggle to completely re-imagine what is possible. Instead, they are likely to recommend incremental improvements to the current system, perhaps one or two areas that are particularly annoying or painful to them that would improve the current process. The reality is that older legacy systems aren’t easily modified or configurable, so changing them is costly and difficult. This experience clouds the view of more modern systems that are easier to change - but even so, all systems represent constraints that impose restrictions on processes.
Startups are not constrained by existing systems in their design and thinking, nor are they generally focused on the specific needs of an individual customer but rather build solutions that scale to a potentially large number of users. These “outside” solutions can provide significant advantages over the status quo, yet when innovation leaders ask subject matter experts (SMEs) that are closest to a particular role or type of work to help in the evaluation process, too often these individuals will focus on aspects that do not align with the current workflows and dismiss a new solution entirely. These well-meaning individuals will struggle to see their work from a broad perspective, re-imagining how their existing processes could be redesigned while still accomplishing their objectives.
As a leader seeking to spur innovation within your organization, you need to rely on the input of your SMEs to properly evaluation potential solutions being pitched by startups. After all, these are the prospective users and their buy-in is required. They are also likely to ask detailed questions that are crucial to fully assessing whether a new solution will in fact meet the needs of your firm and be a worthwhile investment. However, these individuals can also unwittingly limit innovation that unlocks huge benefits through narrow thinking that fails to go beyond the “as is” world to see how the “could be” world is superior. Note that I’m ascribing positive motives here: there are certainly concerns over technology like AI where workers feel that their jobs are threatened and thus may have more negative reasons for rejecting new solutions.
Rethinking “build vs. buy” decisions and budgets
While the nature of new solutions offered by startups varies considerably, increasingly many take the form of enterprise software-as-a-service (SaaS) products or other subscription-based forms that require little to no upfront expenses but rather an annual fee to be paid. One of the advantages of this model is that the process for firms to acquire such solutions tends to be more straightforward because the costs incurred are part of operational budgets, which usually have a lower threshold required for approval than capital expenditures. (Of course, there are trade-offs involved: operational expenses cannot be depreciated over time and are recognized fully in the year they are made from an accounting perspective for example.)
The significant investments that startups make in developing their solutions calls into question the age old “build vs. buy” dilemma. Many enterprises go through a decision framework weighing various factors in making these determinations, but increasingly in my view the question should be reframed as simply “why not buy?”. For most organizations outside of the technology space, their IT departments are largely set up as maintenance organizations; that is, they first and foremost focus on “keeping the trains running” and ensuring existing systems are in good working order, protected from external threats. Secondarily, they focus on additive contributions that fall into the “build” category, whether directly performing this work or supervising the development work of other partners whom they have contracted with to custom develop new solutions. In my experience, these endeavors typically run over time and budget, often by a significant factor, and they are of inferior quality - often because the additional features requested by users are not easily accommodated once a project is closed and expenses transition to the “operations & maintenance” category where smaller but still impactful improvements can get stuck in the prioritization queue.
Startups have an advantage in that their focus is exclusively on the products and services that they offer, they benefit from the feedback of a wider variety of customers (not just one), and they are continually improving their offerings as a result. Startups also are incentivized to provide the level of support and extras necessary such as a customer success team that can make the difference between a smooth deployment and a failed one. Most incumbent rollouts of new systems have only involved limited user training and change management efforts upon implementation, but are not part of an ongoing customer success team. Depending on the solutions offered, the startup can also be in the running to become the dominant player in the space, especially if there is some aspect of collecting data and training AI models that can translate to a lasting competitive advantage if done well (think of Google Search for example).
One thought experiment: what if your organization took the budget currently available for capital expenditures in building software and converted it into additional operational expenses instead? Departments would not have to wait months or years for “build” efforts to come to fruition and would likely save on human capital as well that were dedicated towards the project team. Each department could focus on finding and acquiring best-of-breed SaaS-based solutions offered by startups and established vendors. It would significantly speed up the payback period by buying, not building, and would also provide the benefit of diversification because multiple suppliers would be utilized in a “buy” world rather than relying on a single provider in a “build” world - your company.
This is an oversimplification to be sure and there are many factors that I’m not mentioning here worth considering. Managing external vendors requires a procurement department, legal team to review contracts, IT risk and governance reviews, etc. But I haven’t heard anyone argue for this approach, and I think this conceptual framework is worth having a robust discussion on within your organization. Challenge yourself: what is everything fell into the “buy” bucket - how would our organization be different? Would we be more agile and responsive to change? Could we significantly boost our innovation efforts? Does this allow us to address a wider range of opportunity areas by pushing more money to each area and empowering them to make decisions at a lower level than capital expenditures are made at? What are the downsides? What would we miss out on?
Instead of the famous “mo money, mo problems” challenge that the Notorious B.I.G. memorialized in the 1990s, I call this the “mo problems, mo money” challenge. By providing more money to operational budgets while cutting back on capital expenditures by an equivalent amount, you may find that your organization can significantly boost innovation efforts - by addressing more of the problem areas of the types that startups have identified and resolving them by acquiring their solutions.
What do you think is preventing more startups and incumbents from partnering to help accelerate innovation efforts? Should you adopt an “always buy” approach? When does “build” still make sense, if ever? Share your perspective in the comments section below.