Many startups historically have made a name for themselves building “as needed” custom applications for customers. Many have served customer needs providing a strategic business application that other like companies would find tremendous value in having as well. These custom “ideas” have the potential to help increase revenues for customers and or save costs for their customers often in the $$ millions.
However, these custom built solutions, although attractive to a large portion of the market, are still considered a project, a solution (not a product….yet).
Many Startups who have had a smash success with one “productize-able” customization often see a tremendous opportunity to turn their boutique Services Firm into having a product “arm” that would drive revenues through these repeatable solutions they would productize. Some feel this could be their ticket to becoming a full-fledged legitimate “product company”.
One would say that “overnight” a product company was born from what was started originally as an application development “services” shop.
However, does this transformation from a “services” company to now a “product company” happen overnight? Not exactly….. If you have read down this far, you know there is a lot more involved in this process. So let’s deep dive a bit…
As you will notice, the characteristics are widely different when comparing a “services” firm to a “product” shop.
Characteristics of services firms
- Maximizing the billable hour
- Having high resource utilization
- Driving customer perceptions, margin, and linearity
Characteristics of product firms
- Drive Innovation, cutting edge technology
- Focus on speed and time to market
- Write quality well-written software
- An architecture that is scalable while ensuring product readiness, design, and repeatability
And of course, commercial success, margin, etc.
Take stock in your people immediately
DNA of a product developer versus a project (application) developer. In the short story above, many “project” application developers find comfort being on projects, billing hourly and are focused on project timelines for their customers. In this current role, the services application developer is not typically concerned with product packaging, market readiness across multiple customers, integration into an Industry Platform and general design of a product. However, these latter details are the very details all critical to building a product and a product company.
Not recognizing this situation as you “cross the chasm” could lead to huge spend unnecessarily.
The turning point: Examine your people strategy first
- Should you hire “product” people and ramp them up instead of going all the way down the path with your “lead developer” who you started the company with?
- Perhaps leveraging that lead developer in a more strategic role while advising the product people? There are many “people” factors to consider and costs associated with this.
- Don’t take shortcuts. Do your homework as your cost structure will change.
- Market sizing and analysis, and viability analysis. Most startup come up with ideas from previous projects and while that might be a great idea for that one customer, this may not be it for a broader market. Building a product needs to have appeal to larger set of people. Market segmentation has an impact on pricing.
- The bank account. Raising rates or lowering labor costs may have worked in the services world within reason (as far as what the client could absorb). But in the product business world, you need to realize that profitability may not be within reach for some time (possibly even years). Brace yourself for that new reality.
- Map out your scenario. Are there new costs associated with the build out of the product? Have you factored in potential deployment models and pricing? Your idea might be brilliant but it won’t stand up long if you don’t have a full and complete picture on how you will be monetizing on your product.
The fine art of selling
Selling/commercial attractiveness is a must for obvious reasons. There might be a beautiful product that was built however you may not have the sales staff or sales knowledge in house that understands the intricacy of selling in this “new” paradigm of the product world. If there is a legacy staff, they’ve been used to a level of flexibility and scope of work which could be adjusted in services sales. In a product world, it’s a different story where specific pain points need to be addressed. It’s binary. It either solves the problem or it doesn’t.
While it seems challenging, remember that it is not impossible. What is important is to be realistic and plan for the transition. If you are in the middle of a scenario like this, do reflect on all the details with a proper look at your people, skills/talents, and finances.
In Part II, we will examine the commercial side.
Please follow me @jamespiacentino on Twitter