Prior to my current role, I spent 25 years working in the federal contracting space. Almost all technology built in that world is one-off and designed for the specific needs of a customer. Often, those needs are complex and meeting them involves creating new technology. “Productizing” a solution is common trope around the Beltway among integrators of all sizes. Most of the time, attempts to do this never get past the whiteboard stage and those that do invariably fail to become anything the wider technology market would recognize as a product.
In my current role, I happen to work for a company that actually succeeded in turning a solution it built to support its original services-based business into a thriving software-as-a-service (SaaS) product. While this represents an anecdotal and statistically-insignificant sample of one, it has helped me understand the differences between successful products and those solutions that never quite get there. I also happen to manage the portfolio of SaaS platforms my company uses for its own operations, so I’ve had a good chance to observe commonalities among many products and contrast them with the solutions in the previous phase of my career.
The differences have really boiled down to two key factors but, before delving into them, I need to define some terms that I have thrown around liberally in this post. They are:
Services – These are generally actions performed to deliver value to a customer. There is rarely a defined product or solution that is the focus of the activity. There could be outputs such as reports, presentations, or analytics but they are exactly that: outputs. The customer has procured the service itself, not any specific concrete leave-behind.
Solutions – Solutions, as I use the term, are generally technological systems that are built for a customer to solve a specific problem. A whole lot of services go into them, but the customer is expecting a durable system that will keeping functioning to meeting their needs long after the services are over. The solution may need some ongoing care and feeding, but the level of needed labor is expected to ramp down after delivery. Solutions tend to be unique and one-off. They are most likely integrations of various off-the-shelf tools, but those integrations are tailored to a specific need. The ability for a solution to scale beyond the needs of the current customer, or its ability to serve the needs of others is generally not a requirement.
Products – Products are technological systems that are built to anticipate or serve the needs of a class of customers – otherwise known as a market. There may or may not be an initial specific customer. The genesis of the idea for a product can come from a number of places, but it is designed to appeal to and meet the needs of a number of potential customers who have yet to be acquired. Those users generally expect a product to “just work” so the product needs to be fairly bullet-proof and not require much laborious care and feeding. That is generally seen as a sign of immaturity and weakness. It is important to note that a product can be quite successful without being a 100% perfect fit for any single customer’s needs as long as it demonstrates significant value for most of its customers.
I won’t claim those definitions to be canonical, but they represent the logical framework in which I operate and they work pretty well for me. Your mileage may vary.
For the rest of this post, I’ll set aside services and focus on solutions and products. In my previous life, it was generally integrators who had built one or more solutions who attempt to transition them into products. I don’t know that I ever saw one successfully make the transition to a product as I now see it, which is a fairly high bar. Most often, they fell back into the realm of a “soft product” which existed to shorten the time-to-delivery of tailored solutions or reduce the cost of delivering services.
There are generally two aspects of a successful product that were commonly missed in the effort to “productize” solutions and neither of them are technical. Scalability and reliability are eminently solvable problems that shouldn’t stand in the way of any serious product effort. Two aspects that are most often neglected by solution providers are 1) product management and 2) sales. I’ll discuss them in that order.
Product Management
I am far from an expert in product management, but I am fortunate enough to work with an outstanding product management team and see how much work they put into our product. Atlassian has a definition of product management that I think works well:
“Product management is an organizational function that guides every step of a product’s lifecycle — from development to positioning and pricing — by focusing on the product and its customers first and foremost. To build the best possible product, product managers advocate for customers within the organization and make sure the voice of the market is heard and heeded.”
Going back to the above definition of a product, it is built to “anticipate or serve the needs of a class of customers.” It is the job of product management to understand the needs of that class of customers and deliver the product that best meets their needs. The engineering team will ultimately build the product, but it will do so based on the guidance of product management. There’s a strong overlap with marketing functions in terms of understanding the market, especially when you don’t have a lot of customers yet. It is the job of product management to take market data, customer feedback, best practices, and other information and synthesize them into a concept of a product that will appeal to the market. This is “product-market fit” and products that don’t have it will fail.
By the time a solution provider is thinking of productizing a solution, they’ve probably already generated a lot of revenue from their customer. That customer is probably also really happy with the solution. If those two things weren’t true, the solution provider probably wouldn’t be dreaming bigger. While these are good things, they are also seductive. They can appear to stand in for proper product management. A single happy customer with deep pockets is not a market. There is most likely not a second customer like them and your solution was highly tailored to that customer’s needs. Is there anyone else who needs what you’ve built? Is there anyone else who needs something similar to, slightly different from, but within reach of what you’ve built? Product management provides the answers to those questions.
The buyers of products don’t generally come to the door holding statements of work describing exactly what they want. Product management teases that out of the market, often imperfectly. Successful products invest a lot of resources into product management. Most solution providers fail to understand the required level of investment and don’t resource it accordingly, leading their product effort to falter.
My co-worker, Coleman McCormick, has forgotten more about product management than I’ll ever know and happens to be one of of the deepest thinkers I know on the topic. Check out his Substack to read more. He’s also great about linking to his influences so you’ll quickly be exposed to some of the best thought on this topic.
Sales
The SaaS/Product world has a lot of different schools of thought regarding sales, but I’m not going to get into any of that here. I plan to focus primarily on the approach taken by solution providers and product companies.
If you are a solution provider, especially in the Beltway sense, you are not doing sales, you are doing business development (BD). BD has longer cycles and takes more time to close. You spend a lot of time understanding which customers have been buying solutions similar to yours, who the incumbent providers are, and how to build or join teams to capture business with new customers, or expand business with current customers. When you close, the dollar figures tend to be quite large, but they are far less frequent. In federal BD especially, the funding cycles running according to a template: the new FY, 3QFY sweeps week, end-of-year money, etc. You can set your clock by the ebbs and flows of the funding tides.
There are certain BD qualities to product sales, but deal sizes can be smaller, more frequent, and on vastly shorter timelines. Product sales, in a lot of ways, is an extension of product management. If product management is about establishing product-market fit, sales is about establishing product-customer fit to close specific deals. In the product space, you sell what you have and help the customer understand how it provides value for them even if the fit is not 100%. In BD, you take more time to understand the details of the customers needs to craft a proposal to deliver something close to 100% of what they want.
When I was in the federal solutions world, I saw many traditional sales people flame out trying to perform BD. Conversely, I’ve watched successful product sales teams in action and it couldn’t be more different from BD in the solutions world. A solution provider who doesn’t understand that the sales process is nearly 100% different and tries to go to market with their BD team is destined to get outrun by professional product sales teams. If the solution provider plans to stay in the services world, that can mean incurring the cost of spinning up a second sales team, so it’s understandable why it is tempting to cut corners there, but going to market with the wrong sales process just increases headwinds for an aspiring product.
I have developed respect for successful sales people. It’s definitely not a life this world-class introvert could live, but the role they play is vital to any product organization. There are no appropriations or end-of-year money. The entire organization subsists on what sales brings in. As a result, I try to make sure they wait the least amount of time for anything they need from me. The entire ethos of a successful product sales organization is so different from solutions business development, that failure to understand it will be a failure to bring a product to market.
Wrapping Up
The last five years have been quite a learning experience and I continue to learn more. Sometimes I get to reflect on the differences between this sector of the tech industry and the one I left behind and this has been a key one of late. It’s really easy to underestimate the level of effort needed to bring a product to market. Underestimating the importance of product management and the difference in the sales process can make it nearly impossible for a product to succeed, even if it’s starting out as successful solution.
