Why In-Company Incubators Aren't Working… Yet (Part 3)

(Part 3 of 3)

In this three-part series, I'm addressing the topic of why in-house incubators don't necessarily work, and specifically answering the question about whether organizations should entrust innovation to their entire organization or just to an elite team, incubator style.  The answer is, it depends on where your organization is in the three-part innovation process.

In my first post I explained this concept, and covered the first phase, Ideation.  A few days ago I covered the second phase, Validation.  Today, I'll tackle the one that seems to be most comfortable for enterprises and startups, and yet also the failure point for  many of them: Execution.

Once your idea has been validated, it's time to start thinking of bringing that idea to market like building business. Here is where a lot of organizations make the mistake of putting the nascent product or service in a current business unit and letting them run with it. After all, now that it's a product with a defined market, you should just treat it like every other product in your portfolio, right?

Well, sort of.

Sometimes, your new innovation will inherently play by a new set of rules, a set that doesn't apply to your existing products.  These new rules need to be identified and dealt with -- through permissions, process, skill sets, etc -- as the innovation is developed and delivered.

To explain this more clearly, I'll offer a story from my own experience, when I was at PeopleSoft managing the eProcurement product. There definitely was a market (thanks to Ariba and CommerceOne), and there was traction in the growing number of customers that we had. However, there was a lot of catching up to do with what the market expected, but we were constrained by product development processes designed for maintaing something like Accounts Payable and General Ledger in a 12-18 month product cycle, while our more nimble competitors were able to ship in less than half that time. It felt like we were competing with the proverbial one hand tied behind our back.

To get around our constraints, we had to break the rules and ship new functionality when we weren't' supposed to (long-time customers may recall version 8.0 SP2) and make PeopleTools dance in ways it wasn't designed. I credit the engineering team and the creativity of their manager, MJ Guru (now at Workday) for making this all work. He had just enough of a rebellious edge to make it work without getting fired.

The lesson here is that this innovative product had to iterate and add functionality faster than our more mature products like AP and GL. It also was a new kind of solution for PeopleSoft - one meant for all employees to use without training, not just people in the back office. It was different, and playing by the rules set by a more mature product line would have killed the product if it weren't for the team that wanted it to succeed.

Of course, every new product can't require a new organization to be created. It wouldn't work. What companies should consider doing is creating some sort of "half-way house" for products that are still in the early stage to allow them to iterate quickly for the first year or two. Just because you have traction and have validated the solution does not mean that you have a complete product and are finished learning. Far from it. In fact, from my experience, the amount of learning grows exponentially as you get more customers and start receiving more pointed feedback from people using your product every day.

In the end, every product and solution has its development "supply chain" and its point on its lifecycle in addition to having an affinity to other products that have the same economic buyer and market. For companies looking to launch new products and become innovative, it's not only about coming up with the next great idea, but also knowing how to make it work with the organization that you have.