Hacker News Reader

Comment by siliconc0w | Hacker News Reader

Consulting doesn't scale, software does.

One pragmatic strategy to find product/customers:

    1) Pick an industry
    2) Ask someone in that industry what they use spreadsheets for
    3) Build something better

There is a lot of 'cybernetic' processes that are a mix of humans with domain knowledge and machines with spreadsheets for schemaless storage and querying. Generally the move is to encode the domain knowledge into code and standardize the storage (i.e excel -> RDMS) to make it more useful.

View on HN

I know a guy that has made quite a successful software business out of abandonware. Find some business that's using software that has been abandoned. Original authors went out of business, etc. Maybe the users are still keeping MS-DOS or Windows NT computers around because it won't run on anything newer. This is not as uncommon as you might think.

Talk to the users, try to find out how many others are also using it. Rewrite it in modern technology, sell it back to all the current users (and ideally, also sell to others in the same line of business who might need it).

I can bootstrap consulting, can't software.

On top of that consulting opens door, you get very valuable insight inside certain industries and get paid for it.

Also, I'm sure I'm not the only one who is not interested in the slightest in building a unicorn or dealing with investors/VCs.

Building software with no clients requires capital, I'd rather keep mine for my family rather than burn it in the wind into something that is most likely to fail.

To add to this conversation, you can parlay consulting into software without a ton of problems.

Do work for customers. While doing work, try and find a shared pain point across your industry/customers. Build software for it and use your existing relationship to sell it. Or sell it and then build. Whichever.

I think it's possible find a useful middle-ground between consulting and product building, in the pg "do things that don't scale" sense. As the article also points out you can kill a second bird with the same stone, which is self-funding via the consulting.

And then ideally via the consulting you find a niche(s), build your own processes & tooling for your niche to deliver value to clients, and then can product-ize once you actually understand the space and the market, who the customers will be and how to reach them, because you're already doing it via the consulting and just need to scale up.

It also serves as a sanity check that you're actually building something that has value, because you prove it to yourself via invoices for your work rather than investment in an idea.

This is a great strategy.

I've heard this before, but part of the appeal of the spreadsheet is that Patty from accounting or Joe from HR can modify it without having to ask any IT staff, including you.

So I don't think it's a foolproof scheme, unless your solution is also programmable/customizable, which is a lot of work.

Yeah it's not foolproof just a way to start.

Here is one random example that comes to mind. "Risk Management" is something every company needs to do or pretend to do.

So someone gets stuck with this responsibility and they create a spreadsheet that looks like: Department | Risk | Likelihood | Impact

So this is a fairly mediocre solution but it kinda works and "risk management" for "Small Company Co" becomes "Bob's thing".

Of course there is very likely software that already does this but in my experience it's usually what the hipster programmers call "enterprise garbage". You know what i'm talking about - buzzwordy site with stock photos, long annoying sales cycles, no online demo or sign up, some java server you have to deploy, and some extjs/jquery interface that is ugly and each click takes 5-10 seconds. You aren't competing with these guys, you're going after the long tail of small companies they are ignoring.

Your move is to register some fun name - "Riskly", "Riskque", "Risksalot", etc. Next, hire a graphic designer to put together a fun colorful site, hire a college kid to make a fun video with royalty free upbeat music and narration showcasing your app, and build a simple CRUD app with maybe some built in risks for certain industries and some cool simulations/reports.

So go spend a few years of your life and see if you can't 'Disrupt/Fix Risk Management'. Or go work for a large company for eight years, take all your earnings, go to Vegas, and let it all ride on a 10:1 bet. It works out about the same.

Odds are probably worse for the startup unless you have actual experience in Risk Management.

Proper risk management is serious business. "Risk" "management" in smaller businesses may just be pretended. This illusion will cost some time, focus and money to keep up. I believe that's the market referred to.

A lot of things in small companies are pretended, which I think was grandparent's point.

HR, benefits, invoicing, inventory tracking, project tracking, etc etc

And the fact that there are business providing most of those testify to how good of an idea it is (and how crappy the existing MBA-Sales enterprise solutions are).

This is actually largely what we're trying to do at Sonadier.com. The basic idea is that you can build most enterprise CRUD applications with drag-and-drop forms.

While we realized it before starting, we didn't fully grasp how much you need people with "computer literacy" to build these things, for lack of a better term. Just thinking about the schema of the application you need is something a lot of people can't really do yet.

As far as I can tell it's got very little to do software intuitiveness, as I've noticed the same effect on phone calls with prospective customers.

Even as enterprise moves towards managed SaaS platforms, there'll always be a huge place for power-users. Much of the time, even just defining the problem that needs to be solved takes one.

It sounds like you may have an opportunity to offload some of that power-user/consultant content to contractors who just integrate your platform in their gigs. Or, operate a linearly-scaling in-house consultancy and have your platform be a means to optimize revenue per employee.

The CRUD application is definitely not the hard part, but it can be the long part.

Spot on. We've had success with in-house consulting for medium-to-large development projects, and we're in talks with a few MSPs now to help them offer managed custom applications to their customers. In terms of long-term scaling, getting more contractors on board is our biggest priority.

What's the best email to send inquiries to? Enterprise@? Possibly relevant to my interests on the supply side.

Or reach out to ethbro . coAtGma il.

Hi there, I just noticed that I had a new reply. I've sent you an email.

>So I don't think it's a foolproof scheme, unless your solution is also programmable/customizable, which is a lot of work.

Yep, almost everyone you casually talk to about a problem domain is only casually talking about it. They'll dream, but won't let you know about the pitfalls.

After you build something, the next questions are usually, "Can you change this just for us?", which is a fun task if you have 9 other customers that won't want that change.

So you have "advanced options", add a switch, and then change all of that. And if you do it right it's still nice and modular.

Or plugins. Then say "Hey, we now have this plugin available for only $x.xx".

Ever heard of Zapier?

Consulting pays the bills when software can't. It's all about the mix and getting to what you want -- not everyone is destined to be a product owner.

Your advice is spot-on, although I would likely CAPITALIZE the words "build something better". Not so easy a proposition.

Accenture revenue in 2016, $32.9 billion. Consulting definitely scales.

The point is scaling without increasing linearly the number of employees. Accenture has approx. 400K employees

A succinct way of putting it is there is a finite profit margin on consulting.

Agreeing: https://priceonomics.com/which-companies-have-the-highest-re...

Accenture is #493 of the S&P500, at $101k of revenue per employee. (!) They're doing a bit better than McDonalds (#497). The scalability argument holds -- compare to Netflix, which scales quite well (#23, $1.9M/employee).

True, and interestingly the way that they scale and remain profitable is by going after specific industries offering quite specific consulting services. From the outside it looks like generic "consulting" but actually they sell packages that are quite specific.

O(n) vs O(log n)

In English s'il vous plait?

Basically it's saying for every extra dollar you want to earn in consulting you must hire more engineers. For traditional software you can continue to sell the same bits over and over and not hire an extra engineer for the Nth sale.

I mean there is some level of growth in the sales/marketing/accounting and non-engineering departments right? Engineering isn't the only thing in a business, sometimes it's not even the most important (as much as we might hate to hear that). I've been in extremely successful software companies that had a crap product but an amazing sales team (although I didn't stick around long).

Couldn't agree more.

I've noticed this pattern in both business and in individual engineers.

You either have a spectacular product that theoretically could sell itself with initial exposure, or you have the best marketing and a product that might as well be vapor.

Usually it's the mediocre product that's somewhere in between that wins.

In engineers I've noticed that some of the brightest I've worked with are unsociable, or have no self esteem, and get stuck in the same place for 20 years, and on the other side of the spectrum are talentless hacks that are great at selling themselves and moving around enough to increase their salary.

Meanwhile I feel like a fraud because I'm not the best, but good enough to recognize my worth and sociable enough to put myself out there.

I leverage the shit out of that and feel somewhat guilty about hoping that the really talented local engineers don't catch on to the idea.

Also the optimal mix varies according to company age.

Younger company with unknown decent product? More heavily spending on sales.

Older company with industry recommendations from previous clients? Spend less on fewer, more technical sales people.

Older company with no recommendations from previous clients? You're doing something wrong, and sales isn't the place you should be spending your money.

I feel like normally this logic is inverted at the C-level though. Sales are low and product isn't getting traction? Hire more sales and marketing folks and put off those engineering hires.

Tell that to Uber's 15,000 employees.

The above comment is implying:

Consulting requires linear increase of resources. Software product requires logarithmic increase of resources. Therefore product business is more efficient to scale than consulting.

known as "Big O Notation": https://rob-bell.net/2009/06/a-beginners-guide-to-big-o-nota...

Sure, but with < 10% margins and terrible growth rates.

When people say "it scales" they are largely referring to the cost of serving incremental customers. Software does that well, consulting doesn't.

It's a great business if you can profitably hire other engineers and skim the difference in what you charge for them and what you pay them.

>the move is to encode the domain knowledge into code and standardize the storage (i.e excel -> RDMS) to make it more useful

This is exactly what I did!

Reply on news.ycombinator.com