One of the most difficult lessons to learn for an engineering services company is to specialize. We started out as a company that did embedded systems development. We stated it that way because we didn't want to miss work in any number of vertical applications. When our CEO pushed us into wireless devices as a specialty there was a lot of pushback from the engineers because we felt like we would be required to turn away work other than that. Instead what we found was that we got more work in that specialty as well as others and that we had more opportunity for reuse of IP because the projects were more closely related.
That situation really helps in terms of developing internal IP. The first customer in a vertical helps create the IP, but successive ones allow you to generalize it effectively. Eventually it can be developed to the point where it could become a turnkey product.
I agree, developing an IP with a vertically oriented company is the best option and off course the IP developer should not charge customer for the extra development needed to make the vertical application in a horizontal product.
But beyond financial development of an IP in collaboration with a vertically oriented company is crucial because then the IP has an opportunity to be used in a product. Selling IP for the first time is most crucial and the usage of your partner customer will become a very useful and convincing case study for future potential customers
Also in area like semiconductor it is very difficult to define the feature list, performance requriement of an IP without help of a customer. Hence it is always better to have a customer as a partner during IP development
What I found the best potential for IP development was with a vertically-oriented company, one that planned on using the developed IP for a very specific application. That generally leads to the least chance of conflicting business plans. The remaining conflict, however, is the extra development effort to turn that targeted vertical application into a horizontal product. It is unfair to do that on the customer's time, but that extra effort eats into the project margin. This has to be a conscious and dedicated effort by the contractor.
The business model will see a big success if the ASIC design services company can target system companies for their custom SoC development. But the issue is this will need deep domain expertise which typically the design services company lacking
Co development of IP in right sharing mode depends heavily on who is the partner. If the partner has capability of developing the IP itself then it is very tough for service provider to persue customer for right sharing. But if the customer does not have the capability then it becomes easier.
For example if an SoC company is customer of ASIC design services company then it will tough for the service company to share the right. But things may change if the customer is a system company who does not have any SoC design team in house.
@LarryM99, thanks for sharing your own experience. Pulling off miracles on sometimes impossible situations, I am sure, would not come cheap. however, I, too, see the potential conflict -- as you elaborated in your comment. Being a subcontractor, you can focus on your client's spec. But being a "partner" means that you have your own agenda to satisfy too. Let's see how this will work out.
I ran an embedded systems division of a services company back in the last big tech expansion. We worked strictly for fee, and we were not cheap. We also had a nearly 100% success rate on very cutting-edge products (we built a tablet computer for a spinoff from Xerox in the mid-1990's). Many of our competitors were sharing equity with their customers in the hope of cashing in, and my comment to them was generally "I hope it works out for you".
My problem with that model is that it complicates things. IP negotiations rarely are easy, and if the contractor does not bring significant IP of their own to the table then they have to explain to a customer why they should pay twice for a design that they end up not owning outright. If the contractor does want to develop IP of their own, they have to allocate resources to develop and maintain that IP out of an internal IR&D budget. That can be deceptively expensive and problematic.
I also have a philosophic concern. When I am building a system to the client's specification I can concentrate on what best serves their needs. If I am trying to mold it into something that I might be able to reuse for future clients then I am trying to serve two masters, and one or both will suffer.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.