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.
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.
2 thoughts on “The Allure of Selling Product over Services”
This is really an inspiring and educating tale. As a Records Management Consultant and Advisor to a software development firm, a number of your insights ring true. To come through with a really terrific product takes teamwork and also a lot of luck and devotion. I don’t think many people realize what a major endeavor development is and I thank you for pointing it out.
You bring up a great point in regards to how solutions for customers can become software products. At TSG, for our software products, we initially struggled with differentiating between product and consulting. When does the solution become a product and how do you price it and sell it without it seeming like a veiled consulting offering? FirstDocs comes to mind as a solution that requires consulting from CSC. While the first client might be happy to offer up the solution for productizing (hoping that they will get the enhancements from later clients)that second client, that realizes they are purchasing with hard dollars a product but also consulting services to enhance it, might wonder what they are getting for their purchase price.
We also struggled with the relationship issues. Let’s face it, software sales reps (think Oracle), don’t have the best relationship with clients when they are pushing for quarterly quota. We didn’t want to ruin our consulting engagements by being too aggressive on software sales and pricing.
Our solution was to go Open Source with everything. The relationship improves as the client is getting something to start with for free but understands if they need to hire (or develop themselves) any enhancements to the product. Products evolve based on customer needs rather than engineering picking new features.
Comments are closed.