Idea in brief

Making products out of projects is always a point of discussion in the software services firms. I have identified 8 major challenges and proposed their solutions.

It is generally after 5-10 years of starting a consulting career that we feel this need. Initially passion attracts the IT consultants into the field; you get a lot of exposures, broader view of different industries, a lot of travel opportunities and money rolling in. But, now you have kids, you have a family and you feel a need to have a life that insulates you from service demands. Rather than viewing it as products vs. services debate, we can set up a nimble system that takes care of our pet projects that we want to turn into products.

There are some recurring problems that I have seen when services firms try to productize their projects. The major problems are:

• Lower risk appetite
• Inadequate market research
• Tracking bench cost & ignoring product KPIs
• Cash flow problems
• Lack of dedicated capital
• Lack of product-oriented sales and marketing
• Putting the wrong person as product manager
• Technical lead

I have also identified some action points that can help successfully turn projects into products.

1. Lower risk appetite

Product firms have greater risk appetite compared to the services firms. Consulting is a low-risk field. You have the project tightly scoped out, you have the requirement documents that the client has sent, and you have the man hours calculated before you start a project. What worst can happen?

A product’s destiny hangs in consumers’ hands and this is a risky business. You may fail spectacularly. This prevents consulting firms from giving their full (or even half) to the product development needs. They think it better to have a $40k project than to sell a $200 security or migration utility (which is fine to think but not when you think product comes to you naturally). They find it difficult to envision the benefit of productizing or think it is a process beyond their capabilities.

Action points:

• Rather than diving all out in the product frenzy, services firms can use internal products in either of the three ways
  • Products as a service sales machine
  • Products as a key differentiator
  • Products as a gross margin bump

Mark Suster has extensively written about these three strategies to help aid in selling services.

2. Sales & Marketing not oriented towards selling products

Mark Suster of GRP Partners writes that “consultants mistake their successes in selling services as a competency in selling products”. Regarding his experience of building internal software products at Anderson Consulting, Suster says that “We over-spec’d products. We built for our over-intellectual selves”.

An IT consulting firm’s sales and marketing function is not geared towards selling products. Beware, if it’s no one’s job to market or sell the product, it’s quite possible that in a roomful of consultants, no one has the skill set either.

The sales people in a typical IT consulting firm have technology as the yardstick to identify prospects and nurture them. A sales or business developer for a Microsoft partner will look for customers interested in BizTalk, SharePoint, Dynamics, or HDInsight. For the salesperson at an IBM partner, it is all about selling InfoSphere, Cognos, and SPSS.

This is not so for the product firm. A product salesperson will touch every industry vertical that can be a potential buyer of the product, essentially adopting a problem-solution path.

Action points:

• Website: You do websites for your clients, whether they are WordPress or SharePoint sites. Do one for your own product. Or put up your next one at the Office Store, Google Apps for Work or AppExchange.
• Prospecting: Hire an independent contractor (1099s) and hand him/her over with the target persona. Build a list of prospects that you want to talk/contact.

3. Inadequate market research

A consulting firm recognizes a recurring problem for which the practice lead is getting queries from the customers. This is usually deemed enough to start building a product.

In the product development world, getting customers/prospects to actually show interest in a solution is a necessary condition for developing the product but not sufficient. Doing a decent idea screening is a time-consuming activity. However, it is not billable.

Consultants think that doing market research for your own product is apparently too much time that can otherwise be spent on building the product or completing the billable work.

At best it is assumed to be an expense that cannot be recovered and at worst a useless activity. Hence, the process is ignored.

Action points:

• If you’ve developed a SharePoint migration utility for a field services company, it does not mean your potential buyers are only in the field service industry. Develop an agile marketing research program for your product. The main goal should be to find the exact same type of people who bought your service.
• If you can do a PoC for the $40k project in six weeks and within $10k budget, why can’t you do the same for your own product? Develop a PoC and take it to the market for hands-on research.

4. Tracking bench cost instead of product KPIs

Consulting firms track the bench cost of resources. Popular thinking is to utilize the bench time as best as possible. Firms usually get the product developed (and sold) by utilizing the idle resources.

Whenever a new consulting gig lands, product resources are asked to prioritize project over the product. Product launch is delayed or proceeds at a snail’s pace, or in a manner contrary to the best practices of product development. There is rarely a dedicated team or product manager assigned to the product development. So, it never pays big time to have products developed and marketed by resources on the bench.

Action points:

• For any product, make a product team (may it be a two-person team)
• Allocate an estimated budget & time
• Set KPIs, establish new reporting rules and leave them alone

5. Cash flow

Another major difference between a consulting firm and a product firm is their cash flow cycle. A practice lead whose resource utilization falls below 70% is bound to raise questions. If a resource has not been billable for two months, the practice lead will be questioned. A team’s profitability is essentially gauged by the resource utilization rate.

On the contrary, product firms burn significant cash up front. They have a much higher Capex compared to a consulting business. Products remain unprofitable for six months and upwards and still the product firms bet their luck.

Action points:

• Dedicate 6 months of upfront Capex for the product development team. This includes R&D, development cost, sales and marketing and support services.
• Identify metrics that product teams use when they develop the product. Use product related metrics instead of services metrics such as resource utilization, margin, and leverage. For instance generic product KPIs are:
  • Customer acquisition cost (CAC)
  • Average revenue per user (ARPU)
  • Customer lifetime value (CLV)
  • Conversion & retention rate
  • Feature usage percentage

6. Not skillful at raising capital

Product firms or product managers are much better at raising the capital that they need for their product. They are better at packaging their product idea and selling it for investment purpose to a venture capitalist, an incubator, an angel investor or within friends and family. A product founder does not hesitate to paint a compelling product vision and campaign around influencers to get a buy-in for the idea. Services firms developing products are modest in claiming that “this is the product that will change the way people YADAYADAYADA” .You’ve got the point.

Action point

• Treat your next project based product as a start-up. Develop product pitch and raise capital from an internal sponsor, angel investors or F&F. When you start burning your own cash, you just become conservative with the S&M and User Experience aspects of your product.

7. Putting the wrong person as product manager

This is the person called the champion of your product, both internally and externally. Or you may call the P&L owner. This is the most vital part that any IT consulting firm must develop if it seriously thinks about developing products. There has to be a dedicated product manager who thinks and acts through the following tasks:

• Shield the technical team from slings & arrows of outrageous demands
• Customer development & market research
• Meeting/contacting potential customers and prospects, generating sales leads
• Bridges every department that touches the product including marketing, sales, engineering, QA, customer service, operations
• Oversees cash flow & Capex issues

8. Technical Lead

This is the person whom you may call the CTO (chief technology officer). The person is responsible for leading the software engineering side of the product. He is a person whose hands-on with the development and also capable of understanding the business side of product so that customer requirements/needs are incorporated in the next iteration.

Action points:

• Assign this role to a person who can get along well with the product manager, a lot will depend on product manager and technical lead
• Avoid doing it in a distracting manner in-between client projects, allow the technical lead to focus on the product

Conclusion

Let it be a reminder to kick start an internal debate at your firm. Can building products on the side and preventing it from distracting your shop from the main craft be managed? Start with the following checklist and you may end up with a list of to-dos better than the one I have put up.

• Treat your next project turned product as a start-up idea
• Prepare the start-up pitch (even for internal investors)
• Don’t ignore sales & marketing
• Shield the product team from client work & internal pessimism
• Raise capital (internally or externally) and give product a budget
• Develop risk appetite; there’s a tradeoff between immediate revenue & uncertain revenue
• Start prospecting for your next product the way a product firm does (across verticals, geography, and function)
• You can assign resources currently on the bench; don’t reassign them on a project once the product is halfway
• In a nutshell; treat the product as a client and do for your product all things that you do for a client (user interface polish, documentation, fixing those 200 bugs, installers, password-reset, S&M, project team)