From Custom Dev to SaaS — Why Is This So Hard?
Picture, if you will, a slider. Like the bass and treble controls on your mom and dad’s old hifi. On the left-hand side you have “customers telling me what to do and when to do it” and on the other you have “master of my own destiny.”
In growing your SaaS solution, you’re going to encounter the issue of customers who demand custom features. When you’re onboarding your first customers, you’re simply not positioned to say “no” at this stage in your growth. If you’re lucky, you can accommodate the request as part of your core product but, in some cases, you can’t. These requests become custom development items for the customer and, while they can be vital to building goodwill within your customer community, executing the conversation properly and managing long-term expectations must be done delicately — or you hurt the spell.
Managing Customer Expectations
To manage your customers’ expectations you’ll need high-caliber user engagement, but this isn’t news to you. So how is your support organization positioned in relation to your marketing/customer relationship management group? If you’ve got them siloed off from one another, your phone might be ringing. It’s the 80’s calling, and they want their organizational model back.
Your support org and your CRM group have got to move in lock-step, using metrics to gauge customer satisfaction and proactively engage customer stakeholders before crises emerge. Jon Solomon has some great points around this concept here. More on this another time.
Question: how is your support organization positioned in relation to your marketing/customer relationship management group? If you’ve got them siloed off from one another, your phone might be ringing. It’s the 80’s calling, and they want their organizational model back.
Your input will come from all touchpoints — support encounters, marketing/PR check-ups, chance run-ins at restaurants. Customers will tell you “I absolutely must have these features, or I can’t use the product. This is a top priority and I need it addressed ASAP, contract and SLA be damned.”
Defining the Problem Domain
If the customer’s got a business problem they’re trying to solve with your product using features not found in your product, that’s a pretty good sign they don’t fully understand the business problem. Get with SMEs closest to the issue and understand the problem space. Draw some lines around it. Recognize that, while every customer is the center of their own universe, capitulating to very request as a component of your core product will lead to a clunky, disjointed product. Make a hard decision.
Important Point:
The idea repository is a trap. In it are ideas that aren’t necessarily good ideas, nor are they really interesting from a core product standpoint, but you’re tempted to tag and bag them so that, just in case there’s some gold in that pile of awful ideas, you don’t forget them when you need them. It’s the same logic as the junk drawer in your kitchen.
But no one forgets great ideas; that’s why they’re great.
If Not Now, When?
If you’re growing a SaaS startup from a custom or ASP shop, you are either in, in for, or on the back end of a pivot from customer-driven to market-driven product development. You’ll have to get good at having difficult conversations around when customers can expect features.
Consider the idea of thematic development. This involves selecting features and enhancements within a certain piece of the product and executing them together. The basic idea is to focus efforts on impactful changes that users will notice. While consistent, incremental improvement is nice, burning up dev cycles on slight improvements that a few users here or there notice will generate customer satisfaction, not customer delight. The way to wow them is to make meaningful changes in the user experience that your entire customer community — or at least the large swath exposed to the changes — will notice and appreciate.
If you can consistently make time in your development roadmap for these themes, you’ll build trust within your customer community that their general enhancement items will get addressed, and it’ll relieve some of the pressure to see those changes right away. While customers are generally insistent that their major business pain points be addressed in short order, bright ideas for quality-of-life enhancements are deferable — if the customer has confidence that you’re listening.
Transparency and The Tyranny of the Majority
You’ve made the volitional shift to a product focus, and have stratified your backlog. Your sprints are loaded with roadmap projects, major customer pain points, and a few items that are part of an improvement theme in a particular area with substantial UX impact. You are now a player in your market, and the master of your own destiny.
Then, one day, you have to tell a customer “no.” And you’re good at this sort of thing — you’ve done a few Carnegie courses so your “no” is more like “yes,” and you open up to your customer; you let them know that their idea is great and has value but it has value to them and to them only, and that there will be some sort of fee involved for the customization, and that they may have some risk of forking from the core codebase, precluding the benefits of future updates to this section of the product, etc., etc. And your customer, who’s unaccustomed to hearing you say “no,” wants to dig in on this idea of “value to the market,” and “who decides if my idea has value to the market? Who is the market?”
And that’s when you know you’re in the pivot, experiencing the pain of steering your company from custom development to SaaS. You won’t always have good answers and that’s OK; but you do need to have your customers’ faith that you’re moving the industry forward, and then you need to be a good steward of that faith and move it forward. Because that’s why you started down this path in the first place, right? That’s the fun part.
