At one point in my consulting practice I was engaged on assignments with two new client companies. Both of them had businesses selling to large, blue chip customers. Customers of the size that are used to “having it their way”. As a result, for these companies to get deals with customers of this stature they often feel the need to provide a lot of customization. This is a very common scenario, especially with young companies that are desperate for a key deal of this type–or even any kind of deal at all. The interesting thing about my two clients was how they perceived and approached that need to customize very differently. This is a story of emphasis: system integration vs. product development.
A Tale of Two Software Companies
Company A viewed customization somewhat as a pain and distraction, something to be controlled–I assisted them with creating a standard solution menu outlining the “Base” offering, with a list of options available at an added cost. They really wanted to discourage certain customization requests, absolutely wouldn’t do some things that were asked and wanted to make sure that they charged dearly for items that they found painful. They had the classic mentality of a product company; they wanted to do the minimum amount of customization necessary to make a large sale to this important class of enterprise customer–but NO more than they have to.
Company B, which also considered itself a product company had a very different mentality about customization. They welcomed it, prided themselves on it and positioned themselves to these potential large clients as someone that could quickly bring solutions to the client, fully customized to their desires. They really had a classic system integration mentality and wanted their reps to be scouring the big accounts for unique pain points or opportunities which might fall within the company’s core capabilities, enabling them to then propose a customized solution which would win the business. In fact, up till the point which I engaged with them their product development approach had really been to find out what individual accounts want–and build it for them.
So which of these two business models is the best way for software and hardware technology companies to adopt?
System Integration Focused Business Models
Advantages:
*More flexible and able to change with shifts in the marketplace
*Not as capital-intensive due to less “betting” on upfront product development
*Easier to grow business organically with internally-generated capital than in a classic tech product business
*Less risk due to lower upfront investments
Disadvantages:
*More competition; system integration is a more competitive, “easier-entry” business
*Generally lower operating margins than a standard software or hardware product business which reaches scale in their market
*Growth is less scalable than a product-oriented technology company
Product-Focused Business Models
Advantages:
*Provides greater opportunity for strategic advantage and resulting fast growth
*Less competition if a strong product/brand/technology differential advantage is created
*Can scale a tech business much quicker if a hit product is developed
*Higher operating margins if a standard hardware or software product is successful
*Usually more marketing-driven and less labor-intensive
*If creating a very large company is the goal, it’s much easier to raise outside capital for a tech product company
Disadvantages:
*Much greater risk of “crib death”, often resulting in complete capital loss if the initial product has problems in development or marketing
*Harder to “get over the hump”; standard product success is harder to come by and success often happens as a step function after a difficult startup period
I want to emphasize that there isn’t necessarily a “wrong” approach with either the product or system integration oriented business models. You can make a lot of money pursuing either model. Both of the companies I have used as examples have managed to attract blue chip customer which would be the envy of any company. What we are really talking about here are the operating and financial difference between a classic product-driven technology company and a system integrator.
Company A is that classic product-driven company. They customize when they have to, but also have a point where they will say “no”.
Company B also self-identifies itself as a product company and in fact they have built their business around a small number of standard offerings. But they really are utilizing relationships as well as the ability to react very quickly to customer requests as their core strategic advantage, plus the ability to customize beyond what classic standard product companies (especially larger ones) want to or are willing to do. They’ve built a very nice business doing this, but have some frustrations as well. They are highly dependent upon a small number of major accounts for virtually all of their revenue and have the major revenue/profit swings that are associated with this type of business–up one year, back down the next. They also are in constant fear that a larger company will come along and “take away” their marketplace, because they’ve continuously failed to create strong new standard products to build upon a core offering – which is very dated technologically. The core offering is long-in-the-tooth and appears very vulnerable. This company is very account-focused (and therefore reactive rather than proactive) and the resulting lack of a market focus has kept them from being able to create additional, broadly marketable products which could provide them with a strong proprietary advantage (the lack of which causes a lack of sleep at night!)
Company A understands who they are and what they want. That doesn’t guarantee success, but it makes it much easier to build a plan that everyone agrees on. At that point success or failure usually depends upon execution, unless the plan is awful. If failure is the end result in this scenario – more times than not, unfortunately – the problem is in execution. Company B’s biggest problem is that they are floating right in the middle between the two business models. They are trying to leverage both product and system integration business models and struggling with execution as a result, on both the product and systems integration side.
SUMMARY
It isn’t impossible to combine these two business models successfully. I’m sure that many of you can point to several examples of such a very successful compromise. In fact, most successful B2B technology companies combine both of these models to some extent, with good success. But I find that usually a company identifies its business model primarily as a product company or a systems integrator. That identification drives their strategic focus and takes precedence when prioritizing the use of always scarce assets.
When combining these business models successfully, the secondary of the two models is usually utilized on an opportunistic basis. Product companies integrate and customize as needed to get a big deal. Integrators create “products” to fill the needs of a big account, and sometimes happily find they are salable to other accounts. Occasionally, these “products” prove so widely salable that they are spun off into a separate product company, or the integrator changes its focus into becoming a full-blown standard product company as its strategic focus.
The most important thing, in my opinion, is to understand who you are, where your strengths lie and what you are trying to accomplish strategically. It’s the companies that are trying to equally leverage both business models at once – somewhat schizophrenically – without one model taking the lead, that get themselves in a heap of trouble. That’s my opinion on Systems Integration and Product Development–what’s yours?
Follow Phil Morettini and Morettini on Management via Twitter, Facebook, LinkedIn, RSS, or the PJM Consulting Quarterly Newsletter. Contact Phil directly at info@pjmconsult.com
If you liked this post please share it with you colleagues using the “share” buttons below:
That was a great article on product innovation, appreciate the insights you gave.
Very thought provoking, Phil. I plan to share with our management group. As you indicate, the best practices probably lie somewhere in the middle, not being married to an old technology, but not being blown with the wind chasing every perceived opportunity.
Thanks for the comments, Len.
How timely it is for us to receive this analysis. We are struggling with this issue. We are Company A in our heads but we recognize the value in having Company B characteristics, and we also know the client has a lot of good insight. I try to see the middle ground as this: not to think of their requests it as customization suggestions, but rather further innovation and refinement opportunities. Our challenge is respond to “custom” requests but effectively integrating them into our core capabilities that leave us not just with a sale, but also a more capable and compelling product for future customers. Thanks Phil!
Very interesting article and an area that I have personally managed both scenarios. I have just left an assigment where I was the GM for two independant industrial product businesses that were both a part of a large industrial firm. In my case, company A was a small to medium size business that had a strong reputation as a product business, we focused our efforts within two market segments and only a few products that we strongly pushed. We were able to ride the increase within the automotive segment and the natural gas segment with dramatic increases in top line revenue and margin. My company B was a very small bussiness that was not so much a system integrator but we custom designed components in form, fit and function for each of our OEM accounts. For this business growth was slow and unpredictable but profitability was very high and consistent YOY. We were taking the best from each business unit and learning.
According to me, the business model which a company should apply on depends on the state of the company. While I was working with a product start-up, our aim was to create a good product. We built a prototype of our offering and starting pitching to clients. As clients showed interest we built the product understanding what is core offering and the rest for customization. As more and more clients came in, the customization part is too much to handle for a small team. So gradually we added new features into the core product which are mostly sought out by clients. Thus our core product offering became strong and level of customization decreased than what we used to do before. It may sound ironic to put each feet in one boat, but that is how business houses are run and the one who manages both without losing focus on either stands by as an example.
GREAT Article Phil,
I wonder what would be your perspective in the case of a company that design and manufacture turnkey systems per order integrating many off the shelf subsystems.
If along the way they decide to create a line of standard product so that to create a more predictable stream of revenue, how challenging this could be and what strategies should be used to conciliate these two highly distinct business model?
Thanks again,
Wlamir Mello
Hi Wlamir,
Thanks for your comments. Unfortunately there is no simple answer to your question–there are definitely challenges in doing this, but lot’s of product companies start this way (and many more fail). The devil is in the details here and I would hesitate to comment given the potential complexities of the situation. This discussion is definitely beyond the scope of a comment field.
Interesting article.
I’d like to see more discussion of the benefits of creating a platform vs. a product: enabling (and then incentivizing) an ecosystem of partners and ISVs to do the “last mile” development rather than company B doing the customization work in-house.
It certainly means a greater emphasis on exposing APIs, but that doesn’t have to (and indeed shouldn’t) be an after-thought when architecting software.
Kean, I actually did recently write on that topic: https://www.pjmconsult.com/index.php/2015/03/platforms-applications-software-market-lifecycle.html, although it probably doesn’t have the emphasis you’re looking for.