Looking back on SaaS product strategy
ghiculescu.substack.com
ghiculescu.substack.com
I'd love to hear how folks here handle this. What systems have you used to decide that either did or did not work?
Where I am, we built things into our product for one of our three largest enterprise customers that no one else uses. And some of that work isn't aligned with the core product and strategy.
Yet, the contract with that customer is among our largest and also covers that customer's other usage that IS aligned with our core product.
I joined the company in the year after that contract closed. I look back at the decision (that I didn't make) and think that it completely distracted the company and product (and still does, just less).
But in that moment, would I have said no that particular non-aligned use-case, and potentially walked away from the $? We're talking about a $1M+ annual deal. I don't know!
At the end of the day you are presumably doing all of this to turn a profit. Not to uphold some arbitrary ideology regarding what a perfect product and perfect customer should look like.
We used to look at "custom" code like some kind of awful thing (aka avoid on principle at any cost to us). At the financial scale we were operating at, it totally didn't make sense. However, as we started to gain traction and bigger customers started looking, the notion of maintaining a code pile per client started to make more sense. We even have some prospects with their own development staff who would be interested in assuming full ownership of product and source once we bootstrap it for them.
My line in the sand is a million dollars annually, with a term no shorter than 3 years. If the customer can afford to pay more than this, then I think custom could be in the cards. Otherwise, I would push them into our standardized product offering. We've got a few prospects in this bucket today, but most are under the standardized offering.
If you squint hard enough, much of SaaS is really just a big consulting package. The software is a shiny distraction to keep everyone participating. We only want to use just the right amount of software. No more, no less. The business can be much easier to change than the code in many cases. Sometimes back office processes completely evaporate when you get 2 employees together who have never met before.
Another way to frame it is to be upfront about development costs for custom features and bake it into the contract. A few ways I've managed to do this in the past:
If the feature seems like it will benefit all customers, but is not a priority, push back on timeline. Otherwise, validate with other customers and try to get multiple customers interested and/or on the hook financially to fund the work.
If the feature seems like it may be will benefit some other customers but is not a high priority, then you offer the customer the ability to partially fund the development and work closely as a partner to accelerate building to spec.
If the feature seems like it might never be applicable for other customers, my preferred approach is to say no, with an alternative proposal of building something jointly (i.e. we will consult for you to help you build this on our platform) while facilitating their ability to build the thing through whatever means (API improvements, examples, etc.). This always comes at a substantial markup over SaaS sticker price.
Basically, unless you were going to do it anyways, get funding for it, and even if you were going to do it, try and get funding for it anyways. Mature organizations are used to this game and won't be shy to discuss options.
The only caveat is when you openly advertise something in development or on a feature roadmap, it becomes much harder to lobby a customer to fund it. I usually advise founders to stick to table stakes features for the roadmap, like SSO. A savvy mature customer will have a purchasing team that actually reads your website to find opportunities to out negotiate you.
What a great paragraph and overall reply. Thank you. I really like the bit about shiny software in particular. Also, the quick point otherwise about arbitrary ideology. At the end of the day, a lot of us are not building products driven by some serious human/moral/emotional mission. Instead, they're fairly ordinary enterprise (or other) SaaS products. So - ok to take the money too.
But at the same time I agree if we don't build it, we won't have customers and unfortunately keeping/geetting new customers is not exact science.
In the end important part is to get rid of stuff that was build for big fish customer once they stop being customer because it keeps living in code base and after years no one remembers why that stuff is still there.
Read that as "unfortunately keep getting new customers" and all I could think of is clerks.
"This job would be great if it wasn't for the customers"
Is this just gatekeeping?