Meh. The company I'm at is in the exact same situation as the 'self serve' company described, taking the low end of the market while a larger company fails to do so. The way we approach enterprise is uncannily similar to the way they described the other company doing so: use our API which does the hard domain specific stuff. Except we're the opposite of self serve.
Virtually every customer pays us for technical support, and our developer (I'm effectively the only one), talks to customers practically every day about what they need in the product and to our services staff about their challenges. The insight this provides is invaluable.
Companies in the market with dozens/hundreds of developers are worse at deploying new features than we are with a single developer (yes, I write tests and use industry best practices for my stack, extra work up front, but development is waaaay faster years later). Think ViaWeb's Lisp advantage, except our real secret weapon is just that 1 developer who talks to all their customers and their services department is as good as 20 who don't (I'm using C#/Vue for web [with an erlang like actor framework I built] and C++/Lisp for embedded).
There are certainly challenges scaling, and dear lord am I underpaid (I'm more interested in autonomy than the 3x-10x money I'd get from moving to a competitor), but self serve is orthogonal to our customer appeal. (Others in the market might actually think we're self serve though, just because our software is user friendly and self serve is actually possible).
Wow, while reading this I was thinking to myself: "this person better be a co-founder!".
You obviously don't need any advice since you know what you want and you know what you're doing. But I couldn't help thinking - 10x-ing your pay gets you 9 years of complete autonomy for every year spent working.
Also, are there any quick insights you can share about using actor model with .Net? Did it shine, did it make some things harder then you thought they would be? Thanks!
I'll answer the last bit first (I have no other developers to talk to at work, so excuse me for the wall of text):
It's not exactly a traditional actor framework, so you might be a bit underwhelmed. It's single process (working on extending that, as we use P/Invoke, and a mistake there can completely crash the process; that said, hiding the details of distributed calls seems like a bad decision, so I'm still thinking about how to best approach this). Message passing is done through individual typed queues. Actors don't run when a message is received, but instead decide how often they should be run, and then poll for available messages from their queues (or just perform some timed action). Actors don't fail-fast so much as ensure proper logging and try again later (though parents may manually monitor and dispose their children).
The biggest flaw I see is that message passing involves locking, and while I've tried to abstract this away with 'MessageQueue' and 'Atom' primitives, a user could easily circumvent this or pass mutable data. While I could easily catch and correct this if we bring a new developer on board, if someone were to start using the framework with no guidance, I worry they would not 'fall into the pit of success'. Designing a language around the actor model allows you to solve these issues: https://www.ponylang.io/discover/#what-is-pony
I wouldn't say I'm proud of the framework's code. It could be better organized and more understandable (unfortunately, you can't use dependency injection when making the framework which does your dependency injection). What I am proud of is how simple and organized our main codebase is because of our use of the framework.
A new developer can simply create a file containing a class, mark it with an attribute, specify its dependencies as private fields (also marked with attributes), and then create new functionality independent of what everyone else is doing. Effectively, fences are drawn between independent portions of the codebase in the style of 'micro-services', except there's no need for separating into separate services until a bottleneck is introduced (so there are no pointless debugging nightmares).
I still have a lot of plans for building tooling around the framework: profiling, visualizations, monitoring, reporting to a centralized parent, inspection of running systems using reflection (remote inspection?), etc. I probably wouldn't recommend using it unless you're a brave soul. Maybe check in after a year or two and there will be something a bit more fleshed out.
Having said all that, the actor model is a natural fit in our problem space. Our software talks to dozens of types of mission critical systems and physical equipment, each of which has the potential to fail outside of our control. I think the actor model would have been a perfect match for our software regardless of language. That said, .NET's excellent reflection and the ability to dynamically compile lambdas made it possible for the actor paradigm to feel native. I think that there's a lot of untapped potential in .NET surrounding this (making frameworks for one's domain).
Regarding switching jobs:
You're not wrong. There are other factors I didn't mention though. 10xing my pay would put me at the pay level of a mid-range FAANG employee. The main issue is that I would either have to move to get this kind of pay, or do a large amount of traveling (depending on the role I took). I do not live in a software hub (I live in an aerospace manufacturing hub), and so there aren't a lot of options in the area. Additionally, I feel loyalty to our team, and my leaving would have a major negative impact on them (they'd need 3 people they couldn't afford to replace me). I'm happy to have a good job in the area that I (mostly) enjoy, and to be innovating in a B2B space which allows me to make a lot of people happy. Five years from now I may feel differently (or we'll have substantially increased my pay). I get a lot of job offers, and they'll probably still be there in 5 years.
At least one of the current owners wants to give me an ownership percentage, but I've told them to just keep increasing my pay as revenue increases instead. Most companies fail, typically from structural/organizational issues. I think ownership may be overrated. I could be wrong though. I think owning a piece of the company would feel more like the company owned me, and that I was stuck with it. Right now I feel like I'm choosing the company, and have the ability to easily leave if needed. Not 100% rational, but feeling good is important. I'd be much more likely to start a contracting business than found a company.
We are(were) the exact same way, and I hate(d) it.
Every customer is a whale and has demands, both on features and deadlines. Failing to meet these can result in losing the customer and the more customers we get the harder it is to balance/scale it all. Scale is personnel scale to handle each new challenges new clients bring. Somehow no matter what the is always a new client with some new demand we have never seen before.
I don't see how your development is way faster, how do you handle multiple requests from multiple companies all different?
Last year we started our self serve initiative and have slowly been growing there. Before we might have clung on anyway possible to keep the whale where now if they are too much of a hassle we can comfortably say "no" to something and not sweat their loss.
With self serve, we are much more scalable. We don't need to hire more devs just because we have more companies. This is our product this is how you can integrate it and these are the customizations.
We still take client requests, but we weigh them with other requests and if we deem them mutually beneficial to a majority it will get prioritized. We talk with our clients weekly and they have access to basecamp/jira/email to communicate individually, you can still get plenty of insights
I hate it sometimes too, and lose a lot of time to frequent interuptions. It still seems to work for us though. I think there may be some differences in our situation based on what you've said.
We don't hunt whales. We actually avoid them (whales take a long time to pay you, and are very demanding). If one customer wants something from us which we don't think will benefit our customer base as a whole, we point them to our various APIs, or just tell them no. That said, usually they want things which benefit our whole customer base, and so we're happy to work with them to provide this.
Customers almost always buy the software 'as-is'. While customers expect to be able to communicate their future needs to us, and expect our software to improve over time, very rarely does a sale hinge on developing a new feature. If it does, I am always consulted and will advise on whether we should agree to the sale (I'm consulted on unusual sales anyway).
The reason we're not 'self-serve' is because we have a services department devoted to providing a complete solution for our customers. Either remotely, or while visiting their facility. Customers pay for this separately.
We'll definitely need to hire more developers as we continue to grow, and I'm sure we'll face challenges scaling how we operate now, but I think the benefits are worth it.
Regarding getting features out the door faster with a single person. This is because I know the problem domain inside and out, even though it's a moving target. I know the domain because I constantly communicate with our end users and services staff (I used to be our whole services staff; very happy to have gotten past that!).
Oddly enough, the frustration of being interrupted is usually rewarded. I've had a lot of phone calls that started with me thinking 'I don't want to deal with this right now...', and ended with me thinking 'What a great idea for adding value to our product! I'm so glad I spoke with them directly!'. Typically the customer asks for something, and then we talk about why they want it, and we eventually (together) figure out an even better way to solve their real problem.
Anyway, YMMV. It sounds like the bigger challenge you're seeing is clients demanding new features, and deciding there's not acceptable ROI without them. That's definitely a problem, but I don't think it's necessarily solved by not having a team that does implementations?
An alternate POV: you can sell boutique software as a means of getting paid to do initial iterations on an idea while simultaneously building out an impressive set of logos to slap on your site when you release an off-the-shelf version down-market to capture what the smaller companies are paying LOB/plugin devs to do.
The shop I'm at is in the first half of that, TBD whether it works out. Which is about as much anecdata as the OP has in support of their claim.
If I had to guess, I'd say the amount of consulting you're providing to your customers to supplement the software, or the gap between the process of using your software vs. just automating existing workflows probably has a lot to do with which approach is preferable.
The other note is that if you have a decent amount of domain expertise/networking, you can do the above and not take on VC funding. You may not eat the world but you'll do a hell of a lot better than most lifestyle startups.
A company I was at for nearly a decade did just this, a few times... kind of. We never fully transitioned to the SaaS versions of whatever software we were building for customers, and ended up with a "base" software that we would then just tweak to the customers spec.
It wasn't a bad model by any means, and we ended up turning what had been 3-4 month projects into 1 week, and charging the same amount.
One product was an emergency communications platform for city government, another was a CMS/CRM/Website Builder for RV dealers, another was a blogging/sales platform for interior designers. We had a half dozen base products that we sold to hundreds of clients for a few thousand a piece.
We had enough individual customers in each of these spaces to build all these semi-custom solutions based on shared codebases, but we could never find enough customers paying a LOT less per month to afford spending time on the SaaS versions.
We were a tiny team of only 3 though, if we had some venture capital maybe things would have turned out differently.
We eventually moved out of doing "custom" software though, and into consulting on SEO and Brand Reputation, then finally into launching our in-house software as SaaS offerings, growing our service business from around $200k ARR to between $30k and $90k MRR.
You can read some of that journey in the second half of a blog post I wrote a while back[1].
That approach is sound, but challenging, IMHO. The two major issues you run into are "how do we allocate resources between the boutique and the off-the-shelf version?" and "how do we manage the functional differences between the versions?"
Both can be overcome but require really good, disciplined people.
On resources, the "right" answer is to have your core team focused on the off-the-shelf version, and then have revenue from the boutique version fund its own additional labor. In my limited experience, software salespeople crumble on putting out the big price tag ask to make boutique development work in this way.
On functionality differences, there's a spectrum of customization. Extreme customization often comes at the detriment of the overall evolvability of the software. So for boutique customization you need judicious devs who build carefully, you need PMs who can push back on the customer delicately, and sales folks who don't overpromise. A good friend's uncle sold his otherwise thriving software company because his boutique product had fragmented into a dozen products (one for each client) and it was impossible to maintain.
If the boutique version is a coat of paint with a custom page or two, life is great! If they're completely different, you're essentially a consultancy working on your own product on the side. That's a grind and I've seen it burn people out.
I've observed the same thing in the EdTech space (e.g. ClassDojo, Google Classroom), and I think a big part of that is being self-serve forces the company to build _actually good_ software, not just software that sells well to the district, state, etc.
What's required to sell software to large buyers is very different from what's required to make the product useful, but in the long-run, it's the utility of the product that makes it valuable to end-users, and the success of the end-users _eventually_ determines how the buyers make decisions. Self-serve software tends to prioritize the things that will make it easy to sell and improve in the future.
Exactly. Serving people directly strongly encourages a focus on delivering real value, because the user and the purchaser are the same.
Serving people indirectly allows for all sorts of other approaches that work in the short term. If purchasing decisions are mainly driven by our sales guys and their executives, it slows and distorts a key feedback loop.
I once heard a story about SurveyMonkey that I love. They got their start very much on the self-serve end. But eventually the CFO of Oracle saw all these credit card charges from individual Oracle employees using it, went to SurveyMonkey, and said, "Create an enterprise tier for us." SurveyMonkey looked at what it would take in terms of engineering and said, "Sorry, we have other priorities right now."
The way I heard it, the Oracle CFO, not used to being told no, sent forth an edict: From now on staff were not to use SurveyMonkey, but some other product that Oracle did have an enterprise deal with. Sounds like bad news for SurveyMonkey! Except that the other product wasn't very good, and SurveyMonkey wasn't that much anyhow, so people just went on using and expensing it.
I'm at a company with a self-serve B2B API platform.
Our customers mostly build their own PaaS offerings on top of our API, which has some really positive effects I have observed.
1. Stickiness & seriousness of customer. When we land a big customer who is going to swap out competitor APIs from their platform and use ours, this customer is clearly very serious about building & growing with us, as the approval to rewrite huge amounts of core platform functionality to use our APIs is not made lightly, and is almost always made by a technical C-level person. The building phase often results in very close relationships with their developers. Their needs and demands help drive our roadmap, but with the understanding that we're not special-casing anything for them. If they need a feature, we're going to take the time to build it so everyone can use it.
2. Being API-first means satisfying the developer, which lends itself to focusing on building ergonomic software. If updating some configuration takes 2 seconds instead of 200ms, no developer is going to prioritize switching to our API when they need to make a 50k of those update requests regularly.
If something takes two commands on our API instead of one on our competitors API, it better be damn clear what value that extra command is providing... etc etc etc.
I think that for B2B software, the right approach is "service first!": you should consider service processes as equally important as the business processes your product supports. For each feature, you should ask yourself "How will we provide customer support for it?"
The answer does not need to be "self-service", but don't add customer service as afterthought to your product.
We have been self-serve product for the first 12 years and a year ago we launched our Enterprise version. As the article mentions because of the existing high traffic it has been pretty easy to find leads. We have already signed 100 Enterprise customers. Our main challenge was not to find customers, in fact we struggled to catch up with leads. The main challenges were making the product Enterprise ready with necessary features such as covering most popular SSOs and building admin privileges on the Enterprise product, and trying to build a sales team from scratch.
We had to hire 3 sales people before we found someone right. It is like someone hiring developers without any development experience. You get it wrong because you don't know what makes someone good. Get help from someone who has experience. We finally found the right person from our network and suddenly sales started flying.
Can you explain a bit more? I cannot quite square the fact that you had issues with sales (people) and the fact that you had no problem finding customers... Why do you need sales people, if not to find customers? Or do you actually mean customer support / integration people?
The leads are the top of the funnel. Traditionally salespeople take leads and turn them into deals. So I presume they were seeing a big falloff between interest and conversion.
It also doesn't surprise me at all they struggled to find good salespeople. I hear that all the time. Seems like it's hard to tell the difference between a salesperson who can sell your product and one who's just selling themselves to you.
> By the end of our coffee, he resolved to pull together a tiger team of four engineers to rearchitect the company’s technology stack and make it possible to launch a self-serve version of the product by end of year.
wonder what the fate of this 7.5month x 4 engineer rewrite was
I think this has to be taken with a grain of salt. Building self-serve can have huge development costs which for enterprise B2B can be absolutely out of proportion before a product market fit.
Isn't "do things that do not scale" (and automate them away once you got enough momentum) a mantra exactly opposite to this?
Self-serve is a specific form of automation. The problem is that introducing automation after the fact is almost impossible in this case, because the sales org you'd automate away tends to become far too powerful to ever allow that to happen. Postponing the sales automation adds a very hard cultural problem you the technological one you already had.
By the way, I would not call "do things that do not scale" a mantra, rather the opposite: "don't scale too early, but be dead sure that you can when you need to".
If anything, I'd think self-serve should empower a good sales team. I would think it would let them spend less time scheduling and doing generic demo, PoC planning, and onboarding meetings, because customers could do all of that themselves (with the option to talk to a human at any point in the cycle, if they want to).
I've never been on the SaaS sales side, but from the big-enterprise buyer side, I've seen what seems like so many unnecessary wasted cycles spent on things that could be avoided if there was a way for us to immediately start playing around with their product ourselves (and potentially even using it in production) before talking to anyone. Then when we do talk to them and schedule meetings with them, it could be focused on specific questions and feature requests we have after spending time with the product. Instead, it was usually 3 - 7 meetings before we could even get to the stage where we evaluate the product hands-on. Those meetings could be drawn out over the course of 3 - 10 months.
I got the impression a lot of that was because they wanted to sweettalk and hand-hold us as much as possible to increase the chance we would agree to the most extensive and expensive contract they could think we'd accept. All the worst offenders would want to constantly take us out to lunch and schedule various sorts of useless meetings before asking us to agree to some absurdly overpriced contract. And then our managers would have to do various dances with them over the course of weeks or months to get them to drop the price/agreement to something we found more reasonable (they'd usually concede to most or all of our requests, sometimes dropping the price by like 80% in the process).
I do understand that purely from a financial side; they have a lot more revenue (and commissions) potential if they tailor the price to the most each company is willing to pay, and giving customers access to the things which cost the least to provide, both of which may vary wildly from company to company. And maybe at the end of the day, that is actually the most effective strategy for making money. To your point, maybe a powerful sales org is actually rational to avoid automation, so they can milk more per large customer and make more net revenue. But it felt like a lot of wasted time for us engineers who weren't sure when or if we were going to evaluate the product, or purchase it after evaluation, and usually generated bad will from our engineers and especially our managers. Not to mention the annoyance of interrupting work to sit in on so many mostly-useless meetings.
Over the course of many years and dealing with probably 20 or 30 vendors, I don't think there was a single sales team we interacted with who we didn't unanimously agree we utterly despised. The exception was a small boutique firm which happened to have the best product and service in a particular domain, in addition to being priced literally 50x lower than their main competition (one of the companies that frequently wanted to meet us for lunch and schedule all sorts of pre-pre-pre-calls; that company's product was also, maybe unsurprisingly, total shit compared to the small firm's). I believe we mostly just dealt with the founder in that case.
Even with a non-self service system spinning up a demo should not take that long. I'd say those companies indeed had further political or other issues leading to your experience. For the product team alone a proper pipeline for building and deployment is worth it.
Than again it of course also depends on how the product works, how deep the integration and customization needed are etc.
Dev side of the business myself, so just perception of the mechanics why self-service may be unattractive for the sales team:
From a sales perspective you would typically optimize for fewer false-negatives (people not buying even though the solution would be valuable for them) at the expense of more false-positives (you wasting time trying to convince people who have no value and therefore don't buy in the end).
Self-demos lead to people self-selecting themselves out without sales being able to influence this (explain the lead maybe just misunderstood a feature in the self-demo etc).
Besides typical sales bonus structures reward converted leads which the sales person did convert, not avoided churn after self-signup which customer success gets credit for.
It was indeed always political, sales, and contractual hurdles (some their company's fault, some our company's fault) I believe if we could somehow interact solely and directly with a vendor's engineers, the whole process would take a few days to a week, max, for most vendors. But sadly that doesn't seem to be how enterprise B2B operates in my domain.
I'd recommend against falling into some mode of cargo cult thinking on this one. A key part of whether self serve is going to work is to look at how fragmented the requirements and use cases are across different customers. In many cases, there will be a good amount of domain customization, which invariably makes it difficult to go into self serve. Most of the examples provided are around utility/productivity apps which all tend to have very similar requirements across a large customer base..
The point the article is making is that if you want great customer support you need to design that into the company's business model, and so it gets reflected in all sorts of places - cost structure, org chart, target market, customer expectations, etc. And then if it turns out there is a segment of the market that doesn't care about customer support (which is fairly common with tech companies), you cannot effectively compete for that segment. Tech businesses frequently have network effects or strong economies of scale, so a company with no customer support but a decent product can often eat the self-serve end of the market, then use the profits and market leverage from that to build a decent customer support operation and attack the higher-end market segments. This is the model that's been employed very effectively by Dropbox, Github, Heroku, Google, etc.
Zappos is not a software company. They sell inventoried product. The high quality support for this inventoried product is provided by low skill / low cost employees. The quality of the support staff is not in direct competition with the quality of the produced product. This is what allows it to be economical to specialize in support
I haven't heard much about Github or Heroku but as far as I'm aware, neither Dropbox nor (especially) Google have stellar reputations for customer service.
Google has great customer service if you're regularly dropping $10M on ad buys - you get a personal sales rep who takes you out to expensive dinners and does all the normal wining & dining of high-end business. I've heard GitHub is similar if you purchase their on-prem Enterprise product.
That's my point about moving up-market: it's not that the self-serve product has good customer service, it's that they create a division within the company with all the customary trappings of B2B sales & support and then leverage their consumer product as free marketing & engineering.
It’s all relative. My products are in the $100 to $500 range, there is a limit to how much support you are going to get for that price. On the other hand it does mean I will work hard to engineer problems out of the software.
Software products do not sell themselves. Only when you have a snow-ball rolling where users will tell other's. And I would say most software need a sales process, even if the software itself is very intuitive and solve a real problem, you basically have to install it on users machine. Then teach them to use it, and come back every week and repeat.
It depends which end of the market you are targeting. My customers generally don’t have the budget for consultingware. Their budget means they can only get a self service solution.
I think that a better approach to software is to only build what is absolutely necessary, lazily, according to real user stories fulfilled by customer service. Try to automate away all the customer service, but only in response to learning from it in the first place.
So I'm building a Wizard of OZ interface for creating custom Wizard of OZ interfaces.
A good sales force is the richest source of market and product information that you can ever find if they are good, and if you can get them talking. But they know why/not what they sell sells. The caveat is that if the answer is "cheap" then that is the thing you will not hear...
Virtually every customer pays us for technical support, and our developer (I'm effectively the only one), talks to customers practically every day about what they need in the product and to our services staff about their challenges. The insight this provides is invaluable.
Companies in the market with dozens/hundreds of developers are worse at deploying new features than we are with a single developer (yes, I write tests and use industry best practices for my stack, extra work up front, but development is waaaay faster years later). Think ViaWeb's Lisp advantage, except our real secret weapon is just that 1 developer who talks to all their customers and their services department is as good as 20 who don't (I'm using C#/Vue for web [with an erlang like actor framework I built] and C++/Lisp for embedded).
There are certainly challenges scaling, and dear lord am I underpaid (I'm more interested in autonomy than the 3x-10x money I'd get from moving to a competitor), but self serve is orthogonal to our customer appeal. (Others in the market might actually think we're self serve though, just because our software is user friendly and self serve is actually possible).