What are some important observations and lessons you've learned working at startups and running businesses that were not immediately obvious (both technical and non-technical)? Did you learn the hard way?
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.
AFAIK Engineers have an axe to grind with the sales department, not actual sales. Giving credit for a sale is a very subjective matter, and more often than not every sales person who so much as sent an email to the opp want credit - effectively taking advantage of the subjective nature as much as they can get away with. Even if in reality the customer had to pretty much talk around everyone on the sales team and speak with an engineer to gain confidence in the product. Then the engineer has to go play catch-up from the 1 hour meeting while the sales member gets % of the sale.
But the important part is to diagnose why you have low or declining sales. Sometimes it's because you don't have good sales people. But other times it's because the product you have isn't a good market fit, or it's really buggy, or your salespeople oversold and now your customers are unhappy with the actual functionality of your product.
So then the sale is made, but in a way that ends up destroying the long (and even medium) term health of the business. Product/engineering goes on a death march to get things done, by the end of it many of those folks are burnt out, customers are unhappy, and sales folks see the writing on the wall and are happy to bail with their fat commission.
It's like saying "do whatever you need to raise your stock price." There are healthy and unhealthy ways to do that, and the advice is useless if you don't carefully distinguish between the two.
Sales are important. However, as you note, sales now should not come at the expense of sales later (or lead to returns later, or etc). And debugging low sales is non-trivial.
Focusing on sales to solve internal problems is like focusing on work to solve internal problems.
It can work to an extent, but sometimes you need to solve the internal problem before you can get the results you need.
So it's a feedback loop that leads to circular thinking. The problem is when we try to blame the external side of the feedback loop, to avoid seeing that our internal side is the problem.
If you need "more sales" to fix it, the problem often lies somewhere else.
no one said hire sales people; rather if you've got a problem, first look at increasing sales before you put your efforts elsewhere. This will either fix the problem or explicitly identify it.
To a founder or CEO the word "revenue" is used where you're using "sales", it isn't wrong except in context but the intention was unambiguous to me.
The original comment which said "more sales"; I've never heard someone in business refer to salespersons with the cutesy "sales" so I don't think it's reasonable to think "more sales" refers to people, and if they meant a larger department they would have said "larger department", not "more (department)".
The comment below that also says "sales fixes everything", which, again, same logic as the original (and has the same author as two below where they clearly say "we're talking sales of things").
The comment below that is the only one clearly confusing sales people/department, with sales of things, "I don't think you can solve it with more sales people".
The comment you're directly responding to said "We're not talking about sales people or the department, we're talking about actual sales of things".
And you're saying someone, other than the person being corrected, 'clearly' meant the department or role? Nah.
Expressions like "A 20% increase in sales" are almost never used to describe an 20% increase in the sales department's headcount or budget. Most people would interpret that as a 20% increase in revenue from sales.
"Cost of Sales (COS)" in finance refers to the cost of making a sale, including all the costs required to produce the good or service sold, not just the compensation and other expenses associated with a sales department.
"Sales" as a noun does often refer to teh sales department, but there are times when it absolutely unambiguously means that, times when it almost never is interpreted as that, and times when it could go either way and a word like "revenue" would be clearer, but that doesn't make using the word" sales" to refer to revenue wrong.
(I’m noticing elsewhere in this thread that others are interpreting “sales” as sales departments or salespeople. Perhaps it’s a cultural thing, where the meaning of the plain word varies depending on where you live.)
Few problems (a/k/a most problems) can be solved with more sales (a/k/a sales as a P&L line item equating to revenue); but OF COURSE its what you do with the increased revenue/sales that matters. Buying a Bentley isn't going to solve the business problem.
Answering that later question can lead you into any direction. Maybe you need more sales people, maybe your product sucks, maybe you must spend more on marketing. The point is not on how, the point is that the later one is the one goal you can have more impact on, and it will lead you into solving the former.
1 - On this case, with higher salaries, but there isn't enough money to increase them, thus the actionable question.
Corollary #2 - Nobody cares. You might love your baby (i.e., idea / product / startup) but nobody cares. At all. See Corollary #1 for more details.
"money brought in" is air that your company breathes. "lies to customers" is poison that your company drinks.
As in people who have broad knowledge but also specific expertise?
Basically, but more like "capable in many areas but an expert in one (or two)".
I'd add: ARR is a metric, cash is king. (related to 2-4 from your list)
While true, unfortunately in many (blue-leaning) states, they're starting to become at the judge's discretion. Absolutely sickening to be honest.
> Couples who have been living together for two years share the same legal rights as married couples in BC, including a 50/50 split of debts and assets—excluding pre-relationship property, inheritances and gifts.
With a rate of 40% for divorce, a pre-nup may no longer be just for marrying couples, it may be needed for any relationship where cohabiting occurs. Also, there is absolutely no chance the judge will side with the men in places known.
One of the reasons for me to consider leaving California.
Sorry to hear that.
> One of the reasons for me to consider leaving California.
You do realize that California is not an administrative subdivision of Oregon, but a completely different state, right?
Instead of HN constantly defending California, I want us to take a hard look at what's wrong with this state and improve it; but I see a bad future and looking out for myself. I want California to be the best place on the planet to live. It is regressing at an ever increasing pace. I was talking to a SaksFifth employee in SF – he is working there since 1995. I talked to him for good 30 mins talking about how things were in Bay Area specifically. It is night and day compared to 90's.
Are you able to mention some of the things he said?
It's required on HN for rich tech guys to threaten this from time to time.
His ex-wife was a trainwreck, they faught and for so long, lost $100k+ in just attorney fees and yet, the Portland judge wouldn't give him a break. I couldn't fault a single thing in his character and offered to be a witness. His attorney did their best to put forth a case, had a psychology auditor evaluate his mental health, everything is flying colors. Still, the judge wouldn't give more time with his child.
FUCKED UP. Makes me angry just thinking about it. It made me realize that there is evil in this world in the most visceral way.
But calling 70 people to get 70 new advertisers is OK, or if it's early days 70 people who can get you some traffic.
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.
I know a startup that failed because they thought they were doing ok on sales, but it turned out: lots of people were signing up for the product, but then not using it, or not being able to, and un-signing soon after.
10. You're only as happy as your wife. If she's unhappy, you're unhappy.
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.
You might familiarize yourself with Rule #6 before commenting on Rule #1.
Read the original point. The OP is not saying sales globally optimizes all things, like how your sales department is organized, rather it mitigates (i.e "fixes") the problem. All your other points are secondary, and definitely don't hurt as much if you've got lots of sales.
Larry Ellison of Oracle definitely fails rule #6 but he gets at least one big thing right. There are only two roles: You're either building the thing or selling the thing.
I've seen companies where more sales has amplified the problem
EDIT: I use Sales as a shorthand for "Salespeople" but OP use Sales for "revenue" maybe ?
Yes, definitely.
The venn diagram of tech skills and a non-tech business is where the opportunities are. This applies to many other unrelated skills.
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.
Except tanning salons (or hairstylists or dog walkers or plumbers) usually a) dont have cash to spend b) Dont see their problems as software related c) are in many cases hostile to software, due to geniune bad software
I remember some time ago when I used to hang out in bootstrapped.fm, every week a person would come in and say "Oh I built a software for salons/hairstylists/dog walkers" how I can sell it? 4 weeks later they had shutdown their business, and a new person would come in, rinse and repeat.
This is also why this (very good) advice is not so easy to follow in real life. You need multiple skillsets.
Guy owned two carwashes in Cary, NC. Thought technology could enable mobile carwashing. Got connected with the right technology people ...
If you're not as well placed as the incumbents at the core product (salon, sure), software will not save you.
If you're better placed than the incumbents at the core product, software doesn't matter.
If you're (roughly) equally placed as the incumbents at the core product, software can help you, but it will likely take a while to realize any competitive advantage.
And, I say placed, because there are a lot of factors at play. There's the quality of the service/product (itself a huge set of variables), pricing, location, and availability, to name a few. None of those will custom software directly help you with.
Not for me; it has to be sexy, world and life style changing. I’d rather build something like one of the top used apps or just be an employee at a tech co.
Good if someone can pull it off. But, I believe that company might have sold that feature as an add-on to their existing customers. Otherwise, you know “Sales” are the hard part
That's what I also meant. Even if you start a business, the features that your product would have, will be sold as a "solution" - in layman's terms.
Why we are talking about low-hanging fruit instead of picking them up? I have a hunch they aren't low hanging after all.
The reason for that is the same reason your idea works, most businesses outside the tech bubble stand to gain a lot form software. Currently they have no way to act on it except to hobble together a ruby goldberg of SaaS services or try and cram their businesses into a monolithic piece of software that expects your business to run a certain way.
Most mid-sized companies don't have the skills to manage and deploy software developers that can solve their problems. Those skills tend to be expensive, and the software project, historically, has a high chance of failure.
So, yeah, the high price of tech wages seems to be correct.
The answer that I think is a hard pill for some to swallow, is that for a long time we have been the tool required by special kinds of high return business ventures, so we can command high wages. The same is true of remote miners in Australia, the difference is there is no use for a miner in the rest of the community so there is no loss since no one is competing for their wage anyway.
My argument is simply that the rest of the economy could really use software developers, but they are too expensive due to the distortions on commandable salary that the tech bubble has created. It would be nice if software developers returned from the high heavens and integrated their skills more readily with the greater community.
I am a software developer, and I understand the audience I am talking to is the very audience benefiting from the status quo. I don't expect it to be a popular view but I do hope people give it a thought. Think of ways your talent could help your community, and then that is what I am hoping to see more of.
Another way of saying the same thing is that few businesses can see their revenue double by employing even the most skilled plumber. However, many businesses can see there revenue double (or their costs halved) by employing even a mediocre software developer.
So, I would agree it's true that we live in a special time in history where the translation of business needs to computer languages is being demanded at an ever higher and higher rate. But I would disagree with the framing of this phenomenon as a "tech bubble" or a "distortion on commandable salary".
Employing a software developer IS expensive. <- agree
Employing a software developer is TOO expensive <- disagree
- Existing problems get solved.
- New, more important, problems emerge.
- More developers enter the market (bringing down the
cost of development).
- Consumer demands shift over time.
How many of these companies will be around in 10 years in the same form that they are today? Ford has been making vehicles for over 100 years. What will give Meta, as an arbitrary example, that kind of staying power?
As those companies come and go over the next 10-20 years, I think your concern that "the rest of the economy could really use software developers" will be ameliorated. Maybe everyone's actually working on unimportant problems right now, and the wider economy has more important problems for us to solve, but the best and fastest way we've figured out how to discover that we've misallocated resources (whether human or any other kind) is to let everyone make their own decisions and realize the individual gain or loss of their decisions.
I speak from experience in executing some of these kinds of software projects, as I live in a market not influenced by the SV bubble. Our market has a bunch of bootstrapped software businesses too, because the economics of it are more favorable to that kind of enterprise and you're not competing with 200k+ wages. I'm talking about Australia as well, an expensive first world country.
In fact, going into some market and solving a problem with software is almost always done by people not used to work in development that go and write something by themselves.
In practice the most common option is to have everything run on massive Excel sheets, with spaghetti formulas and VBA coded by long-gone employees or interns. But it works.
If you sell through a channel, that channel is your customer, not the end user. They have needs and actually those needs (not desires, needs) are more important than the end users' -- if your channel doesn't sell the product it doesn't matter how much you've worked to add that end-user feature.
Have the entire exec team go on a sales call once a quarter (not all together on the same call!). They don't have to say anything in the call (in fact it's much better they don't). I remember a CFO I told to go on a sales call telling me it was the first time in his career he had been in front of a customer, and that he really had had no idea what the customer thought about what we did. It makes the team far more effective.
Don't allow inter-departmental sniping. We all know it: sales guys won't sell the product and always want stupid one-off features; engineering is lazy and won't write what the customers actually want; marketing is just lying all the time. Instead make sure everybody understands that without sales folks, no paycheck. Without engineers, the sales folks have nothing to sell. Without marketing, who will know that they need our product, and how can we prioritize which features to build? That mild-mannered A/R clerk is the real difference between paycheck and no paycheck.
Don't do free pilots for enterprise. There's always someone interested in new products and technologies. If they can't put some skin in the game they aren't serious. Ideally cover your costs, but in any case make sure the number is larger than the person you're talking to is automatically authorized to spend (this means they'll need to get some buy in, PO, contract etc). They don't have to give it all to you up front, they just need some commitment and desire to do business if the pilot works. And they have to give you some payment up front, a meaningful amount.
Don't have one customer be all of your revenue (ideally don't have one customer be more than 20% of revenue). Edit: note that Google has this problem: 80+% of revenue is advertising, and Google is a large part of the overall advertising market. They have been trying, and failing, to fix this for more than a decade. This is a case where you want to be able to say "we aren't google".
Don't go in too high in the organization. If your first call is to the CEO and you convince them to try your product, it will be handed off to someone who likely only cares because the CEO said so, and would be quite happy to screw around a little and then tell the boss "yeah, we looked into it but it didn't work out". Follow the standard enterprise sales playbook and go in at the right level and find your "coach": the person who is committed to getting your product into the company because it will make their life better (perhaps promotion, but at least better execution).
This is for when you are bigger: If you work with another company, and your company meets with their CEO, your CEO should go to that meeting. Until you're Apple-sized, always treat your partners and customers as peers. If not, why are you working with them at all?
A friend founded a startup which licensed software to the first generation iPhone. He still has a copy of the voicemail: "Hi. This is Steve Jobs...from Apple..."
A case study from last year. I'm on a board of a company that had a small product under way but got excited by a much larger market. They even got a customer who paid a small down payment (~75K). So they spent more than a year developing the new product (several engineers on staff) in close partnership with this customer. We board members kept urging the CEO to find a second customer but he was more interested in engineering than sales. You can guess what happened: after a year the customer declined to make the second payment of ~75K. So I called the customer and he said he wouldn't pay but would just buy the company for a pittance (less than had been spent on development). The board declined, and as I predicted the customer attempted to recruit the development team, so we just fired the customer. He was quite irate because he had built this into his own development plans, but fuck him. The one fun part was that he couldn't re implement what he needed himself as we had patents they would need.
If that wasn't bad enough, the customer's use case was quite specific and not adequate for the broader market. So further development was needed (development that would already have been done had there been marketing and product management) before the company could even try to enter the market.
In the end I had to come in and do a restart and spin out. A regular starup would have died.
It doesn't have to be as bad as that. But a big company can be committed to you and then cancel a whole product for whatever reasons that have nothing to do with you.
And I wasn't kidding with the Google example. They have struggled to develop new lines of revenue, even pulling puny old Nest back onto their balance sheet for an extra percent or two of non-advertising revenue. With a more diversified revenue stream wall street analysis would drive the stock price up. If there's a secular change in the advertising market they really would suffer. So this advice isn't just for startups.
What's A/R?
Our A/R clerk explained what she did. She managed to get almost everybody to pay on time (cough not the assholes at Sun though). Her avg was something like 35 days (we wrote everything net 30 or less). The next quarter she reported that she'd gotten the average down to something like 23 days, and got a standing ovation! For a ~60 person bootstrapped company that meant a lot, and this exercise meant everybody appreciated her work.
To make matters worse, I have seen A&R being used to mean "Accounts and Receivables", which is just WRONG (except in the context of tertiary education institutions).
- Your competition is not better. Even if your competitor has 1000 employees, that doesn't make them better, they more likely work a lot slower and less efficient than a smaller company. Also, a big company is more likely to ruin a perfectly good product trying too hard to squeeze profits.
- If a customer wants a refund, just accept it, even if they try to scam you. Often times, the trouble of trying to convince a customer not to leave is not worth it. Also, if the customer feels trapped, they are unlikely to buy from you in the future.
- Brings clarity to your relationship: "If you aren't finding value in the product, or think you can find better value elsewhere, you can leave at any time." - Keeps you honest. Because you can't hide your failure to deliver a valuable product behind contractually-obligated revenue.
I'm not against contracts at all, and the larger your customer or the more involved your customer relationship gets, the more necessary they become, but even in bigger engagements I shoot for the contract to be payment up-front or in regular installments with easy offramps should the customer stop seeing value in the engagement. The important bit is that if a customer wants out, you should let them out, and it should not cause _you to lose any money or any sleep_.
I don't know how widely applicable that is to other businesses, but for mine, it's a helpful way to structure the relationship.
But I do offer a 30 days free trial.
Doesn't work for lots of businesses, but where it does it's quite nice.
A bad client can poison a company culture with their own problems and cost more than money.
It's as important to have good clients as it is to have good employees.
- 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.
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.
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.
You can stay around too long - I stayed following an acquisition of the company I had co-founded and other co-founders left. Was an utterly miserable experience winding down the team I had spent years building up.
Thank you for saying that. I would also add that being a solo founder has many advantages including avoiding flaky cofounders and dealing with painful equity negotiations.
I've noticed this mechanism, but how do you go about it strategically? Which exercises or workflows can you use to determine how much to borrow and when?
maybe not letting people coming to work drunk? Or forbidding drinking while at work?
Hamming, as always, is quite insightful.
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.
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.
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...
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.
Sales fixes everything and is the hardest thing.
If sales can execute then there is no problem. It seems obvious but it's really not and people make the business about the mission and product - that stuff is secondary seriously secondary.
As a founder and early employee - you need to know if you can execute on sales or not and make it clear to both yourself and your coworkers.
Sales isnt something you can learn to do my biggest lesson is i cant do it no matter how hard I tried. If your employees / boss / cofounder are not closing sales you seriously need to get someone who can as your companies top priority.
Closing means money in the bank and nothing else. Paper is meaningless.
A contradictory learning is the best startups I've been at are ones where folks are ideologically fanatical with mission.
Strongly disagree. There is a consistent overlap between strong technical folks and skills/personalities that make it more difficult to learn to sell, but you can absolutely learn it.
Now, this is highly subjective, but I think the general lesson applies: Programming language choice is important for culture.
Charging more: 1) gets rid of most toxic customers. 2) increases customer LTV which allows you to spend more on acquisition or get more money for the same marketing cost. 3) helps you pay employees more which makes it easier to hire. 4) helps you pay yourself better which makes it easier to meet your non work needs. 5) can position you better in the market as many people see "more expensive=better" even if it isn't true.
More businesses fail for not charging enough than charging too much, so you should charge more despite the imposter syndrome in your head.
This is terrible, bring value by providing good work and CHARGE for it. People will respect you more, you'll have more revenue to buy tooling, hire better employees, build better products and do R&D on the next step. If you don't have the money, your customers will suck you dry, and you'll never get to build anything new.
There's a limit of course, but figure out what that is and approach it.
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.
- Always be hiring. Every person you meet, always be fitting them into a hiring pipeline.
- You have to be 360-degree. You may focus on areas that are core competencies but you cannot 'divorce' yourself from areas you have no idea about. You need to upgrade and have meaningful discussions with folks you put in positions of responsibility.
- Dont wait for the perfect person to show up! Start with whoever you get, often folks you did not think much of will surprise you.
- Be clear about redlines and communicate them clearly. If people violate red lines, let all hell break loose. Else be nice and chill.
- No one shows up to work and says 'ok let me do the worst possible job today'. every one does the best he/she can in their personal contexts. if it is not enough, communicate clearly. help where can.
- Be transparent with your team. Be fair to them. These are still valued.
I'm not saying you need to become the "boss from hell", but you should always maintain that arms-length relationship.
It is inevitable that one day they will let you down or they will withhold information from you or any other number of things. If you did not maintain the arms-length relationship with them, then you will take it personally and it will be painful.
There is truth in the old saying, don't mix work & pleasure.
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!
A very sad reality :(
My #1: Get really good at user testing so that you minimize risk every step of the way. I can't say this enough as it has totally changed how I approach startups, new features, and core assumptions (and weirdly my personal life).
My #2: If you have co-founders, make weekly rituals to ensure you stay in sync over everything else. When you get out of sync, bad things happen. This can also be applied to investors, board members, spouses, etc etc etc...
My #3: If you are making a bet write it out in detail about what the bet is, what the assumptions are, and then write in detail why you are doing each piece and examine it from multiple POVs. Writing that down over a period of weeks ensures a good thought process most of the time. Write it out as if you are giving a presentation. This has helped me in so many ways.
Those are the big ones that have been huge with startup/business/life.
Step 1: Buy 3 to 4 books and read those -> https://shepherd.com/best-books/understanding-user-research
Step 2: Map out one, do it, and instantly you will understand the power and how to do it better. Then just keep evolving. I am so much better at doing these now than when I started. I better clarity of what I am testing and how to ask to ensure non-biased answers.
ie, read and just start doing it.
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
- there is no substitute for solid user research (no competitor research, sales, marketing, ...); you need to understand the clients journey before you can start to think about how to add value
- the emotional journey of your client is the only thing that matters
- get rid of everybody who doesn't understand that; you want the organization to value making your (potential) clients happy and look beyond the numbers.
- your cash cycle will dominate your life, don't start a business without understanding rough CAC and earnback times.
- competition is not just companies that do similar things to you; it's every possible alternative way to solve the clients' problem. Make sure you actually have an advantage.
- seniority is the ability to deal with uncertainty; some people are senior just by their attitude alone and teach themselves how to succeed. Others will always ask for more definition and are terrified of admitting they don't know something.
- only senior people add value to startups; you can bring in more junior people when you are a scale-up and there is a lot of clearly defined work to do.
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.
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
The wrinkle here is that it's not always obvious what projects will create business value. Unfortunately, if you're not in an organization with deep pockets and a long time horizon for projects to succeed, it's almost always a better business decision to work on projects that have a direct link to creating business value.
2. Using a technology because [insert large successful company or startup here] uses it well at scale is almost always the wrong decision for a startup. What works for Google, Meta, Uber, etc. will likely not work for your startup until you reach a certain critical level of scale.
3. Headcount is vanity metric. If a company is proud that they have a large team, you should probably run. Employees cost money and employee salaries count toward OPEX vs. CAPEX. What matters is revenue per employee, but many startups are pre-revenue.
4. Scaling your organization or technical stack before you have product market fit is a waste of time. Silicon Valley history is littered with dead startups you've never heard of that burned through their runway building over-engineered systems designed to scale to meet the demand of users that never came. The same is true of startups that built out massive sales departments before they had a product that people wanted to buy.
2. Know when to ignore criticism
3. Communicate directly to your users (Your users know what they want more than you do, it’s easy to control the project based on your preferences, but it’s not always the best idea.)
4. Stay organized Having emails, files, spreadsheets, financials, etc with a solid organizational structure will save you later.
5. Keep backups.
2. Someone who is difficult in good times will be a monster in bad times
3. Repeating the words of other's back to them is eerily effective
4. Every client is in the middle of some sort of political drama, you will be some minor part of that drama - this is normal and not that meaningful
Research before you build anything. If there’s no need for it, don’t build it.
Choose your business partners wisely. Don’t fall into the trap of working with smart assholes, if someone is an asshole - no matter how smart. The asshole-ness will take over no matter what. (That’s just one side of it, many other things to watch for).
Build trust, it takes time and effort to get this one right.
Put your name on your work. One of pg’s essays also mentions how putting your name on your work let’s society reward you. I’ve seen it happen in front of my eyes. The product with a UI that looks bootstrapped together is like magic for your customers. No matter how basic or “ugly” your think your product might be, stand beside it like it’s your first born.
Investors will want you to build technology to inflate the company IP and worth, but will leave you when you fail to bring in profit due to focusing on tech too much.
You can always expand your target market over time, but start where you are strong.
Everyone understands this in theory, but it's hard to do in practice, because I think we have evolutionary aversion to "scarcity". So instead of thinking of it as "small vs large" market (when the small market is plenty to start with), think of it as "easy vs hard" sales and marketing. If sales and marketing is hard, shrink your market.
Yes, shipping faster means you get feedback faster. But shipping faster also means you begin customer support faster. The moment customer support happens is the moment that your development focus shifts from deliverables to bug squashing, making tweaks and balancing priorities. The moment that the system has live data is also the moment that you have to make sure any changes to the system can smoothly adapt the data that's already in the system.
The moment you ship, all of your development is going to slow down from the side effects of shipping. Slogans don't have nuance.
Ultra-successful startups are actually caught by some wave or catch the market at the right moment -- the business takes off and the team is trying to catch up to it.
It's possible to create that momentum, but you need to really understand your customers/market so you can make sure you're focusing on the right things.
Focus is about saying "no" to everything else. You don't get focus by saying "yes" to the thing you want to focus on.
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.
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...)
If your output requires direct labor, it IS possible to sell your way into a death spiral because labor is short-run inelastic.
Know your experience curve and know where you and your competitors are on it. If the curve has flattened and you're not the winner, find a new curve.
Be crystal clear why your business needs to exist. Not why you think it should exist. Deeply understand the customer pain points, business domain, competitors, and find your niche. Sales and product development get easier with this.
Deeply understand your cash flows months in advance. Identify warning signals sooner rather than later. Things won't magically get better, act now.
Stay organized, stay focused.
How are these things non-obvious? Isn't that like business lesson numbers 1, 2, and 3?
The sad thing is that the boss is right.
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).
Before going to a startup I would tell everyone to read this post about liquidation preferences and cap tables.
Why didn't I get any money from my startup?
https://www.reddit.com/r/startups/comments/a8f6xz/why_didnt_...
Who invests money? What about the second round of investors? A lot of people think that the people who were their the longest should have priority but it is the exact opposite. The people who invest last get the best deal on a return on their investment.
Ask these questions to the founder / owners of the company. If they don't answer your questions directly take that as a sign that they won't be truthful and straightforward when you are an employee.
Including second and third degree implications as far as this is possible.
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.
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.
The talented person that built the thing knows exactly what a change will require, and how to test it before pushing his code.
Don't be an enterprise too soon.
The opposite. Tests are for people who know exactly how the product works. It's very hard to write good tests if you don't understand the product (or at least your piece).
I really hope you are being sarcastic. Tests when done properly speed up development and make your product more robust and resistant to breaking changes.
For a proof of concept that will never see production, sure, by all means don't write tests. But in my 15+ years in CTO and Principal role at smaller companies, the most expensive projects with the most downtime are always the ones without tests.
Tests make software cheaper not more expensive. And the ROI isn't even that long... all it takes is for two to three iteration / release cycles.
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)
It doesn't get sharper if you sharpen it indefinitely. You'll be wasting time and metal.
There's always a point of diminishing returns. Just get the tree down, because another task is waiting.
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 with each project. I know it because I went through the same phase in my career. Good luck!
The only reason why this becomes a phase that burns developers out is that writing high quality software is hard, under-appreciated and needs to be painstakingly learned by experience and guidance by experienced mentors. But most projects in the industry are complete shitheaps where the seniors need to spend all their time fighting fires instead of teaching the craft to juniors. No wonder developers get burned out.
You're hitting the nail on the head about burning out though. I suppose it's just the way the cookie crumbles.
Thanks for your awesome reply! Means a lot to me! Let me dive along! To make this discussion more interesting from the start, I'm going to say that we managed to raise $2M with an MVP written in 4 months, and now I have to rewrite everything because the business team pivoted 180 degrees. Bear with me a little.
> 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.
The only failure I feel is that I haven't really managed to employ the right people for the right job. This forces me to take care of everything - really, like I have to refactor Typescript interfaces or CSS for other people, which are trivial things but time consuming. On one hand, I have to move fast and deliver features as a team, but on the other hand, I have to teach people how to properly do their job.
> 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.
The expression 'building cool rock-solid code' might've been just me venting my frustration - it's not that hard to do a good job it if you know what you're doing. But you're 100% right: I'm wasting resources if I don't implement the business needs in a timely manner. I actually managed to pull that off before raising the money.
But I'm also aware that difficult problems have more than ordinary solutions. I took care of our infra, from Proxmox, docker, Google Cloud, Jira, Confluence, Cloudflare, to Slack, emails, Jira, Confluence and others. The business team just says: "we could've employed anyone to do that".... really ....
> 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.
Actually you're right and this is the reality. IMO, I see the grand scheme of things, where I know what "should" be done, so we could attain 100% autonomy and be able to scale without coding anymore, whereas the business team needs some features NOW, forcing me to do shortcuts. This is why I'm pushing to build a roadmap, but it's obvious we cannot do it right now.
> 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.
We have 10k users, we have the market fit, we have the funding. The only problem is that I built everything for a specific business case, and now I have to abstract it to support the previous business case, plus new others, which are completely different. It's like building a new product from scratch. And my pain is that we could've thought about it from the start - this would've allowed me to abstract some of business logic.
> 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.
Exactly, no plan is going to be perfect, and we're constantly iterating over it, but we didn't allowed ourselves to start this damn plan from the beginning. We thought: "let's do it, see what happens. Wow, it worked! Let's do even more now, and be backwards compatible"
> 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'.
EXACTLY! We had poor product and domain knowledge - basically we built our way without having a good sense for them. The code is flexible enough: monorepo with apps and libs sliced and combined in separate packages, while trying to follow 12-factor-app methodology as much as I could.
> 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.
This is where the friction comes inside the team. I want to plan as best I can do it, and then just execute. Talking about my experience, I was employed in a German project where people actually took their time to plan thoroughly, at a point where they knew exactly what people they needed and almost the exact buget for the whole thing. And it was a joy to code and do your thing. In retrospective, looking at this German team, they really knew their tools and craft.
> 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 with each project. I know it because I went through the same phase in my career. Good luck!
I've been using solutions like Supabase, Hasura, n8n, Prisma, just to move things faster. IMO, it all boils down to understanding the product and domain. Then the table schemas, data structures, interfaces, services, etc, will start fitting into place. In my case, they still do, partially, but I could've done a better job at abstracting them from the first place, rather than patching or rewriting shit at this point. I'm lazy.
My takeaway, even it might sound childish or wishful thinking, is this: 1. I won't start a startup with non-techincal founders anymore 2. I won't touch a single line of code if I don't understand 100% the product and the domains 3. I will strive to employ only the right people for the job and I will document everything from the start, so the onboarding curve would be low 4. I will enforce best practices, standards and internal protocols when it comes to writing, testing and deploying code. 5. I don't want to think when I read code; a quick glimpse is what it takes: looks good, passes tests => OK 6. I want to be able to delegate as much as I can, without fearing that quality might suffer 7. I should follow my guts and speak louder when the business team wants the Pyramid of Giza - at a point looks like a challenge that I accept, but then it translates into lost nights for myself.
I might be biased, I know I'm not that experienced yet, I know there's no such thing as a perfect world, but I can strive to achieve that. Maybe I'm just venting - nonetheless, it's still possible to build a product without having a gun pointing at your head.
What do you think ?
Clients rely on you and you need to be a solid rock.
Eventually you will make enough money to spread out the work with employees. Until then your on call in every sense.
Also, just don't do that anyway. It was a total waste of time, focus on legitimate grass roots sales activities. I thought I might as well give it a go, as they said they'd get the app on ProductHunt and so on. I was skeptical of that, but no harm if it doesn't work. It didn't work and it was a generally scummy experience, and some of the submissions they made on my behalf were very embarrassing for me. Wrong place, wrong tone, wrong words, that kind of thing.
If those needs solve one or several problems, great, but my main focus is to create products that people need, or once they use it they adopt it because it became a neccessity. For those interested I extended my rationale here http://minid.net/2019/07/30/on-building-products-for-necessi...
Either you're dealing with someone honest, or not. Seems simple, right?
But, there is a third option. Sometimes someone will earnestly and honestly make a commitment, but then later on they will not see themselves as being obligated to follow through, or they will rationalize some reason they don't need to meet their commitments they've previously made.
At first, it feels natural to loop in people who are both trusted and technically skilled. Plus, talented people tend to enjoy being friends with one another.
It will feel serendipitous when - one day - you need an experienced React engineer and your roommate happens to love React.
If you care about being friends in 5 years, your optimal path is to ask your friend “who else do you know that may be interested in this role” and not “want to work on this with me?”
1. Just because others are making money, doesnt mean you will
2. People like, and show a a very small part of their success. "Oh I just worked 70 hours, helped the community, they gave back to me". Not mentioned will be their friends who secretly helped promote them, their rich daddy who bankrolled them while they worked on the "startup", or the dodgy things they did to get sales.
3. Its hard whatever field you choose, so make sure you choose something you love, else you will quit at the 1st sign of trouble.
Many founders start applying methodologies and hiring for roles they know from other companies, even though they're not at a scale that justifies it.
New hires don't know how the system work. Don't know the day to day operation or use cases. Never assume they'll just pick it up.
Have periodic exercises where people use the app from start to finish. Have people take on other roles periodically.
I see a lot of brilliant engineers build amazing things that don't help the company. Get them invested in the day to day usage of the product so they know when to push back on pointless ideas.
Invest in your employees' job satisfaction. Keep growing them, and make them want to stay. There is really very little value that doesn't stem from seasoned human capital.
Always be selling.
Surviving is succeeding. Make more money than you spend.
read this : https://basecamp.com/shapeup
Find a LEGIT accountant. Expense everything.
FIND health insurance ( if it means getting a part timer for health insurance)
hire 1099s
there will always be bugs.
Set up an alert to be notified if your site go's down.
Workout daily. Go outside walk. whatever find something MOVE your body.
Good lucky.
*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.
And when you're leaving, if the company suddenly feels compelled to grant you more stock options, or increase your salary, keep walking away.
It is 100x better to have one or more clients with a need for your product. This means don’t dream up something first and build it. First find the client then build the thing.
Whether it is implemented features or design choices (e.g. product logo, etc.), the more people you ask, the more differing opinions you will receive.
2) Diversifying business is nice, but diversifying businesses is nicer.
Things I learned from my dad and grand parents.
1. Being decent to people will cover all kinds of other problems.
2. A great reputation for doing good work is probably the best sales tool to have.
3. You can pay your people well if you charge premium rates. (and do premium or higher quality work)
4. If you pay your people well you just have a generally happier work force.
5. If you trust your people you don't have to micro-manage them.
6. Giving trust to people can be hard sometimes when things don't go well. (but you need to keep doing it anyways, even when you get taken advantage of from time to time)
7. Hiring mature and decent people fixes a lot of problems in advance.
8. Having a happy work environment is more important than efficiency.
9. The higher up you are, the first you are to take a pay cut, provides respect, stability and confidence in the rest of the company.
10. Don't beat up your vendors on price, and when things get rough, they will take care of you.
There is a lot more.
Me personally:
1. Being technically minded I had to learn to just hang out and talk with people. This was hard because I felt it was inefficient, but the long term, knowing people personally helped when there was difficult technical issues to solve while working with them.
2. Don't make changes to other peoples lives without consulting them first or at least giving them notice (if they don't have a choice). Changes to software, their computer, their job role, etc... Too many horror stories about this kind of thing really frustrating people. Thankfully, I avoided many of these issues by learning from others before making these kinds of mistakes to often.
3. It can take time to really understand a customer or a business. It's just hard to be patient as a technically minded person to sit and understand why something is done when it seems to be done so poorly.
4. Everything doesn't have to be fixed. I thoroughly enjoy fixing and improving things, but sometimes it's just fine to let something be clunky. Why? Because sometimes that clunky thing will stay working under every possible difficult circumstance, and an efficient issue requires calling me when it breaks...
5. Stand down. I've had to give up on very important issues because it would have had too much impact on other people. I wanted to fix product ids because they were based on a 1980s limitation, but the fight to win this change would cause too much turmoil, so I let it go, and I am glad I did, because I never really had to use these product ids myself anyways, and my concerns were theoretical.
6. Patience on change. I've found that when I see something I want to improve (from sales processes to manufacturing to IT related items) that if I bring up the issue to those involved, offer some ideas, and then leave it alone. When everyone now knows there is a solution waiting in the background, they start to notice the issues more keenly (instead of the frog in the pot) and then when they've had enough, they will be motivated for change instead of me pushing people towards it.
OTOH, if Ford had asked people what they wanted, they'd have said "a faster horse". And there's risk of taking the stated needs of your most vocal customers as representative of the whole.
As with everything, there are tradeoffs / counterexamples, and knowing which applies when is more art than science, and usually involves some luck.
@armc's first point "Few business problems can't be solved by more sales." is important, but here is a case where it doesn't work (on the contrary).
I once (indirectly) worked for a startup whose business model was basically to rent expensive hardware to its customers. It was considered a rising star, but here's the problem: it had exponential growth. That meant exponential capital needed to buy hardware.
It was considered a rising start, most of its metrics were incredible. Given unlimited access to liquidity it would have easily IPOd by now. But there is no such thing, so it crashed and burned.
(The product still exists but they took measures to address that problem, and the growth is hardly what it once was.)
2. Money doesn't exist until it's on your bank account.
Another startup I worked for (you might guess which one) raised a round with a new fund as the lead. For various reasons that fund couldn't give us the money for a whole year and that locked the other funds as well.
That startup was selling hardware. With no money in the bank we couldn't pay the factory or shipping. We had endless pre-order lists. When the money finally arrived, we had had a whole year with basically no sales, and that ended up being fatal.
3. Some customers aren't rational and that's fine.
At a startup I worked for some time ago, a customer bought an expensive yearly license for our product and never even used it once. At the end of the year, they came back... and renewed the license. I think we actually asked them if they were sure, and they said yes. They didn't use the product for yet another year.
4. Only found a company if you understand the field.
That one is from my experience as a founder. I was the technical co-founder of the company but I had no previous experience or knowledge of that specific market. I thought that was fine because I had a great co-founder who did and very serious partners, so I could learn as I went.
As it turns out we realized quickly that all our initial market study had important flaws an our assumptions didn't hold. We then went into a mode where we tried to figure out if we could turn the company around or maybe pivot, and that was a very frustrating time for me because I felt powerless, not having the necessary knowledge to help like I would have wanted to do.
Thankfully I had enough experience with other businesses to look at the metrics and figure out a few key things. Eventually we shut the company down and it was the right decision, but I will never again start a company in a field I don't know well.
5. Everyone on support.
I have done support one way or another at every single company I worked for. At the company I currently work for everyone works L1 support in rotation and I strongly believe it is a good thing. It will ensure everyone talks to customers and is aware of their pain points.
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.
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.
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…
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.
* This message pre-censored by HN in order to preserve curiosity.