R&D: The Good, The Bad and The Ugly
Research and Development. R&D. Most of us have heard this phrase without paying much attention to it. As a matter of fact, most of us work in R&D. But what do these two terms mean? And more importantly, what is the implication of doing research versus doing development on your company's bottom line?
Research is an activity that has always fascinated me. Systematically investigating problems to increase your understanding and knowledge. If it weren't for research, I wouldn't be working from a home office through a VPN connection, and you certainly wouldn't be reading this article over the Internet. But putting my personal interests aside, how much research should your organization do? And how much should be spent on development?
If you're a small company hoping for an eventual IPO or eager to be acquired through an M&A deal, you should focus on development and let other organizations such as universities and government-sponsored agencies perform research. Research, especially basic research, will not make you successful overnight. Actually, it may not make you successful this decennial.
Because research in and of itself does not produce a commercially viable product, smaller companies struggling to reach profitability or break even shouldn't invest too much time on it. You should instead focus on development; building solutions to solve your customer's needs.
Generally speaking, the market doesn't compensate organizations that can't bring a solution to their problems. The high tech industry is not a horse-shoe game. You don't get points for coming close to the pin. You only get compensated if you hit the pin – and you better be the first to hit it, or hit it better than any of your competitors! Otherwise, you may as well not play.
Take the Internet. Known as ARPANET, it was brought online in 1969 under a contract let by the Advanced Research Projects Agency (ARPA). It took almost 30 years before the mass market could start benefiting from the Internet. Do you think investors would have kept financing a start up for 30 years hoping their research might eventually result in a commercial product? Not likely.
If you can't communicate to investors a solution to a specific, well-defined problem, you are doomed! You will not be able to find the cash necessary to sustain your company.
Certainly, there were periods where investors would have funded you. The .com bubble of the 90's was certainly immune to this principle. And I'm positive that we will see other bubbles at some point in the future. But of the .com companies that didn't solve any real business problems, how many are still around?
If your corporate objectives are financial ones, keep these two principles in mind:
- Define a specific problem.
- Solve this problem by applying the 80/20 rule. Spend 80% or more of your effort on development, and 20% or less on research.
That being said, trying to solve a problem that requires a lot of innovation doesn't necessarily mean you're destined for failure. But keep the following guidelines in mind when managing your resources and project risk.
Hire Experts. Not understanding how to solve a problem sometimes means not having the right people on board. Try do understand which skills your company needs and hire subject matter experts.
Find a Customer With Deep Pockets. Find a customer who believes in your solution and who is willing to support you financially before your product is commercially ready. While you're not in a position to be picky, try to attract a customer who shares your vision. A partnership based on organizations with diverging visions rarely amounts to victory.
Delay Part of your Research. Certainly you're not starting from scratch across the board. There must be at least part of the solution that can be implemented immediately. Make sure the development of those components are well staffed, and delay some of your research to a subsequent release.
Reuse External Code. Your solution doesn't need to be entirely built in-house. Investigate third party applications and open-source components to see if it makes sense to re-use them as part of your overall solution. Reusing external code can sometimes be extremely efficient and beneficial, especially when it solves an area that is not critical to your competitive advantage.
Manage Risk. Admit that your project is risky. Build a project schedule and adopt a development lifecycle suited for high-risk projects. Do not attempt to follow the waterfall model.
The warnings and advice of this article mostly apply to start ups and/or smaller companies with limited funds. Obviously, the Microsoft's and IBM's of the world aren't going to suffer too much if one of their smaller projects doesn't become a successful commercial product overnight. But for those of you who can't afford to fail, follow these guidelines. Stick to the 80/20 rule, and focus your effort on development rather than research. And for those of you whose main corporate objective is not a financial one, enjoy your research.
This article was originally published on www.gantthead.com.