By guest author Tony Scott
The Phases of Outsourcing: The Value of IP vs. Productization
Tony: That’s great, but isn’t a company’s core IP still really important?
Anand: To give some context here about your IP question, what I find is that with many of the small startups, you’ll find two or three founders who have some great idea and they have built a prototype. Let’s say they have some great algorithm to improve linear programming by 20%. They go to a VC, and the VC will find the idea interesting, but these three people are PhDs; they don’t understand testing, quality assurance (QA), support, integration, and so forth. You can make a list of all the things that they have to do from the time they get funded until they go live, and 70% of the activities have nothing to do with the IP of their product, absolutely nothing to do with it. The failures of product companies are typically not in their algorithm or IP – that’s been already validated. The risk that somebody is taking is that the algorithm or IP cannot be brought to the market as a product.
Tony: That’s right – I’ve seen so many companies around the world with great IP or a great idea that failed because they never get productization right. Sometimes they might get the first demo product or basic product out, but they fail miserably on ever getting any future versions out on time and with the level of quality demanded by the market.
Anand: The productization process is actually quite complex, and most founders underestimate it. You have to figure out what tools to use for QA, what kind of test analysis you need, how you manage all those things, how do you run a daily regression . . . it’s just a whole bunch of planning that you need to do. That’s the piece that we focus on. I don’t go to a startup and say, “I know your linear programming algorithm better than you do.” All I say is, I just need to know enough about the algorithm so I can test it – I don’t need to know any details about the algorithm. I clearly need to know what linear programming is, and I need to know what the inputs and what the outputs are, but beyond that it’s my job to take care of all of the things related to turning the algorithm into a solid product that works from a software perspective. That means that you can focus on whatever you need to figure out for your linear programming algorithm.
The value of the IP portion of a product is highly overrated by most companies. One of the challenges that most American companies have – and this is even more true in Europe than in America – is that over the past ten to fifteen years they have not hired as many junior people into their companies. So they have these people who have very deep experience, but they have an unrealistic perception of what their value is in terms of what they are doing. It seems like whenever I go to a discussion people will tell me, “Oh, this product code is so complex, we’ve been working on it for the past 15 years, this guy has been here 10 years and he has a PhD. How can you fix bugs?”
The reality is that I have been fixing bugs routinely for companies with very complex code – and we use fresh grads to fix bugs. You need a process to fix bugs. It’s not like you have to know everything about the code. I can find a bug, find the problem, tell you exactly where the problem is, and 70% to 90% of the time, it is pretty obvious how to fix it. There are at most 25% to 30% of the cases that you have to deal with where you need the PhD who’s been there ten years to fix it – and I can send those cases back. That means that I can improve the efficiency of the process significantly by using people who are simply following a systematic way of getting to the problem and solving it in the majority of cases. We are able to do this consistently with customers all over the world.