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!
> the contract with that customer is among our largest
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.
>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.
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.
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.
This is a great read — appreciate the valley of “phase 2: too many things to prioritize” which is where I see most product teams get stuck - trying to over-index on being data-driven, or on MRR targets…
The indie hacker approach to this is constantly develop, deploy and monitor. If the feature is used, improve it. If the feature is unsuccessfully used, improve it. If the feature isn't used, kill it. This is heavily data-driven and requires intuition for users' desires (what they want, how they want it) and your product. The latter takes years to learn.
When working for companies the development process is longer and requires input from multiple stakeholders outside of the development team, e.g. product manager, project manager, copy writes. There is a substantial analysis before starting the development. As an independent hacker (indie hacker) you don't have those resources but instead increased agility and speed.
As a developer I dislike "build all things even if they don't neatly fit in the system". I would like product people to come up with features that fit in and are thought out. It makes my work harder :)
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.
It’s definitely not an exact science! As a developer I feel the same, and as we matured it did slowly get easier to be more precise about what’s worth building.
It’s not clear how the product team decides work to be done. The article jumps from data driven decisions not working to OKR’s that would apply once a product direction is set. Would be great to get some clarification
It's actually the reverse. The product direction is dictated by the goal (OKR). Our objective is to increase engagement from management which we know we are accomplishing by hitting the key result of admin users increasing average usage from y to x. From there a product team can generate ideas or prioritize ideas that fit the mold.
This is terrific. I loved the presentation of trying different approaches successively, and I think you nail the nuance of several early product stages that often get rolled together.
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!