[HN Gopher] Now is a good time to start a service business
___________________________________________________________________
Now is a good time to start a service business
Author : zachthewf
Score : 80 points
Date : 2024-06-20 04:17 UTC (18 hours ago)
(HTM) web link (www.zachocean.com)
(TXT) w3m dump (www.zachocean.com)
| joshuanapoli wrote:
| We started selling services in earnest alongside our SaaS product
| this year, and it's working out well. We didn't think of doing
| this during ZIRP; it was relatively easier to invest in more
| rapid product development.
| zachthewf wrote:
| Nice, what do you guys do?
| jollofricepeas wrote:
| I disagree in part.
|
| It really comes down to your own temperament.
|
| I think micro SaaS solutions for small tiny verticals that are
| neglected by VC backed firms are the better option.
|
| - They scale better
|
| - Less competition
|
| - Customer service is less of a headache with a physical product
| or SaaS
|
| - Easier to exit
| portaouflop wrote:
| What small tiny verticals are neglected by VC backed firms?
|
| Asking for a friend.
| jollofricepeas wrote:
| Any B2B vertical where customer ACV is less than $10k per
| year.
|
| If the vertical has affiliated trade organizations when you
| go to their events, you'll find either very few VC-backed
| startups or none at all.
|
| The competition will be mainly service businesses without
| software chops. Sell cheap automation and price sensitive
| customers will move to your solution.
| HeyLaughingBoy wrote:
| I'm pretty sure that there are no VC-backed firms building
| software for chimney sweeps.
| rco8786 wrote:
| Really confused to see the conclusion of "It's a good time to
| start a service business because of AI". AI can't perform, or
| even semi-perform, a single one of the example services the
| author used except maybe "design agency".
|
| But otherwise, it does seem that starting a service business is
| sort of the ultimate "do things that don't scale" strategy.
| dudus wrote:
| AI increases productivity. If you are selling your time that
| means higher margins. It doesn't have to do everything. If it
| increases your productivity by 10% that is all profit.
| zachthewf wrote:
| Even if AI doesn't help with any aspect of the service itself
| there are a ton of efficiency gains to be had from "the rest"
| of the work, which will make service margins less ugly. Every
| business still neeeds some form of sales and/or marketing,
| support, and back office administration.
|
| And for a lot of services there'll be creative ways to squeeze
| efficiencies from tech/AI. For example roofing businesses used
| to send a guy to your house to give you an evaluation + quote;
| increasingly, they now send drones (https://www.roofer.com/).
| hatefulmoron wrote:
| The claim that there's a lot of efficiency to gain from
| _tech_ isn't interesting. I'm guessing when the author talks
| about AI, they're not suggesting to build a fleet of drones.
| zachthewf wrote:
| (I'm the author)
|
| The "why now" is any significant new efficiency gains that
| are available without a ton of cash.
| rco8786 wrote:
| Drones aren't AI though?
| creer wrote:
| A service business is about selling employee time. Anything you
| can use to speed up the non-core tasks goes straight to the
| bottom line percentage. After that anything you can use to have
| management "run" more people also goes straight to the bottom
| line, as a multiplier.
|
| So there is tons of potential in AI-based tools. Is it there
| yet? I doubt it. But perhaps yes. Anyone here getting traction
| in AI for business routine efficiency? Back office? Accounting?
| Time-keeping? Task dispatching? Email requests dispatching?
| Audit?
|
| But also possibly, having a sales team running the simple cases
| (mostly) straight through an AI "junior engineer" before even
| talking to the more expensive guy.
| csmeyer wrote:
| Palantir is a classic example of what is a hybrid services =>
| product business. It was a _very_ long road for them to get to a
| point where their product could actually scale without massive
| implementation effort, but I think they're finally getting there
| (they offer a cheap self service option now AFAIK)
| safety1st wrote:
| One of the interesting bits of information that came out of
| Microsoft's acquisition of Github was that at the time, the
| majority of Github's revenue was enterprise deals. Enterprise
| is a code word that product businesses frequently use for
| services - yeah sure you have a product, but here are these
| guys who want to use it to the tune of $10M/year but you will
| need to do custom development just for them, so what is that?
| That looks a lot like a conventional service business running
| inside the same company as your product business.
|
| Microsoft actually seems to specialize in that sort of thing
| (selling a software product, and then offering some quite
| expensive, bespoke enterprise consulting services for it). But
| they are not the only ones, looks around the industry and
| you'll see it everywhere.
|
| The only real drawback to this model when you're small is that
| it dilutes your focus and multiplies complexity and cost
| because you have to manage multiple very different lines of
| business simultaneously. But if you can overcome those
| challenges it can make a lot of sense, be an expert at a
| particular problem, sell a product for the average Joes who
| have that problem, do bespoke consulting services for the
| money-laden enterprises who have their own complex versions of
| it.
| pylua wrote:
| The other drawback to buying expensive consulting services is
| that your company does not have the domain knowledge of the
| solution.
| HeyLaughingBoy wrote:
| That's not necessarily a drawback. That's the reason people
| hire plumbers instead of learning plumbing: they have more
| important things to focus on.
| onionisafruit wrote:
| That's not how GitHub's enterprise deals worked. It was the
| same product for all enterprise customers.
| disgruntledphd2 wrote:
| Not quite, the onprem version was older and didn't have
| Actions for ages, for example.
|
| But to be fair, basically all enterprise deals involve
| services as you generally need to train people in how your
| thing works if you want to get enough adoption for when
| Finance come looking for operational efficiencies.
| onionisafruit wrote:
| It's been a while, but I think that enterprise customers
| all had access to both enterprise cloud and on-prem. What
| I was really getting at though is that there was no
| custom code or consulting with the vast majority of
| GitHub's enterprise deals.
| bryan_w wrote:
| I think its less about custom code for Large Company
| Inc., but rather, when Large Company Inc. had a bug or an
| feature request that was prioritized and perhaps released
| to them first
| kiliantics wrote:
| When it comes to analytics or machine learning type products,
| the scaling without massive implementation effort problem seems
| to be pretty universally hard to solve. Of course the usual big
| names seem to manage this on some level but startups seem to
| get stuck at building a handful of great solutions for a
| handful of clients/problems but unable to increase the number
| without also increasing the effort proportionally.
|
| Do you know of any examples of small scrappy places that have
| figured this out? Is there any good writing on what kind of
| organisational and engineering approaches are necessary to make
| this step?
| disgruntledphd2 wrote:
| This is because data is basically a service business. Like
| the value is the specific data and it's hard to build a
| product that works for customers without a lot of custom
| work.
| cjs_ac wrote:
| Caveat: I'm approaching this from a 'indie hacker' mindset. The
| article mentions $10 million funding rounds, so they're probably
| approaching this from a different mindset.
|
| The article distinguishes between a _product business_ and a
| _service business_. In the former, the founders find a problem,
| build a solution, and then sell that solution to people who have
| the problem. In the latter, the founders find people who have a
| problem, and then build a solution for that problem.
|
| In a product business, the risk is that you solve the wrong
| problem. In a service business, the risk is that you never find a
| problem to solve.
|
| I used to be a schoolteacher, in schools where teachers tended to
| be on the verge of retirement. Most of my colleagues used
| computers because one day their typewriter had been taken away
| and a computer put in its place. Their technology use tended to
| be quite basic: emails and basic word processing. Most workflows
| were unchanged since the typewriter and mimeograph days. Almost
| all planning was still done on paper, on especially-printed
| planning books. (We were individually asked whether we wanted
| week-to-a-page or day-to-a-page when the stationery order was
| being prepared for the next school year.)
|
| (Lesson planning is not a problem to be solved; I'm just using it
| as an example of the kind of mindset I was working alongside.)
|
| This is a problem-rich environment filled with people who don't
| know that many of their problems can be solved by computers. You
| can't ask these people what problems they want solved, because
| they don't know that their problems _can_ be solved. You have to
| have something to show them and point to and talk about before
| they can grasp the idea that it 's even possible to automate some
| of their work.
|
| However, I speak from a position of privilege. I spent years
| working in that environment, and I walked away with a list of
| problems - a list of potential products. If you've only worked in
| software, you won't know any good problems. You'll know some bad
| problems, and they'll be bad because your potential customers -
| other software engineers - are just as capable of building their
| own solutions as you. In that case, a service business is
| probably no more risky than a product business.
|
| If you start a product business, your moat is the insider
| knowledge you have of how to solve the problem you solve. If you
| start a service business, your moat is your reputation for
| solving people's problems. If you have no insider knowledge, you
| start your business with no moat at all, and have to dig it while
| building your castle, whereas the founder with inside knowledge
| just has to build their castle within their pre-dug moat.
| keiferski wrote:
| On a really long timeline, it's probably high-end services
| businesses that have the most job security. I'm thinking of
| professions like Michelin-quality chefs, performance coaches for
| top CEOs and athletes, etc. These will likely never be replaced
| by any sort of automation, at least within our lifetimes.
| falcor84 wrote:
| I'm not sure about chefs (though I do have some opinions), but
| I'd be surprised to see much success for any CEO or athlete who
| would stick to a human performance coach once they can have
| "Her" level AI whispering expert-level advice into their ears
| at real time.
| keiferski wrote:
| I don't think professional athletes are that dismissive of
| the collective wisdom of real-world experts, and are in fact
| much more likely to pay for the "human premium" and not a
| soulless chatbot, no matter how advanced its information.
| falcor84 wrote:
| But the LLM is almost literally "the collective wisdom of
| real-world experts" rather than a single one. Obviously
| it's not at that level yet, but I don't see a clear upper
| bound to it getting there. I'm not very familiar with
| athletes, but from what I know, regardless of the "human
| premium", if the AI coach helps their competitors perform
| better, they'll need to adapt or "perish".
| keiferski wrote:
| Coaching, especially at elite levels, isn't about
| information. At that point the human connection to a
| coach with championship experience is better than pretty
| much any conceivable chatbot.
| 0x63_Problems wrote:
| Is the kernel of this advice to start with a known problem which
| is already solved with a paid service, and then just sell that
| service more efficiently? That's how I'm interpreting the "skip
| the R&D phase" idea. In that case I think the question becomes
| "why is this a better strategy for a startup", since this framing
| implies going after well-established markets with (at first) an
| undifferentiated product. Both 'productize' and 'automate' sound
| like things that incumbents would be able to do more effectively
| than startups, and likely has already happened in most cases
| silently in the background.
| zachthewf wrote:
| > "Is the kernel of this advice to start with a known problem
| which is already solved with a paid service, and then just sell
| that service more efficiently?"
|
| Yep, this captures what I'm saying.
|
| > "why is this a better strategy for a startup"
|
| If you _can_ build a differentiated product it 's great to do
| that, but it's a lot more difficult/expensive than it used to
| be.
|
| Incumbent product companies will pursue full automation, but
| probably won't compete directly with service businesses because
| it's not their wheelhouse. E.g. GitHub built Copilot and maybe
| they'll try to ship a "fully automated" AI software engineer.
| But until their AI software engineer is actually fully
| automated (which I would guess is 10 years away at least), they
| won't be competing with software development agencies.
| ed wrote:
| If the service opportunity is to resell AI skill to the people
| who lack it, consider productizing and selling Education instead.
| Otherwise the clock is ticking for a new model to put you out of
| business. Most folks will need to learn "AI for ___" eventually,
| and product businesses are way better to own. Service businesses
| are a lot like being employed. (Having run both.)
| zachthewf wrote:
| What do you mean by selling Education?
| htrp wrote:
| run training platform like coursera vs developing the courses
| Bloomy22 wrote:
| Sorry for the off-topic, but reading this text I thought about
| myself.
|
| I find myself at a critical point where I wonder what I should do
| next. I'm over 40 years old and have accumulated years of
| experience. Sometimes I feel like Neo when he controls the
| Matrix. Maybe I've been in the same role for too long, but it
| doesn't matter what project I'm assigned: I implement it with
| little difficulty (beyond the time cost, exhaustion, etc.).
|
| On the other hand, despite the confidence they've always had in
| me, the place where I work is starting to feel hostile. Being an
| introverted person, I try to figure out if this is something that
| depends on me (and if I can redirect it) rather than looking for
| answers where I should. Being introverted, it seems unwise to
| start something that depends on my social skills. Conversely,
| every day it seems like new obstacles appear, as if going to a
| job that I liked 90% now feels like a problem.
|
| I have to say, I work in a flat-structure company where the boss
| is a megalomaniac who wants to control everything. A good part of
| the new things we do are his impulsive ideas. The office is
| filled with figurines (dinosaurs, busts from 80s movies, ...) and
| motivational quotes. He gives talks about how well he does things
| and how great it is to work there, but he doesn't improve
| salaries or do anything to provide training, a better work
| environment, etc. He also plays dirty tricks on employees, like
| unexpectedly complicating pre-arranged vacations or trying to
| delay them without a real reason
|
| While writing this, I realized that the 10% that made me not like
| the company has always been because of him. And if I don't like
| it, it's because of him.
|
| The only thing that keeps me tied to this place (besides the
| money, since I don't live in the opulence of certain regions
| where software is very well paid) is the entrepreneurial spirit
| of having done so much in the product.
|
| PS: If someone saw our product, the things we have done with just
| 4 people (on average), they would be amazed. And, with all
| humility, a large part of that has been driven by me, which ties
| me and kills me.
___________________________________________________________________
(page generated 2024-06-20 23:01 UTC)