Ask HN: Important nonobvious startup/business lessons you've learned?

Here's 30 years of experience for you:

1. Few business problems can't be solved by more sales.

2. Cut expenses when the storm is approaching, not when you're soaking wet.

3. You can't eat assets or inventory. Don't get emotional about what you own, only about your cash balances.

4. Banks are your friend only when you don't need them. Corollary: One bank for borrowing, one for cash balance accounts.

5. 70 completed calls per week. Not emails, calls. You can do it, start now.

6. Don't be an asshole: https://en.wikipedia.org/wiki/The_No_Asshole_Rule

7. Hire and retain "T-shaped" people. In difficult times those employees execute across multiple domains.

8. Client, vendor or employee drama is quicksand. You assist with a stick or a rope, you don't jump in with them.

9. Don't romanticize work & try to avoid romance getting in the way of work.

10. You're only as happy as your unhappiest child. Prioritize good parenting over work. Good parenting = SOS: Self awareness, objectivity, selflessness.

11. Get a prenup. No, really, do get one.

12. Pay yourself according to a financial model that prioritizes healthy business cash balances, and not your personal desires.

Sales fixes everything. Very hard to learn for engineers and designers often.

That can sometimes be fixed with "don't walk there" stickers and/or ignored.

I wonder how many dev teams exist that think their product isn’t defective.

Assuming the product that has been sold actually exists!

Great lessons, all.

I'd add: ARR is a metric, cash is king. (related to 2-4 from your list)

No, they aren't. They're literally saying you should be a good parent to your children.

Your children - their physical wellbeing, emotional and mental health, behaviour - have a profound impact on you that, for good or for ill, will absolutely colour your own behaviour and decision-making at work.

Can confirm. Have a stable family is key to work success. Or put it other way, always put family first

> 1. Few business problems can't be solved by more sales.

This obviously completely wrong. The only problem that can be solved by mores sales is when your are not selling enough. And even in this case just having more sales not always work.

I'm the first to say that what matter most for a company is its ability to have more customers. But having more sales when you sales org is badly structured will make you loose a lot of money. Same products problems won't be solved by more sales, same for Marketing problems, or People problems or actually any problem.

> This obviously completely wrong.

You might familiarize yourself with Rule #6 before commenting on Rule #1.

- The decreasing barrier to ship products means sales & marketing is what differentiates successful products versus products with 0 users.

- After building a high growth / high churn product, I am OK sacrificing decreased growth for a significantly decreased churn rate. Great product with high churn is a hard business to build, even when customers love the product.

- One of the highest leverage decisions you'll make is deciding what to build. You can achieve a 1x, 10x, or 100x outcome with the same blood, sweat, and tears depending on what market you decide to build in.

- Choose something that aligns with your strengths. A good idea for me, might be a terrible idea for you if it doesn't leverage your specific knowledge (Naval calls this product / market / founder fit).

- Product is really freaking hard and relying on external contractors sucks, give someone technical a significant % of your company to own product development.

- Google Search & YouTube are likely one of your most important acquisition channels, because these are the only two platforms that consistently surface old content. Chances are, G can distribute your content better than you can yourself via email / social / copromotions, etc.

- High performers are cool, but high performers that document what they know so junior level team members can execute at the same level, or better is even cooler. Document everything you expect to hold someone accountable to doing in a specific way.

- Email recaps let me skip 10-15 meetings per week. I get the agenda, notes, and decisions that were made, and can jump in (but usually don't) at my leisure without sitting through the meeting.

Apply your technical skills to a non-technical business. Dont start a tech startup in a tech hub. Run a business completely unrelated to tech and use your skills to improve that business, theres SO much low haning fruit out there.

The venn diagram of tech skills and a non-tech business is where the opportunities are. This applies to many other unrelated skills.

This is amazing advise. People working in tech, especially in high tech orgs live in bubbles and often imagine that the whole world is like this. I know a multimillion £ business that probably gained hundreds of thousands in productivity by simply introducing shared mailbox. Some of those low hanging fruits are litterly on the ground ready to be picked up.

Best advice in the thread so far.

You’re chances of success are 10x higher trying to build technology for tanning salons than it is building the next new docker kubernetes react native infrastructure as a service.

Unsexy sells.

Maybe this is actually obvious, but it's still a common mistake in startups so I'll say it - you don't have to believe your product is good to start selling; you just have to be better than not having the product. You don't even have to believe it's the best, or believe it's complete, or even like it. People will happily give you money for anything that makes their pain point slightly less painful.

You should start selling before your product is complete, but I disagree that people will "give you money for anything that makes their pain point slightly less painful" (in some categories perhaps).

For consumer products, your product must cut through the clutter. For business products, it must exceed the hassles of buying (and it usually has to be a top 1-3 priority for the buyer).

Although absolutely start selling before you get there. For the feedback, not revenue.

This is definitely nonobvious and also consoling to someone that is a perfectionist

There's a video where Michael Seibel of Y Combinator says something like "Don't treat your MVP like it's precious. Treat it like an old t-shirt you plan to wear to paint the house in and throw it away afterwards."

You don't know what you don't know. Iteration is king.

Experience can't be shared to team member. I don't mean that experience can't be documented and read. But that readers don't have visceral feeling upon reading. It goes both way.

First, team members with limited experience don't internalized why certain things is done certain way. They "know" it through indoctrination. It could be cultural or technical. This leads to reinventing wheel or people sharing some random blog article and following advice blindly. You want to exploit your experience.

Second, it is hard for yourself to identify blindspots. Trust and delegate is easier said than done. You want to explore unknown hence expand the island of experience.

Have a mental model on where you and your teammates are on the relative experience spectrum and switch between explore and exploit is important. Fast iteration/feedback cycles help you identify that relative position on the spectrum.

I haven’t seen success at all. That's because people is super hard. Selling to people and managing people.

Selling is super hard. Ideas are worthless if you can't sell. My thesis is that make sure you have the connections to make the initial sells and you have the personality trait to ask for referral and grow from the initial sales.

If you haven’t figured out a way to guaranteed sales yet, don’t hope for a miracle with marketing. When you start investing in marketing you will find yourself convincing yourself you are investing in the goodwill which might generate sales down the line which is a lie*.

I think many people take on investors hoping that will lead to sales leads or an "in" in the industry. Sometimes that backfires because the investors will setup metrics, KPI and goals which is often based on sales itself!

Don't build something that the world needs, build something that you can sell!

It seems like a good reason to have a marketing co-founder if you're a tech/product person.

1. Verify that co-founders are emotionally committed to stay. For my first startup, I lost half the founding team when things started getting stressful. Needless to say, that made things even more stressful.

2. Don't trust big companies to take you seriously. I've been burned by "lets use market leader XY" and then later "why won't market leader XY return our calls" and then "we're offline due to market leader XY not responding to support ticket AB" more often than I can remember.

3. Never commit to support stuff outside of your control. That means you don't guarantee uptime ever unless you have your own datacenter and your own admin team. Otherwise, always scope contracts to say "we will be online 99% of the time that cloud X is error-free".

4. If stuff goes to shit and it's not your fault, announce that loudly to your customers. Otherwise, they will blame you simply because you're the messenger bringing them the bad news. People just love to shoot the messenger (metaphorically).

5. When you need money, banks will ignore you. When you have too much of it, you get flooded with additional offers for cheap credit. Plan accordingly, so you need to borrow long before you start the project and borrow enough to get you over the cash flow shortage. If you wait until you actually need the money, terms will be horrible.

6. People are suckers for social proof. "Nobody ever got fired for buying IBM". Make sure you have your top customers featured on your website and update that list regularly. Go to conferences so that you can invite your top customers for dinner and people will talk about it.

7. Some people start drinking when stuff gets tough. And some people change their character 180 degrees when they are drunk. Not sure how to defend against that, though.

EDIT: 8. Research the market in advance. I once had a product that people loved, but my customers going bankrupt produced serious churn for us, reduced customer LTV, etc. Building stuff in that market was lots of work for little benefit.

The "No"s are more important than the "Yes"es.

Focus is about saying "no" to everything else. You don't get focus by saying "yes" to the thing you want to focus on.

Success on platforms that have a recommendation system (YouTube, Roblox, Google etc.) is nonlinear.

Because results are ranked by some metrics, if you make your thing 10% better (watch time, play time, CTR etc.), it will not only reap the direct benefits of being that much better, but the indirect benefits of now outranking others whenever the situation arises where it can get recommended vs. others (recommended videos, games, search results).

So it can make sense to put in more time into making something just a little better than would seem intuitively reasonable. MrBeast and Tim Urban of WaitButWhy both talked about this in their podcast interviews.

Kind of well known but I think bears endless repetition.

There will come a time when someone in a very large organization will take an interest in your product. You're going to feel very validated because now you can tell friends, family, investors, potential customers that X is using/piloting your product. They may or may not give you money, but it will certainly be less than your time is worth. They will definitely take a very long time to make any kind of decisive move. It is very likely that they will destroy your focus and never actually become a real customer. The longer you engage with them, the more you will want to make something come out of it and the worse the impact will be.

David Heinemeier Hansson (of Ruby on Rails and Basecamp fame) once wrote a blog post with related advice on per-seat pricing (for a SaaS) and how this leads to chasing the biggest companies. One you've gained a very large company as a client, that company's outsize influence will affect features, fixes and direction in your product (in a negative way according to Hansson).

The Basecamp pricing model (flat monthly fee) is not often emulated by other startups, but it's worked well for Basecamp.

Why we never sold Basecamp by the seat ( (2017): https://m.signalvnoise.com/why-we-never-sold-basecamp-by-the...

1) You almost certainly can charge more

2) No matter what business relationships you have with other companies, but they will always save them first

3) Being known for paying on time can do wonders when the going gets tough.

4) Get rid of toxic assholes asap no matter how valuable

5) You aren't aware of the tech that exists and can help your business, do seeks for advise

6) Better service is only possible when the entire company believes in it

7) Don't mix confident with competent

8) Not all things should be automated

9) Buy things you need not want

As someone who has been an arsehole and has worked with a fair share of them, I've come to realize that arseholes in a workplace are often a product of their environment. Anyone who is sufficiently overworked, undercompensated, interrupted, or mismanaged, is likely to become an arsehole given enough time.

As a dev i've always known my hunch when it comes to compromises. Never let the business team ruin your experience building cool rock-solid code. I'd rather resign than to compromise anymore. I know there should be a sweet spot between "perfect" and "working". Even a junior can pull-off a "working" app. But when it starts to scale, all those hasty bad decisions will bite your ass. Never skip planning, plan as long as you need. Nowadays i start coding only after i have 100% visibility into what i'm building: diagrams, dependency graph, schemas, types and data structures, documentation, user flows, everything. As the say goes: if i have 24h to chop a tree, i'd sharpen my axe 23h. And we haven't yet taken into account infrastructure, devops, ci/cd, security, releases, logging, and all sorts of tooling. I need around 2 months just for initial planning, setting everything up and laying out the codebase structure.

I apologize if this sounds harsh, but I can't see the /s anywhere and I want to clarify for others.

This post outlines how to destroy a new (or any) business.

There will never be anything approaching 100% clarity between different people talking about a thing that doesn't yet exist.

We all have to see it and feel it in order to truly understand it.

This experience almost always leads to creating new, better ideas, discarding old ideas and digging deeper on others.

That's all before we even leave the building and learn from customers.

I shudder to imagine trying to get a start up off the ground and needing to wait 3-6 months for the first commits only to then have to argue about change orders with my eng team.

I would say a related point to that is: don't skimp on unit and integration tests. It's easy to rush code out but tests will force you to think through it and give you a way to quickly test if a change is a breaking one.

But as a counter point, early in a product lifecycle you don't even know if the product you are building is what you are going to find a market fit for. So spending a lot of time getting the tech perfect is sometimes a waste. It's a constant calculation of balancing the risk of not scaling with the risk of taking so long you never get to the point where you can scale.

Thanks for sharing your thoughts here. I think it's useful for us to get a glimpse into your thought process and start a discussion.

Though I empathize with the overall desire, you sound inexperienced to me, as in, you might have had some failures that you attributed to lack of planning or business decisions, etc, but you haven't learnt from successes, because some of the stuff you're saying is just extreme counterproductive wishful thinking to the point where it sounds like trolling.

For example, 'building cool rock-solid code' is typically not a business goal or at best, a nice to have. Developers are hired to solve a business problem. If the code doesn't solve the problem, you're wasting precious resources. 'cool code' is a personal choice.

Compromising is essentially a trade-off like any other, and it requires careful deliberation in every context. Your opting to not compromise by default means that you're introducing friction in the team, in the business relationship and potentially affecting the life of the business, not to mention that it's a 'us vs them' mentality when you're supposed to be part of a team to deliver a product together.

Your reasoning about hasty decisions biting you is also backwards. Notice how you're just assuming that a product will start getting enough users to need to scale. Guess what: like most products, the product you worked on was actually not that great, didn't have a good product-market fit and if you hadn't spent all that time polishing and planning the cool non-junior code, you might have saved everyone months of time.

Also you go from 'never skip planning' to 'take as long as you need'. Those are 2 extreme approaches. It turns out that a little planning goes a long way. You can come back and iterate on the plan. No plan is going to be perfect from the start, because you don't have all of the information available to you when you start a project. As you develop a project, you get more information on hidden requirements, user expectations, non-functional requirements and various other metrics that you couldn't have thought about ahead of time.

What you are describing is the waterfall approach to software development and the only way it doesn't fail is if the domain and the product are very well understood (e.g. "build a grep clone in Rust"), but most products aren't well understood ahead of time, only in retrospect, so it's a constant back-and-forth between acquiring new understandings about the product and applying them in practice by changing what's already there. It requires your code to be flexible, not 'cool' or 'rock solid'.

Consequently, you will never get 100% visibility into what you are building. If you find yourself thinking "gee I know exactly what we are building" you are setting yourself up for disappointment when 'the business people' pull the rug under all your diagrams and schemas and types that you spent months designing instead of getting a usable POC out the door asap.

Honestly, it's just a phase you're going through. Once you get burned by your current approach a few times, you'll internalize the need to avoid either extremes and you'll start looking for that middle ground is with each project.

I know this because I went through the same phase.

Good luck with that trying to find PMF and first 100 customers. Later stage, I get it sort of. Seed and A series you will kill your company by being too slow. Waterfall does not work for this.

I partially agree here.

if a component is core to your strategy or product then by all means make sure it's rock solid.

but if you're iterating on your product and you don't know which feature is going to be used then don't waste time perfecting it.

we put together in days products that we shutdown in 3 months, we would have never been able to move at such speed if we took our time plan, design, develop ...

and business people do come with a lot of things that go nowhere (depending on your company sales culture of course and product maturity)

Mine is a bit meta, but don't take advice from random people about creating million dollar businesses. Always check the profile of the person giving the advice first.

Same applies for people teaching about SEO and marketing. It's very important to check who is giving the advice as a lot of advice seems to make sense in theory but doesn't translate that well practically.

You need to think about how to manage expectations and ability of employees, particularly if they are the only person who does that job. You might take someone on who says they will do something and they don't, or they don't very well. How will you deal with that?

What is a fair way of measuring someone's effectiveness. It is easy to try and be kind but if you e.g. have a salesperson who is not selling, they need to go.

It is tempting to think you can't afford great people early on but plenty of businesses prove that great people sometimes put belief in the product or an interesting job/challenge or potential equity above a base salary.

When starting a greenfield project, the programming language will affect the culture quite a bit. At such a project, I chose C# because it's a reasonably good language and easy to hire for. What I found was that there's a culture of writing—in my opinion—overly abstract code. Our coding challenge could be solved easily in 50 lines of code, but most candidates would submit huge projects with dependency injection, type reflection, class hierarchies, etc. It was hard to create a culture of simplicity.

Now, this is highly subjective, but I think the general lesson applies: Programming language choice is important for culture.

Local business culture is extremely difficult to change. In most cases you might as well be banging your head against a wall. You're usually better off trying to gather a small group of folks and forming a subculture.

If you are in B2B Enterprise, just having a quarterly meeting with your customers vs having none can be the difference between a success and a failure for this customer.

All business are different, there is not one road to success, there are as many as successful companies. As a result non-contextual business advice is usually useless.

In B2B Enterprise also. Most companies fails not because they don't have a good product, but because they don't sell well enough

The number of people saying with strong conviction that they will pay for your product/service doesn't necessarily correlate to the number of people who will actually pay for it, and can be different by orders of magnitude.

Learn practical "Game Theory", everything we do is a Game, whether within the company, or between the company and the outside world.

Above and beyond the above, also read "Finite and Infinite Games", the ultimate goal is to continue to play Games, and win the majority of them; if you play to win all Games, you will win all the "battles" (Games) but lose the vast majority of "Wars" (Meta-Games).

90% of business deals that both parties say they are excited about making happen will not actually happen

And the other 10% take 2 years (if your product costs more than 10k$).

From a software engineer's perspective:

*I don't know how to sell.*

Well, have you been to a job interview and got the job? That was a closed deal. You understood the problem, you showed them why you not someone else and you got hired. That is selling.

I had to do it to understand it.

*If your solution will change the user workflow or behaviour, good luck*

I learned this the hard way.

1. If the idea / product is any good, it'll probably catch on quickly and sales will be easy.

2. Expect your startup/business/product to morph into something else, and that you'll change names and domain names, maybe multiple times.

3. You need an origin story, especially if you want any press. It also helps to be good looking.

Completely disagree with 1 and 3.

Attention is scarce and there are already lots of good alternatives for almost any product idea. You better be good at sales and marketing if you want to cut thru the noise. A good product is not good enough.

Most startups don’t need press - unless you are asocial media app, chances are customers won’t pay simply because TechCrunch or CNN mentions you. They pay to get their problems solved.

Yes, the build it and they will come is missing the ', after you cranked up advertisment/sales'.

Offering my own experiences as a counterpoint:

1. If the idea is any good, you‘ll quickly encounter others who are better funded and need to execute extremely well. „Build it and they will come“ has worked for the tiniest minority or orgs I‘ve worked with and for, it certainly hasn‘t for us.

2. If your original idea is well researched and partially proven or already sold before building, why pivot? We didn‘t regret to sink a tenth of our initial invest into a great domain and brand.

3. True that. If you can‘t put your business model into a one sentence elevator pitch that includes a real-world problem and its solution that someone will actually pay for, din‘t even start…

> If the idea / product is any good, it'll probably catch on quickly and sales will be easy.

I would respectfully disagree with this.

There are a few startups (e.g. Facebook), whose market timing is so perfect, that it's a sure-fire hit from the start.

But I have known so many companies that had founders struggling to make sales, as their timing was off. Then some market shift occurs, and what once was hard becomes easy.

COVID is a great example of something which induces a seismic shift everywhere. Remote work companies for example, would have suddenly found sales an order of magnitude easier.

As an employee learn to manage expectations. You can push back projects with deadlines if you manage expectations early enough. Fail that and you'll have pissed off stakeholders.

Trying to convince managers to do something won't always work. Presenting them with a growing problem and a solution will help convince them.

You might think your product is bad, but there are likely people making more money than you with worse products. Start selling early.

One thing that is now obvious to me but which I had to learn: pricing needs to not only be reasonable and competitive, it also shouldn't be too surprising.

I read and bought into Basecamps reasoning about no-by-the-seat-pricing(1) and tried it for Submotion. Now, it's always hard to know why people don't try your product out, but two people kindly hinted to me that they were confused by the price and thought that it meant that they didn't really understand what they were getting.

Obviously, as with any advice, this applies in specific situations only but it's now something that I keep in mind, not only in pricing: remove any unnecessary source of confusion, even if it's clever. Not unlike code :-)

(1) (https://m.signalvnoise.com/why-we-never-sold-basecamp-by-the...)

- Product Market Fit - find that before continuing to perfect the product. - Market size and especially addressable market size. We learnt it the hard way with children's apps. - Tech is a tool. Unless you are doing groundbreaking research, dont be in awe of the tools (tech), nor let it go crazy expensive. - One needs a deep reserve of patience and strength, you will get challenged in all dimensions. - Sometimes you can do everything right, and still fail.

> - Product Market Fit - find that before continuing to perfect the product.

How are these things non-obvious? Isn't that like business lesson numbers 1, 2, and 3?

Technology isn't the business. Technology enables the business.

Have an unfair and protectable lever from the get-go.

A mantra that actually helps to ship: "good enough" is better than perfection.

Super easy to get lost in implementation. Make sure you take a daily/weekly/whatever review of what you're actually shipping, and if it fits the use case.

Never ever ever ever ever ever sign a deal that you do NOT FULLY (!!) UNDERSTAND.

Including second and third degree implications as far as this is possible.

Know when to shitcan a bad idea rather than death march your company into oblivion by not concentrating on the core business and customers to deliver the bad idea.

Don't try to raise funds. Don't consider it a win to get funding from some investor. Find some way to make money from the beginning without introducing some adversarial entity into your system that turns the CEO from your friend into the agent of investors. It is cool to run the equivalent of a lemonade stand. If you can do that, keep making it a little bigger and better. Make money the old-fashioned way -- don't hope to be acquired.

* This message pre-censored by HN in order to preserve curiosity.