Self-serve first: an overlooked paradigm underlying great software companies
medium.com
medium.com
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).
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!
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've actually made the framework available as an open source library: https://github.com/caseymarquis/KC.Actin
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.
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
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?
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.
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.
As opposed to off-the-shelf / generic software that is put out to market and is then purchased by whomever thinks it would meet their needs.
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].
1: https://jeremyaboyd.micro.blog/2016/11/05/my-first-product.h...
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.
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.
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.
https://www.quora.com/Why-did-Borland-fail/answer/Danny-Thor...
(discussed on Hacker News - https://news.ycombinator.com/item?id=9712267)
The answer does not need to be "self-service", but don't add customer service as afterthought to your product.
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.
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
He got a promo after launch, the project was quietly taken out back and shot 6-9 months after launch. Happens every time. :-)
Isn't "do things that do not scale" (and automate them away once you got enough momentum) a mantra exactly opposite to this?
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".
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.
Than again it of course also depends on how the product works, how deep the integration and customization needed are etc.
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.
Is being a "great software company" really mutually exclusive with being a "company with great customer support"?
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.
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.
So I'm building a Wizard of OZ interface for creating custom Wizard of OZ interfaces.