The role of the product organization is to consistently deliver significant new value to the business through continuous product innovation.  At a startup, the product team either innovates and provides real value or the startup dies.  However, in larger, more established companies, product teams very often lose their ability to deliver that ongoing value. They just make minor optimizations to existing products. Or they continue to turn out more features that don’t make a difference.

In this article I want to talk about some of the deep reasons why innovation is stifled at so many established companies.

Hopefully everyone understands that in technology companies, continuous innovation is not an option.  As Reid Hoffman says, “A business that isn’t investing in tomorrow, is a business that’s already in the process of dying.”

I have already written about some of the causes of this.  The case I see quite frequently is after the founding CEO leaves.  However, I am not the first person to observe and write about the lack of innovation at larger companies.  In particular, there are two people that I think have contributed in meaningful ways to this discussion.

The first person is Ben Horowitz.  Ben uses the analogy of war time vs. peace time.  We focus on scale and execution during times of peace, but once we encounter serious threats to our business from changing technology, evolving markets, and emerging competitors, this requires a war time mindset and a relentless focus on continuous innovation.   I have witnessed many established companies that are clearly in war time but continue to behave as if in peace time.

The second person is Steve Blank.  He has written at length about these problems, and highlighted how most established companies focus exclusively on issues of scale and execution, at the expense of continuous innovation.  “Every time another execution process is added, corporate innovation dies a little more.”  Nobody is suggesting that focusing on scale and execution is not important.  In fact, I spend a good deal of my time helping teams in the midst of rapid growth with issues of scale and execution.  But the mechanisms to scale and execute can be perceived as at odds with the techniques for true innovation.  And every product, no matter how great, has a lifespan and if you’re not continuously innovating then it’s only a matter of time.

I see the problems that Steve and Ben describe far too often, and I consider them root causes.  However, in this article I’d like to try to add to this discussion another root cause, one that I don’t see talked about, but may in fact be even more profound and insidious in the negative impact on the company and disruptive innovation.

I call this problem “IT Mindset.”

I first witnessed this many years ago when I was an engineer for HP, building platform and tool technology products for “the enterprise.”  We were big practitioners of what we now call Customer Development, and our customer was typically the IT organization of large companies.

I remember being immediately struck by how different we designed and built technology, versus how our customers did.  I quickly learned that one difference was that these people rarely created commercial products.  They used our technology to create internal applications purpose-built for their business.  They were building solutions for their co-workers, needed to run their business, and we were building solutions for paying customers – this was our business.

It took me several years before I had strong opinions about the way they built software, but I quickly saw the behaviors and especially the consequences.  But that difference, while significant, seemed a poor excuse for the way in which they built software.

In any case, the Internet happened.  Now there were literally thousands of organizations that were newly tasked with building solutions not just for their co-workers, but also for their customers.  The issues that were irritations for enterprises, all of the sudden became business continuity issues.

I still encounter many companies today, especially companies that pre-date the Internet, that exhibit these very same behaviors and consequences.  I’ve written about the symptoms (see http://www.svpg.com/epic-waste) and I’ve talked about how to apply modern techniques in established companies (see http://www.svpg.com/moving-from-an-it-to-a-product-organization/ and  http://www.svpg.com/product-discovery-in-established-companies/).

Even if your company does not pre-date the Internet, you may have been infected with this problem.  The main way I’ve seen this happen is that your tech company grows and gets some traction and gets some serious funding, and the company wants to hire some “big guns” to come in and take this company to the next level.  But the “big gun” they bring in is rarely coming from a tech leader, they are all to often coming from a large pre-Internet company – a big bank, or a big retailer, or a big entertainment company, or a consumer package goods company – and of course the first thing they want to do is to put in place the ways of working from their prior company.

What I’d like to do here is shine a light on the actual problematic behaviors and differences, with the hope of inspiring established companies to take a hard look at their organization, their culture and their process, and hopefully start on the path to true continuous innovation:

1) Purpose.  In an IT mindset organization, the staff exists to service the perceived technology needs of “the business.”  In a technology-enabled product organization, the staff exists to service the needs of your customers, within the constraints of the business.  This is a profound and far-reaching difference.  Most of what is below stems from this difference.

2) Passion.  In an IT mindset organization, product and tech are mercenaries.  There is little to no product passion.  They are there to build whatever.  In a product organization, product and tech are missionaries.  They have joined the organization because they care about the mission and helping customers solve real problems.

3) Requirements.  In an IT mindset organization, requirements are “gathered” from stakeholders, prioritized in the form of roadmaps, and implemented.  In a product organization, we must discover the necessary product to be built.  Moreover, we know that most ideas will not work with customers the way we might hope, and we also know that those that do work will require several iterations to achieve the necessary business results.  IT mindset methods are simply too slow, too expensive and generate far too much waste (see http://www.svpg.com/the-inconvenient-truth-about-product/).  Moreover, we also know that more often than not, the technology enables the solution as much as the solution driving the technology (see http://www.svpg.com/the-end-of-requirements/).

4) Staffing.  The IT mindset shows up very visibly in the staff and the roles.  The lack of true product managers (especially strong product managers), the lack of true interaction designers, the prevalence of old-style project management, engineers unfamiliar with the demands of scale and performance, the existence of old-style business analysts, and heavy use of outsourcing, are all clear examples of this.  I would argue the most telling manifestation of the IT mindset problem is that the product managers in IT mindset companies are typically very weak, and at true product companies they are necessarily very strong (see http://www.svpg.com/the-product-manager-contribution/).

5) Funding.  In IT mindset companies you find them still funding projects (output) rather than product teams measured by business results (outcome).   There are many serious problems with this antiquated model, and it generates all kinds of bad behavior in the organization as they try to work around the constraints of this system, but most importantly, it results in very poor ROI for the company because of the very high cost of finding out which ideas work and which don’t.

6) Process.  In IT mindset companies, you usually find very slow, heavy, Waterfall processes, even when the engineers consider themselves Agile.  The only part that would be considered Agile would be at the tail end of build, test and release.  Much of this stems from the Funding issue above, but deciding what areas to invest in, staffing a team, defining and designing the solution, and release planning are all typically very Waterfall.  Technology-enabled product organizations simply must move much faster, and work differently, in order to deliver the necessary solutions for our customers and our business.

7) Silos.  In IT mindset companies, people align by function, creating silos between the different areas of the business, product, user experience design, engineering, QA and site operations.  In contrast, in a product organization, we depend on true collaboration between product, user experience design, technology and the business units.  In a product organization we optimize for product teams, not for the individual functions.

8) Organization.  In IT mindset companies, engineering is often under a CIO, and “product” (if it exists at all) is often under marketing or absorbed directly in the business units themselves.  In product organizations, there’s a big difference between the engineers that support “true IT” and those that work on the commercial products,  The True IT engineers usually report to the CIO, and the commercial product engineers report to a CTO.  Similarly, product is not a sub-function of marketing.  It is a top-level activity on par with marketing and technology.  It is not so much the org chart that matters here, as much as a recognition that the way we manage True IT work is very different than how we manage commercial product efforts.

9) Accountability.  In IT mindset companies, accountability frankly is a farce.  The people actually working on a project typically have no real say in what they are building, and sometimes even in how it’s built, and even when it’s due.  In theory, the leadership team could try to hold the requesting stakeholders accountable for the results, but if they do they immediately hear complaints that they didn’t get what they actually wanted, and because of delays and costs, critical things had to get cut, and so it’s certainly not their fault.  So management writes it off as yet another failed technology initiative.  In contrast, in a product organization, we are measured by results.

10) Leadership.  As with so many things, much of this boils down to leadership.  In IT mindset companies, the technology is viewed as a necessary evil.  It is a source of fear more than a source of inspiration.  Leadership in IT mindset companies is always looking for a silver bullet when it comes to technology.  Maybe they should outsource the whole mess?  Or maybe they can acquire someone else that hopefully has a better track record than they do.   In contrast, in a product company, technology enables and powers the business.  It is embraced and valued.  The people that create the technology are respected as the key contributors they are.  Leadership in a commercial product company understands that it’s their job to create the culture and environment necessary to nurture continuous innovation.

Nobody should believe that true innovation is only possible in startups.  Companies like Apple, Google, Facebook, Amazon, and Netflix are great examples of large commercial product companies that have proven their ability to consistently innovate.

As has always been the case, some established companies will thrive, and others won’t.  It’s worth acknowledging that established companies that stop innovating don’t usually die overnight.  They can live usually off their brand for potentially several years.  But it’s also important to recognize that many of the forces that today can propel good companies to very rapid growth, are the same ones that can accelerate its demise.

Which leads us back to the critical need for your product and technology organization to deliver continuous innovation for your company.

Share This