Big Silicon Valley capital is largely interested in consumer-facing, high-growth “world domination” plays, in anything that has the potential to become a household name. Naturally, the Valley’s startup-grooming tributaries (e.g. Y Combinator) aim to position tech entrepreneurs at an angle complementary to that criteria, since that’s how they make money.
A lot of the cultivated folklore and intellectual work-product of the cultural leaders of this space, as epitomised by the writing of Paul Graham, speaks the language of upward exponential curves, critical mass, and gargantuan user bases–all things Valley web economy VCs like. As PG says here and elsewhere, startups are, most essentially of all, about going big by building something lots of people want.
But what if you’re like us, making a foray into the “boring” world of intra-industrial business software or a product that is specialised deeply into a vertical-specific niche?
I don’t mean a “lifestyle business”, nor do I specifically mean the long-run, sustainable, bootstrapped approach for the advocacy of which 37Signals and DHH have distinguished themselves (although nonparticipation in mainstream tech investment is implied); 37Signals still have products that millions of people want. I’m talking about building something relatively expensive that almost nobody wants.
Think of some Byzantine water pump control mechanism for a sewage treatment plant, something you can elevator-pitch in two seconds to a very select audience but that you couldn’t easily explain in ten minutes to anyone else. We build something like that for the VoIP telephony industry.
We’ve been around for eight years, we’re tiny, and we’ve morphed into a product company largely out of a consulting heritage. We’re clearly not a startup as YC and Valley “VC-istan” would have it, and nobody would fund us. We’re in no danger whatsoever of a “rocket-ship trajectory”, do not leverage “network effects”, we’re not “going viral”, and our customer acquisition cost is pretty high. While we too have benefited from the structural decline in the cost of starting a technology company (e.g. cloud servers), we’re largely unable to benefit from some of the biggest shifts to a lower cost basis and barriers to entry: Google web ads don’t do us much good because that’s not how our typical customers find us, and we don’t have anything to put in a mobile app store.
It’s mostly old-fashioned relationship building, personal brand, conferences and trade shows for us. It’s boring, it’s expensive, it’s slow. Imagine an SEO-tweaked conversion funnel with low-touch onboarding. We’ve got whatever the opposite of that is: a trickle of leads that, when we get lucky, spool out into long, drawn-out, consultative sales cycles measured in months or even years. It’s not the stuff of compelling pitch decks.
And so, the question I’ve been pondering for a long time is: what is the size and location of the cultural and methodological intersection between the Hacker News flavour of startup lore and our kind of business model? Do we have still have something to learn and apply? Can any useful takeaways be mined from the corpus of essays and “thought leadership” that PG and YC have provided? Are there useful entrepreneurial insights to be captured from Hacker News?
I think the answer is yes. One must simply be careful to cherry-pick the right bits. Here are a few thoughts:
Making Something People Want
In the business software realm, this needs to be recast with a sharp emphasis on “solve problems people have”. The advice to solve one’s own problems, or at least problems directly relatable to one’s industry experience, is, at its core, essential.
I first had an idea for something like our present-day product in 2006. At that time, I was young, inexperienced and new to telecom, and conceived of the problem space in very a priori terms. Had I moved forward and tried to take the concept to market at that stage, it would have been a spectacular flop because it did not provide institutionally acceptable solutions to actually-existing problems.
It’s possible that, had I been in a financial position to commit to it full time and avoided being bogged down in consulting for several years, I would have realised a speed advantage from being able to “fail fast”, “iterate” and/or “pivot” in response to the negative feedback for my initial concept. However, in a small industry where personal brand and reputation plays an important role, I’m not sure the speed advantage would have outweighed the personal brand deterioration resulting from putting something out there that simply doesn’t work.
Thus, I’m moved to say that the emphasis on empiricism and really understanding one’s target user is triply important in business software. In particular, I would add that non-trivial domain expertise in the user’s industry is probably a must, unless you’re building something that is, at heart, rather broad and generic.
There’s a particularly ludicrous current of wishful thinking out there that presupposes “customer discovery” to be a free-floating skill set unrelated to any particular industry or sphere of expertise. There probably are some backward industries where daily workflows consist of mostly disposable paper pushing, and where an application with some commodity CRUD screens could make a meaningful dent. However, in our industry, having a JS/CSS-savvy “UX quarterback” shadow “everyday users” for a few days to “really discover their pain points” would be a hopelessly naive waste of time.
There are no shortcuts to knowing a lot about telecom by working in telecom. To make a good telecom product, you have to be deeply conversant with the history of voice and data, the supply chains, the acronyms, and the regulation–oh God, the regulation. This probably holds true of most industries you could build complex solutions for. If you think you can walk into property casualty reinsurance and “disrupt” the place with a month-long Ruby on Rails bender (how very Agile of you), the vertical niche business market is not for you.
In this light, the market validation provided by an organic, consulting-driven funding strategy–which PG is generally sour on–is highly valuable. It might be worth building your product that way even if you could go the fundraising route instead. You’ll learn a lot. I doubt our product would have any market traction if we had tried to leapfrog the several years of hard lessons learned about our target market from our otherwise tiresome and financially stressful consulting slog.
Making Something Users Love
Having said all that, if you read a lot of PG and Sam Altman, it’s easy to become discouraged by repeated talk of the importance of building something users love. Good products simply roll off the shelves, like those round-ish late-1990s iMacs. Marketing is just an optimisation for more eyeballs; the product fundamentally sells itself on a powerful wave of early-adopter enthusiasm, and if your product isn’t grabbing most people who come across it, the implication is that it’s just not a good product.
There’s a fine line there. You do have to know when to call it quits if nobody’s buying what you’re selling. It’s possible to sell at least one unit of something to someone, somewhere given enough time and effort; it doesn’t imply a good commercial prospectus. You should have some way of figuring out if your product isn’t really taking.
However, sales in this area is hard, and you should expect that; the idea that your potential customers are going to just want or love what you’re selling in a self-evident kind of way is complicated by, well, the complexity of what’s being sold. Don’t be fooled into thinking that your product isn’t good just because every sale feels like bruising hand-to-hand combat. You’re fighting against institutional inertia, the customs and habits of the boys at the country club, sclerotic management bureaucracy, combative purchasing departments, and the marketing stranglehold of big-brand competitors on risk-averse management. In our case, we’re selling something that requires the customer to remove core infrastructure in a growing, revenue-generating, and intensely downtime-averse business and replace it with our own. It’s easy to get everyone to agree it’s ultimately a good idea, but it takes political wherewithal. “We’re really in a hurry to do that,” said no executive decision-maker ever.
Many of our most loyal customers of today didn’t know they had a commercial problem our product could solve. The function of marketing becomes very important here: as a general rule for the world of capital goods, customers have to be educated. The “bounce rate” on eyeballs alone is going to be close to 100%.
The popular understanding of what it means to make something users love is often tied up in good user experience and front-end mechanics. This is a siren song. In the world of capital goods and the complex solution sales that go with them, the most important criterion is, “Does it make or save us money?”
That’s not to say a good UI isn’t a competitive advantage, but don’t sweat it. Users will put up with a pretty bad UI on a machine that prints money for their company. More importantly, a good UI won’t do a damn thing for a product that doesn’t have positive bottom-line impact or significant business-level differentiation.
It is indeed critical to hire the right early-stage employees, and hiring mistakes in the early stage will break your company with all the good products and marketing tailwinds in the world. Much of what PG and the YC crowd have to say on the importance of building a great team is directly applicable.
Early-stage hiring is particularly complicated in niche verticals because your customers are buying a vendor service relationship as much as they are buying a software system. Your staff will be engaged closely with customers who expect credibility and expertise from your people, and it’s the warm fuzzies from that collaboration that often close the sale.
That often means that run-of-the-mill skill sets found in the general IT population you can hire off the street simply won’t do. Entry-level people are especially pernicious hiring choice here, since there’s so much more background knowledge to impart. Your early-stage employees will need to be both technical and essentially fluent in the industry domain to which you are selling, which greatly reduces your hiring pool and makes candidates even more expensive.
Accordingly, your success and failure depends on your ability to get people with some vertical-specific industry background in the door. You should expect to make even more compromises here than typical in Valley web startup land as far as equity grants and so on. You’ll want to be mindful of the regions and labour markets around the country that concentrate IT people with particular domain knowledge above and beyond table stakes technical skills: if you’re doing something in energy, get comfortable with Houston, and if you’re doing fintech, think Chicago or New York.
There really are no pre-revenue business models in enterprise software; at least, there shouldn’t be. All talk about building “critical mass” user base and figuring out how to monetise it or render it profitable later is irrelevant and should be summarily ignored. Your first customer should be paying.
There are, of course, some strategic API and platform plays out there whose primary purpose is to set up for an acquisition. These often don’t have paying users or don’t generate a lot of revenue. However, as a general rule, acquisitions in the business market are more rationalistic and quantitative, so bringing more revenue to the table redounds to the benefit of your valuation and bargaining power. This is a bit different from the voodoo valuation process of mass-market startups, where irrational investor exuberance can sometimes be maximised by removing the constraint of concrete, earth-bound revenue and encouraging the acquirer to “really dream big”. All this to say: book revenue. You’re not going to get more for less by letting a freemium cat out of the bag and into the open market. More revenue is always better.
Otherwise, in a market with a low volume of high-magnitude transactions, every customer counts. Arithmetically, price segmentation of some description is usually required to make a product economically viable. One of your biggest preoccupations early on should be to delineate the needs of your “lite” users at one extreme, versus your “enterprise” or “platinum plan” users on the other, and to tier your product accordingly. Joel Spolsky’s classic Camels and Rubber Duckies, dated though it may be, still comes highly recommended as one of the best introductions I’ve seen on this subject.