A few weeks ago, Peter Monks asked the twitterverse the following question:

Does anyone else think that services companies claiming to be product companies is weird? Seems like a rather difficult pivot to execute.

I agreed that it was a difficult pivot but that it wasn’t weird. In fact, I did it once. Ten years ago, when I was with Infodata System, I transitioned from a consultant to a Product Manager for about two years. My team took the results of a consulting engagement and created the AnnoDoc product. It was an annotation tool, similar to the current Documentum PDF Annotation tool, but with less overhead.

Why did we do it? How did we do it? Why were we successful? Let’s dive in and look.

Show Me The Money

In a consulting company, there are a lot of unknowns, mostly stemming from determining where the next contract is coming from. You are always investing in sales activities in order to try and minimize the amount of time consultants spend between projects. If there are any issues, and their always are eventually, you may have quality resources on the bench. That costs money.

After a while, you are faced with the prospect of letting the resource go or losing money. If you let them go you can save money, but then you have staffing problems and hiring replacements later is an expense you would like to avoid.

Of course, this can be handled by charging higher rates, getting longer-term contracts, and, of course, being bigger. Even with all that, it only takes one recession to cause problems.

A constant stream of revenue from a product is seductive. Operations and Maintenance (O&M) fees regularly coming into the coffers can stabilize revenue and new license fees bring in nice boosts.

This is why I don’t think it is weird. The lower-risk revenue is hard to ignore and a steady O&M revenue stream goes a long way in covering costs. If you can grow the product to a large enough install-base, your steady O&M income more than covers the product costs and license revenue can be used to cover those annoying consulting variations.

Heck if it grows enough, you can even consider getting out of consulting.

How it Starts

It starts with a simple consulting engagement. Someone realizes that the delivered solution is widely needed. Of course, this requires a contract that allows the code to be used later. Sometimes the client is promised transition to the product and free support if they release the code to the company.

Point being, eventually there is a baseline. The next step is to start to package it as a product. This is where many companies fall apart. They try to productize something that is, at best, a framework. Frameworks are great as they create repeatable solutions which can be extremely price competitive, but they still require consulting to deliver.

Even if it can be setup to be a true software product, there is a big difference to building a consulting deliverable and a product.

Stepping Up the Quality

I’ve actually talked about this to some degree in the past. When you are building a consulting deliverable, you strive to match the client’s environment to make sure that it works upon delivery. Simple.

With a product, you actually have to have as many environments as your long list of potential clients are likely to need. This requires a whole new level of testing and the infrastructure to support it.

Then there is the installation packaging for all the platforms.

Don’t forget the documentation.

Did you figure out how to support it?

What about translating it all into multiple languages? (trickier than it sounds)

Even then, you still haven’t started selling.

My Experience

I was successful 10 years ago. I had an excellent team (Mark, Mark, and Jie rocked), had some luck, and we timed it just right.  The advent of Documentum’s RightSite the previous year had essentially deprecated the annotation capability that required a local (fat) client. We had experience developing Adobe plugins and Documentum solutions, so we wrote a solution for a client that worked in a web-based environment.

From memory, here is what happened:

• When the engagement was almost over, I was assigned to it to manage it.
• It was designed it to be able to read legacy Documentum annotations.
• We started selling it to the pharma industry. We found our customer number two.
• Client two (love them) was patient as we worked to not only make it more robust, but to work in their completely different environment, which included WDK 1.0.
• We (mostly our CTO Noel) convinced Documentum to resell it to stop their clients from being upset that their annotation tool didn’t work in the world of the web.
• We found two more companies to package it as part of their vertical solutions.

Did I mention luck? I had three companies selling it in addition to my own. They were able to provide great feedback on features from their diverse client base.

Somehow I was able to get our QA setup in such a manner that we could support every Documentum supported environment.

Of course, the company was then ruined by new management that thought they could

• Grow the install base faster just by hiring new sales people.
• Convert the entire company to a product company
• Ignore the consulting side

They eventually sold everything off to two separate companies, a consulting company for the contracts and a product company for the product collection.

That’s okay. My team and I knew what we built. We knew that we had successfully crossed the line into product and were profitable. It was great…

But it was a LOT of work.