7 Ways to Avoid Your Product Company Becoming a Services Company!

Product companies (especially those focused on the Enterprise) always face pressures, primarily that of cash flow in the earlier years, forcing them to take on more services components. This is especially true in countries like India where angel and venture investments are not as plentiful as in Silicon Valley. This is a trap that product companies will find it difficult to emerge from once they get into it.

Just to be clear – there is nothing wrong in being a services company! In many ways, it has better cash flow profiles in the earlier years enabling companies to ramp up with additional people and “projects”. But, you may not be able to make progress on your product vision, unfortunately!

How do you avoid this situation? Here are 7 ways you can avoid this trap:

1. Stick to your Vision, Test and Pivot: As we learn more about Lean Startups, one of the best ways to avoid becoming a services company is to make sure that your product is needed, clients will pay for it and you can build a company on it! You talk to potential clients before you build the product. Even then, you build only a Minimum Viable Product (MVP), roll it out and test your hypotheses by getting to revenues. If revenues are minimal or non-existent, you pivot and build something that someone will pay money for, and soon!

2. Build Features Based on How many Users Ask For Them:  In one of our enterprise product companies, we had a simple rule – If one client asks for it, it goes into the backlog list. If two clients ask for it, it goes into the next major release. If three clients ask for it, it goes into the next sprint!

3. Turn Custom Components into Product Features if you can: Try not to build components for any one client. Parameterize the client’s requirement into a more general idea and make what they are asking for, a specific case of that! For example, if they require your product to work with a certain brand of a reporting tool, think of how you can generalize it so that it can work with most reporting tools. You may need to build additional components but it will be worth it when the next client needs your product to work with another brand of a reporting tool!

4. Line up Services Partners Early:  Large product companies deliberately price their professional services much higher than their service partner ecosystem does. For example, if you were to source Oracle product expertise from Oracle, it will be an order of magnitude more expensive than obtaining it from a service partner of theirs. That’s how they prevent themselves from being sucked into spending too much time on services and away from their products. For small product companies this may be difficult to do, but if you find service partners who are also service partners for related products, they may be interested. It will involve sharing your revenues but that’s the tradeoff!

5. Line up Product Partners Early:  Products have natural boundaries and it’s good to recognize them early on and bring in product partners that do those things better. For example, if your product addresses a specific vertical with a core solution, line up product partners for related needs like reporting, social media integration, telephony integration, etc. You cannot be everything to your clients and identifying related product partners early on will help you avoid the trap of reinventing all related wheels all over again! Of course, you need to architect your product in such a way that it can easily integrate with other solutions!

6. Refuse Non-Core Competency Opportunities:  This is easy to say but tough to follow in real-life if you are a product startup. If a client offers you money to do a related thing but not quite what you were hoping to sell, you may need to refuse it! But that’s exactly what a product startup needs to do to stay true to its vision. If three clients ask for this other thing, that’s a Pivot! Take it and go forward!

7. Plan ahead for Cash Flow Pressures: Product companies are not for the faint hearted! Do not embark on even writing one line of code before you talk to potential prospects about your ideas, show them sketches of what you were thinking about, and finding out what they are willing to spend for such a solution. If you are already well into having two or three clients and it is a case of scaling, you may need to pivot to products that could scale up better, faster.

It pays well to remember that with product companies the goal is to write code once, get paid many times. With services companies, you write code once, you get paid once! Very rarely do you get to write code and retain the Intellectual Property that is general, and can quickly be sold to other clients, unless you subsidize the initial development substantially!

Again, there is nothing wrong with being a services company. It has its plusses and minuses, but without paying attention to strategy, proper architecture and partners, you could end up becoming a services company when you want to go the other way!

I already am a product – Lady Gaga

About the author

Nari Kannan
  • dude

    1. How would one ensure cash flow. Sometimes isn’t it wise to keep a service component as a cash cow to build the long haul product route.
    2. In places like India, there hardly exists any eco system partners.

    • viju

      Totally agree with the points above. In early 2010, as a startup company (zintrus) in the data protection (crowded) space targeted at SMB (not enterprise!) market, we were not able to pique VC interest. The fact that indian startup eco system was also evolving didn’t help. We took up engineering services to bootstrap ourselves and managed to launch our product and demonstrate the traction. However, the product development stretched a bit as our focus and energies did get divided. Another key point here is that we consciously decided to dis-engaged from our services business once the product gained traction. From our experience, this is definitely not an approach which I would recommend strongly. But if you believe that there is a strong differentiated (“classical new market” or “low end market” disruption) value and if it could be validated to a reasonable extent, then go ahead and do it. As the popular adage goes, you cannot do unreasonable things by being reasonable!! 🙂

  • Nari Kannan

    Great questions! Absolutely the pressures you face trying to build a product company in India. The trap you will fall into is that the more service components you take on, you will not have time to do any of the product stuff. Then you join the hordes of services companies, will start competing on price and then you will be back in less cash situations anyway! Regarding lack of eco system partners, that is also true. That’s another reason to target global customers and clients from day 1! Product companies will not be successful just because you are passionate and don’t think about all these other issues ahead of time.

    • dude

      1. How would one have access to knowledge in any vertical for global markets. Unfortunately Made in India is not yet “made for the world.

      2. What is wrong in a hybrid model. 40% services as cash cow to feed product initiatives and market development.

      3. Is your article posting more for the “Enterprise” world 🙂

  • sridhar

    The author makes valid points, points based on facts. However, the paradigm has shifted and I am not sure, the approach recommended is relevant. Here is why I think so –
    Product is about IP one creates that addresses an explicit market requirement or a latent need that the entrepreneur discovers or intuits upon. At its core it is an idea that has a ”working model” to demonstrate value – a better something. Product is about developing the idea and packaging it for use. The path varies depending on which market – enterprise or consumer and accordingly its architecture that addresses personalization, customization, integrates with other products or services and so on. Branding and pricing, marketing strategies, distribution all get defined by that market choice – who, where, etc.

    All this ‘product’ can be delivered or distributed either as a service or shrink wrapped. For a product company to be offering services is a business choice, like I described above. The issue with ‘traditional software services’ is that it was a people dependent model and was linear in growth. But the opportunity for a non linear, repeatable model, where in the first services contract you build 100%, in the next you reduce by 20% (e.g. user authentication, or some server side stuff) and so on. My experience and own research tells me that one can reuse upto 80% by restricting fresh code in a project to 20%. I agree you cant generalize on this, and it doesnt apply to every situation and perhaps only fits SaaS models. But I have made it work in a Cloud based architecture (loosely coupled front end that connects to a common, multi-tenant backend as a service via the 20% custom business logic or application layer).

    To come back to our discussion, several emerging technologies, a product company with a services mindset maybe a more efficient way to address IT requirements of a business with more flexibility, and most importantly offering better value – guaranteed superior features and performance at a lower price – be it a subscription model or a one time fees. Reuse of code lies within the realm of the architecture of the product irrespective of the business model. And lastly, this is where Open Source software helps win. Redhat and others have demonstrated how this can be successful. The product is essentially free. The services around it earn the revenue year on year, and in a manner that suits both the client and product vendor. Further, every new connector written or new feature added in a project that is a result of a new requirement, provided it is generic, it can be ploughed back into the core product. So, why will client agree? It depends only on how the product company defines it contract in this case. We have done it and it is very simple – every service will have 2 kinds of IP – one that is exclusive to the client, the other non-exclusive leaving you the product developer to reuse.

    Just as services industry needs to move away from linear direct people in a project model, similarly, product companies too should try non-license approaches.

  • narikannan

    Sridhar – May be this model works in your particular case. Would be curious to see how it scales as you service more and more clients. That’s where the problem comes to the fore!

  • Nari,

    Well said. I love the anecdotes and specific examples you have used – how to respond when 1 customer asks, what to do when 2 ask, and when there are 3 inquiries. I think the other axis in Lean as well as Services delivery is the TIME axis. Besides re usability the reason for products to seek a premium is higher quality in shorter time. Incidentally this is a double edged sword, if you can reduce turnaround time through own strength or partner network, you can accelerate traction and turn it into Revenues and profits. Starting the wheel the right way often requires greater customer, market and financial access.

    Ankur Lal
    Ankur@infozech.com

  • raj

    Nari: Often the issue of whether ‘product companies’ should be in the services business gets decided by the funding situation. Products require significant upfront investment and often imply losses for many early years. Services are usually profitable in Year 1 (unless the company bungles the value proposition, pricing or utilization). Its easy to say that product companies should not be in the services business. However if the company does not have the funding lined up to sustain the upfront investment, it has to look to services to generate the cash flow and profits.