
Self-serve first: an overlooked paradigm underlying great software companies - feross
https://medium.com/@gokulrajaram/self-serve-first-the-overlooked-but-essential-paradigm-underlying-great-software-companies-45a67dbec4c4
======
caseymarquis
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).

~~~
balfirevic
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!

~~~
caseymarquis
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](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](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.

------
ndarwincorn
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.

~~~
bitcoinmoney
What’s boutique software?

~~~
ldjb
Bespoke software; software tailor-made for a particular client/customer,
according to their specifications.

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.

------
rickcnagy
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.

~~~
wpietri
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.

------
Crinus
This reminds me of the "Why did Borland fail" story:

[https://www.quora.com/Why-did-Borland-fail/answer/Danny-
Thor...](https://www.quora.com/Why-did-Borland-fail/answer/Danny-Thorpe)

(discussed on Hacker News -
[https://news.ycombinator.com/item?id=9712267](https://news.ycombinator.com/item?id=9712267))

~~~
adamc
Thanks for those links!

------
wsy
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.

------
aytekin
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.

~~~
tomp
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?

~~~
wpietri
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.

------
maximente
generally enjoyed the article, then hit this:

> 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

~~~
m0zg
> 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. :-)

~~~
x220
Heads I win, tails you lose.

------
anotheryou
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?

~~~
usrusr
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".

~~~
meowface
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.

~~~
anotheryou
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.

~~~
NewsAware
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.

~~~
1234Mhj
si siht emos dnik fo ekoj.

------
vchak1
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..

------
taneq
You say "self-serve", I hear "externalize your support costs".

Is being a "great software company" really mutually exclusive with being a
"company with great customer support"?

~~~
nostrademons
It's not - see Zappos pre-acquisition.

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.

~~~
taneq
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.

~~~
ndarwincorn
Github's rep is probably worse than Google's.

~~~
jayp
Not sure where this is coming from. Not my experience, but I am one data
point.

------
rco8786
There are tons of examples of “truly great” software companies that are not
self serve first. Neither approach is necessarily better than the other.

------
z3t4
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.

~~~
tonyedgecombe
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.

------
atrilumen
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.

------
scarejunba
There are so many B2B companies in the adtech space that are completely
enterprise-oriented and they're printing money.

------
sgt101
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...

------
natmaka
It resonates with [https://skyclerk.com/blog/if-you-run-a-small-business-
park-i...](https://skyclerk.com/blog/if-you-run-a-small-business-park-in-the-
back-of-the-parking-lot)

------
protez
Great article. But almost all of B2C software products are self-serving.

