With the modern complicated landscape of technical product development, we often see business’ spending their hard earned budget on solving technical problems that aren’t core to the businesses value. Not only does this increase your development risk, but it is likely an inefficient path to maximising your intellectual property growth. Optimising your development strategy for the lowest risk and highest value-add to your business is incredibly challenging. This is especially so for product development in today’s fast changing technology landscape, but it is essential to product and business success.
It is essential to spend time understanding how your business and products provide value to the customer. If you’re spending money developing a technology component that isn’t fundamental to the product value (future IP) or fundamental to your companies strengths (existing IP) then evaluate if there is another way. For instance, Can we buy this piece off another business or partner with them? Can we buy a business that does this? Can we employ someone who has done this? Do we actually need this at all?
Even if buying technology seems more expensive than developing it yourself, it is often available much sooner in the development process, which lets you integrate your systems earlier, test prototypes with your customers earlier, and focus resource on your own value-adding IP. Even if it seems to be an easy technology to develop yourself, but it is not a core skill, be mindful of estimation errors and overconfidence. One technique to counter this is to review how past project estimations fared. Often a simple time-is-money calculation is all that is needed to favour a credit-card purchase over an internal development.
It is not always easy to identify where the technology development risks are, or even which parts of a product should be the focus of the business. Having a business development strategy in place will really help here. Determine what you’re good at, why your customers buy your products, and where the business is going. Then you can dissect the technologies in your new development projects and ask why are we doing this piece ourselves?