Hacker News Reader

Comment by jargnar | Hacker News Reader

It's a skill that can be learned like every other skill. You can take the "in 21 days" route or the MOOC / University course route, or constantly read business articles, Steve Jobs videos, etc.

But some top tips stand out for me over time:

* Talking to people, networking > Not talking to people

* Bug free > Elegant code

* UX > UI

* Simple products that do one thing well > Complex products

* Understanding entire market > understanding some people

* Building brand > Making quick money (for the long run)

* Sleep, exercise & healthy food > late night coding

* Solving your problem first > Solving the worlds problems

* Adaptability, pivoting > Ego

* Knowledge of where the money is > No knowledge of it

* Overestimating cost/expenses > Underestimating it

* Patience > No Patience

* No procrastination > Procrastination

* Reading books > Not reading books

View on HN

Small clients > one big client

Especially at the beginning, you read here how often big clients can put you under at the beginning because you're not ready to deal with them.

Ohhh, yes!

After four years in which I frequently worked in a 6h/1h work/sleep rhythm for weeks at a time, I just left town and decided to never again have any customer that I couldn't fire and forget about on the spot if I wanted.

Big clients and projects were, at least for me, a complete nightmare. Worst were the lawsuits which, even when we ultimately won, would basically ruin whole years at a time.

Now I'm working for a few thousand customers at maybe $50/year average. When some technology or idea seems interesting, I'll spend 48h straight trying to get it working. When the weather starts to get warm, I'll spend the day in the sun with a bottle of white wine and no appointments until November.

But...

A few big jobs > many small jobs

Low-paying jobs will consume more time than you expect. Be careful when quoting these. Always charge more than you think you need to cover your time.

Big clients tend to be very slow at signing contracts because their legals would examine every word and will keep asking you to revise the contract. Furtheremore, real big clients tend to be slow at adopting the techology they just bought, so you may not get feedback quick enough to improve your product. Big clients are more likely to argue for discount as they would use "I am big name" as leverage.

This, and sales concentration is a real risk as well. If you have few big customers and even one of them churns, the impact this will have on you is certainly going to be material.

Yes, the strategy for big client is to lock them in for long engagement (like a 3-YR term). Throw in some nice support package, longer trial period, whatever. Since big customers often take months to fully use a product (6-12 months is very common), I wouldn't worry about "oh now I got big name, I need more infrastructure, more money to pay my cloud vendor." It won't for 6-12 months and you probably can keep all the pennies from the big client monthly. If you get a downpayment (say 1-year for a 3-yr term), you get ammunition to grow your team and get more smaller customers.

That is true for consulting and manual/in-person kind of service. However with SaaS the automation is crucial to service the masses.

This. When small shops land their first big client they're always so excited. To me it's like having a stone tied around your neck. Big clients can often be more trouble than they're worth and become a financial risk when they send you packing and you've hired extra people just for their account.

Reminds me of https://www.python.org/dev/peps/pep-0020/

Beautiful is better than ugly.

Explicit is better than implicit.

Simple is better than complex.

Complex is better than complicated.

Flat is better than nested.

Sparse is better than dense.

Readability counts.

Special cases aren't special enough to break the rules.

Although practicality beats purity.

Errors should never pass silently.

Unless explicitly silenced.

In the face of ambiguity, refuse the temptation to guess.

There should be one-- and preferably only one --obvious way to do it.

Although that way may not be obvious at first unless you're Dutch.

Now is better than never.

Although never is often better than right now.

If the implementation is hard to explain, it's a bad idea.

If the implementation is easy to explain, it may be a good idea.

Namespaces are one honking great idea -- let's do more of those!

Good advice. Some of these (most?) apply to the business-side founder types as well:

> Simple products that do one thing well > Complex products

It has been my experience that business people constantly make this mistake. They feel a product has to satisfy all needs. The engineers I have met have consistently argued to remove features that are expensive to develop and add little value.

Both of those are anecdotes. Your milage may vary.

Possibly slightly controversial:

* Doing something you're interested in > all the self-help and motivational quotes in the world

* Doing something potentially meaningful and failing > doing something you don't care about and muddling through

Being able to stand up in front of people and tell them something. And make them laugh.

Listen to people, figure out what 90% is bullshit or irrelevant and what 10% is interesting business opportunity.

This is great, thanks! Could you do a blog post or something. :)

https://bothsidesofthetable.com/most-startups-should-be-deer...

2009 post, but still one of my favorite distillations of the issues around b2b customer types. Particular impactful if you read it when you end up going above and beyond with support, feature development, and contract negotiations with both rabbits and whales and you're running out of money.

> It's a skill that can be learned like every other skill. You can take the "in 21 days" route or the MOOC / University course route

Sorry, what did you mean by "in 21 days route"? Also, do you have any MOOC on doing business to recommend?

There's a trope of technology learning books whose titles fit the pattern "Teach yourself X in 21 days".

the 21 days are in reference to Peter Norvig's article: http://norvig.com/21-days.html

Nice, but I'm not entirely sure about this one:

> * Sleep, exercise & healthy food > late night coding

Looks like it's against other points. I have a full-time job and I'd like to create a brand, too. Thus. I have to do late night coding.

No you are wrong. In order to get there (build successful brand) you have to take care of your self. With coding marathons, buckets of coffee and fast food (because "I don't have time to cook") you will end up with heart attack before you achieve what you planned.

Not only that but adequate sleep, regular exercise and healthy eating contribute enormously towards healthier cognition. As a developer, I tend to find myself far more productive and successful in a shorter period of time when I am living on the healthy side of things. Everything that is me just works better when I go for a run three days a week, eat clean foods and get in a solid 8 hours of rest a night.

Tee hee. 8 hours of sleep.

Sounds like someone doesn't have kids.

Mostly tongue in cheek, but also slightly serious. There are plenty of life circumstances that preclude all those things.

You are 100% correct - I have no kids and have the luxury of not having major life commitments blocking my ability to do these things.

A full time job is a 9-5. Let's say you commute from 8-9 and 5-630. That means you can gym from 645 to 8 (including travel time), eat decently, do some coding, hit bed around 1030, and be sleeping around 11 (so you have enough time in the morning by waking up at 7). Cook on the weekends, code on the weekends, social life Friday and Saturday night...

Do you work more than 40hrs a week? Why? Sounds like you're creating someone else's brand if so.

In my country I work from 08-15, excercise 1 hour. I still have 6 hours left for cooking food and coding before i go to sleep 22

Let's say you have half of this spare time to work on your side project, that is 3 hours. Excluding weekends, how much time would it take to build a business out of your 15-hours-per-week side project?

Well, typically building a business is a full time job. I'd recommend someone make extra money in their spare time to facilitate a work-break rather than trying to do two "full time" jobs at once.

Rome wasnt built in 15-hours :-)

That's so unreal it hurts

No it's not.

If it is, it means you're probably working too much for someone else!

Maybe you're right. Unfortunately. Thanks for the heads up anyway.

Good luck out there.

With exercise, I'm finding cycling to work and lifting weights are effective in terms of time. I spend half an hour of my day getting to work and back - probably about 10 minutes longer than it would take in a car. And with weight lifting, I never do any more than 3 sets of 10. The actual amount of time it takes is short.

This isn't exactly olympian conditioning, but I do notice a benefit and the time investment is low.

Running from the start as fast as you can will never help you win a marathon.

The principle is that you have to maintain health.

I think late-night coding is a near-constant because of our brains automatically optimize us onto what pg describes as "the Maker's Schedule". Context switching is anathema to effective coding, so people automatically go to the time when they'll be least-interrupted, which is when the rest of the world is asleep.

You also need to maintain a social life and relationships with family and friends. It will boost the productivity more than you believe

You need around 7-8 hrs of sleeping to focus and proper brain functions. Only 3-4% of world people can survive and work perfectly with 4-5 hrs of sleep.

getting 3 solid hours of working on your brand a day is much better than 7 bad ones late at night. Wake up earlier, work at lunch, work immediately when you get home. Late nights are not always necessary.

http://stuff.imeos.org/dropzone/jargnars_business-advice-for...

* Solving your problem first > Solving the worlds problems

Any chance you could expand a bit on this one?

I don't think it's accurate if you take it at face value. If you genuinely solve the world's problems, that's a better place to be (business-wise) than having solved your own problems.

But trying to solve the world's problems vs. trying to solve your own is another matter. You probably better understand your own problems.

It means: Solving your problem first > Solving others' problems (that don't affect you). The reasoning is that you are an expert in problems that affect you.

If the problem affects the whole world, including yourself, then it falls in the left bucket.

Thanks for the list, I'll refer back to it

I get some of these, but "don't procrastinate" and "understand the entire market" are kind of ridiculous. You might as well throw "know everything" and "work hard" in there.

I'm a dev who's starting a business and running up against some of this -- for me 'understand the entire market' resonated.

In my case that means knowing the major datapoints about competitors in my space (public vs private companies, who's making/losing money, appannie stats), knowing everything available about cost of user acquisition, and looking at psych studies on user motivations.

These are things I would have benefited from knowing on day 0 but instead only learned after building a prototype that I had to scrap.

If your business is enterprise focused rather than consumer focused, understanding one or two customers is probably good enough for a start.

Seriously. Your proof that you understand a market is only as good as the frequency that your understanding is tested, whether the test is profits or rote knowledge.

This is true for many things. I'm the best developer as long as I don't compare myself to a better developer.

Also, make sure not to confuse understanding your customers with understanding how the industry works.

Some of the craziest and successful startup ideas come from people who don't understand the industry at all and if they had they probably would have never tried to do what they did.

Survivorship bias. Some of the biggest flops also come from people who don't understand the industry at all, and if they had they probably would have never tried to do what they did.

You can't understand your customers if you don't understand their industry. Picking customers is like investing: if you pick a bunch of customers that are not going to win their industry, you won't thrive either.

That may be true, but it isn't a reason not to try. Heck in the process you may learn the industry, just too late for current venture. It is however a reason to be willing to recognise a flop and abandon it for something else.

Yes, but what I'm actually trying to do is cast suspicion on the dichotomy between industry and customers. Industry is not a thing that exists. There are only people, their objectives, their resources, and their problems. Those are the things that need understanding.

Perhaps I chose the wrong word. I was looking for a word to describe the biases of people entrenched within an industry.

I don't think that's what the parent meant: your time is better spent understanding the whole market than a subset, and your time is better spent getting the important trivial thing done now than working on the not-as-important nontrivial thing.

Reply on news.ycombinator.com