Ask HN: Important nonobvious startup/business lessons you've learned?
255 comments
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.
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.
I want to emphasize an important distinction between Actual sales, and the sales department. Actual sales fix problems, the sales department may or may not be relevant to what causes that to happen.. although they will surely fight for the credit either way.
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.
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.
Yes, but I feel this is somewhat of a tautology: of course lots of revenue makes things easier.
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.
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.
This is encapsulated by that simple statement. Do whatever you need to get sales.
I disagree, and that's why I responded. I've seen too many "we'll do whatever we need to do to get sales" turn into salespeople making unrealistic promises on impossibly tight deadlines.
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.
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.
So I think both of you are 'right', but you're choosing to interpret, and argue, the statement from different perspectives.
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.
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.
Nailed it.
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.
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.
I don't know... I might be having a reverse-survivor bias seeing, being in and contributing to failure, but I've _never_ seen a case where "let's increase our sales headcount" strategy actually did anything (EDIT: i.e. when things are bad. Of course, if things are good, sales is a key driver to growth)
If you need "more sales" to fix it, the problem often lies somewhere else.
If you need "more sales" to fix it, the problem often lies somewhere else.
>> I've _never_ seen a case where "let's increase our sales headcount" strategy actually did anything
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.
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.
Yep! Totally agree. This is good advice.
I meant “sales” as transactions, not “sales” as in the department or role.
The commenter with the advice clearly mean "sales" as the department or role.
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.
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.
So in the comment chain we have -
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.
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.
It's ambiguous, and not that clear-cut.
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.
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 believe the word revenue was simply elided in this case. i.e., parse as “sales revenue.”
(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.)
(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.)
IMO "sales" in OP referred to revenue generating transactions.
OP here... I didn't realize how literally the words would be taken, so:
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.
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.
"Sales fixes everything" means that when you look at any random problem like "turnout is really big, how we can keep people for longer?"¹, often the fastest solution is to answer "hey, how can we increase sales?".
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.
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 #1 - Marketing /sales is hard. Relative to tech / code it's at least 10x more difficult. Code / tech v human behaviour?? Which is easier to predict and sort out.
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.
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.
Unless the product you are selling is defective.
Look around, we're surrounded by defective products. Not just in software either. That doesn't seem to stop them being sold.
There are always bugs. Turns out almost all customers are ok with bugs.
I wonder how many dev teams exist that think their product isn’t defective.
That can sometimes be fixed with "don't walk there" stickers and/or ignored.
Good sales people are critical to success. Most sales people aren't good, pick them with care.
The goodness of salespeople is measured on two orthogonal axes. The one that everyone pays attention to is "money brought in". The one that is hard to evaluate is "lies to customers".
"money brought in" is air that your company breathes. "lies to customers" is poison that your company drinks.
"money brought in" is air that your company breathes. "lies to customers" is poison that your company drinks.
Hire sales people 2 at a time. If you hire just 1, they will have an endless list of reasons they aren’t making sales (product doesn’t demo well, not enough marketing, bad leads, etc). sales will always say this, but with more than one, you can tell how real of an impediment to closing deals those actually are
This applies to nearly any team, you ideally always want to have 2+ people at similar levels competing for the promotion.
All excellent advice. Damn - I'll just skip that MBA now! I'd expand #9 a bit:
9a: Don't hit on your co-workers
9b: Don't sleep with your co-workers
9c: Don't date your co-workers
>7. Hire and retain "T-shaped" people. In difficult times those employees execute across multiple domains.
As in people who have broad knowledge but also specific expertise?
As in people who have broad knowledge but also specific expertise?
> 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)".
https://en.wikipedia.org/wiki/T-shaped_skills
Basically, but more like "capable in many areas but an expert in one (or two)".
https://en.wikipedia.org/wiki/T-shaped_skills
Great lessons, all.
I'd add: ARR is a metric, cash is king. (related to 2-4 from your list)
I'd add: ARR is a metric, cash is king. (related to 2-4 from your list)
11. Get a prenup. No, really, do get one.
While true, unfortunately in many (blue-leaning) states, they're starting to become at the judge's discretion. Absolutely sickening to be honest.
While true, unfortunately in many (blue-leaning) states, they're starting to become at the judge's discretion. Absolutely sickening to be honest.
was just going to mention that prenups really no longer carry the weight that people think it does. For 2 years, whether you are married or not, exposes you to the same liability a married individual would face in the event of a break up here in BC which is crazy.
> 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.
> 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.
Oregon state has destroyed my good friend’s entire life. Child taken away, only get 4 hours a week of time with his kid. My friend is smart, kind and nicest person you’ll ever meet. Personal net worth fucked.
One of the reasons for me to consider leaving California.
One of the reasons for me to consider leaving California.
> Oregon state has destroyed my good friend’s entire life.
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?
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?
No, I didn't know California was a separate entity. But, what I know is that it is worse than Oregon.
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.
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.
> It is night and day compared to 90's.
Are you able to mention some of the things he said?
Are you able to mention some of the things he said?
> One of the reasons for me to consider leaving California.
It's required on HN for rich tech guys to threaten this from time to time.
It's required on HN for rich tech guys to threaten this from time to time.
Quite presumptuous of you to assume that.
You can check the HN guidelines, it’s right there:
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/newsguidelines.html
In the context of divorce court fucking over men, California is by and far the worst in the country.
Did he have a prenup?
No, I don't think so but my memory is a bit hazy, this was around 2013 time frame. All I remember is that he would prepare, spend a whole week planning for things he would do, and when the kid was with him, he'd most sincerely enjoy those 4 hours, every second of it. Makes me tear up just thinking about it.
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.
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.
A good prenup is a reasonable/minimalist one. The more aspirational the prenup, the less likely it is to be enforced.
The sales thing is super important but the channels and investment really depend on the type of business. B2C won't scale with phone calls you need marketing organization.
Scaling sales is a very different thing from getting sales, and I'd argue you won't know how to scale until you find a channel that works but is not cost effective. Otherwise you're essentially shooting blind, but at scale, which doesn't hit much but uses a lot of ammo.
I'm thinking more from the low-touch, low-margin perspective. If you are trying to make money with ads, calling 70 people to get 70 ad views is a terrible ROI no matter how persuasive you are. If you're selling a subscription SaaS product and expecting a lifetime value in the thousands per customer, then cold calling is a pretty decent way to bootstrap.
> calling 70 people to get 70 ad views is a terrible ROI
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.
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.
Are you using parenting metaphorically in #10?
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.
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
1a) and be sure you have those sales, and keep them
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.
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.
I'd modify 10 to:
10. You're only as happy as your wife. If she's unhappy, you're unhappy.
10. You're only as happy as your wife. If she's unhappy, you're unhappy.
If wife is unhappy get a new one:)
Haha I’ll probably be cycling through hundreds of them in my lifetime if I followed that rule ;)
> 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. 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.
You might familiarize yourself with Rule #6 before commenting on Rule #1.
>> But having more sales when you sales org is badly structured will make you loose a lot of money
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.
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.
But this is not true, it is not more sales that fix the problem it is more sales that are -successfully selling- that fix it.
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 ?
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 ?
> EDIT: I use Sales as a shorthand for "Salespeople" but OP use Sales for "revenue" maybe ?
Yes, definitely.
Yes, definitely.
I think you're missing the point. I know that you are right, but the rule still stands.
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 hanging 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.
The venn diagram of tech skills and a non-tech business is where the opportunities are. This applies to many other unrelated skills.
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.
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.
> You’re chances of success are 10x higher trying to build technology for tanning salons
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.
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.
Don't build software for salons; start your own salon that uses software you create, and make that your competitive advantage. Don't know how to cut hair? Then you probably don't know what software would help in that business anyway. Find a business you can do yourself, and help yourself using your technical skills.
This is also why this (very good) advice is not so easy to follow in real life. You need multiple skillsets.
This is also why this (very good) advice is not so easy to follow in real life. You need multiple skillsets.
https://www.getspiffy.com/about
Guy owned two carwashes in Cary, NC. Thought technology could enable mobile carwashing. Got connected with the right technology people ...
Guy owned two carwashes in Cary, NC. Thought technology could enable mobile carwashing. Got connected with the right technology people ...
The obvious problem here being that there is a very, very fine line to tread where software actually matters.
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.
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.
Tell this to Booksy.com (valued ~1B)
> Unsexy sells.
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.
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.
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.
> I know a multimillion £ business that probably gained hundreds of thousands in productivity by simply introducing shared mailbox.
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
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
I think the advice here is not so much to sell a solution to these businesses, but to start a business in that sector and run it more efficiently---thanks to tech magic---than the competition.
> but to start a business in that sector
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.
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.
> Some of those low hanging fruits are litterly on the ground ready to be picked up.
Why we are talking about low-hanging fruit instead of picking them up? I have a hunch they aren't low hanging after all.
Why we are talking about low-hanging fruit instead of picking them up? I have a hunch they aren't low hanging after all.
I keep peddling this idea, but if tech wages came back to reality it would be affordable for small to mid sized companies to hire software developers to truly empower their specific businesses with software.
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.
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.
>if tech wages came back to reality it would be affordable for mid sized companies to hire software developers to truly empower their specific businesses with software.
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.
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.
I wouldn't mind pointing out that your argument is really just that talent is expensive. But my question is, what makes a software developer so much more special than a plumber, a mechanic or carpenter? You can teach yourself software on youtube, we aren't -that- special. There are dozens of highly skilled positions out there that don't get payed nearly as much.
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.
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.
What makes software developers "so much more special than <insert skilled tradesmen>" is that their output to the business is teaching a dumb-but-very-fast-and-cheap-and-capable machine how to do a previously-only-done-by-humans task. It turns out that's a very valuable thing for businesses to have. All those other trades are in "exploit" mode on the "Explore -> Expand -> Exploit" spectrum. There was a time when having a skilled carpenter was critical to building your company. But that time has largely passed. Most carpenters today are applying known solutions to known problems.
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".
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.
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 disagree. You can do software very simply, it's in an environment of excess that teams tend to over-complicate software and software deployment into complex monsters that are expensive to maintain. Small business software problems often lack the scale and public facing nature that causes problems for software infrastructure and increases it's complexity.
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.
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.
Most large-sized companies don't have those skill either.
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 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.
> 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
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.
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.
Which industries do you consider as the lowest hanging fruits?
These are more enterprisy:
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?
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?
> 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 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..."
I love this. He intuitively knew the stuff I wrote in my comment and didn’t let his pride distract him from his mission.
Is it really a bad thing if you hyper-grow by just focusing on one client? It takes time to get a lead, so why not focus on the leads you don’t need to get?
If you have no customers you'll work on your project and eventually give up. If you have multiple customers you have a business of some sort. If you have only one you are in a dangerous place.
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.
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.
You strike me as a genius, Gumby. I literally said "oh my god" out loud while reading the free pilots paragraph
If I am a genius (thanks!) it's only because I initially failed to do this and was screwed each time until I figured out why. Don't be like me; make your own mistakes instead.
Don't be too hard on yourself. Over the years I've come across a few folks who never figure out how not to smash their thumb with that hammer (and never figure out that what they need is a screwdriver).
> That mild-mannered A/R clerk is the real difference between paycheck and no paycheck.
What's A/R?
What's A/R?
Accounts receivable. The people who handle payments, and who hound delinquent accounts to pay up.
We used to have all hands meetings in which everybody talked (not the CEO yakking) explaining what they were doing and what they planned to do.
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.
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.
Accounts Receivable, one assumes.
Almost certainly. Though the music industry's "Artists and Repertoire" (sometimes abbreviated AR, sometimes A&R) is a not-particularly-close second.
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).
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).
[deleted]
[deleted]
- The cheaper you price your product, the cheaper customers you attract. I get a lot more support tickets for customers that paid $45 than those that paid $1500. Discounts often lead to the same issues.
- 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.
- 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.
Regarding your last point: One thing I did in my B2C startup that helped tremendously with this is to have all customers pay monthly up-front, with no contracts and no free trials. I think most folks avoid this because it "leaves money on the table" but it does 2 important things:
- 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.
- 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.
I have a B2C app with a prepaid model as well since 2011. It works like a charm. Very easy to understand, no confusion. Refunds are maybe 1 per month. I haven't had a single credit card chargeback ever and I think only 2-3 PayPal "conflicts" in more than 10 years. (But this, of course, also depends on the kind of customers you have).
But I do offer a 30 days free trial.
But I do offer a 30 days free trial.
I do provide a free trial because it lowers the friction for users trying my product. I sell a self-hosted software, so the main push-back against such software is that installation could be too complex. The main purpose for trial in this case is to let customers test the installation for free and if it works for them as expected they can then purchase a license.
Your first and third points are areas I've found open source companies pleasant to work at. The cheap customers go to the open source code; the ones looking to actually pay buy support contracts. Customers that you can't please also switch to open source; meanwhile ones who find a good fit but want some guidance, end up paying a support contract.
Doesn't work for lots of businesses, but where it does it's quite nice.
Doesn't work for lots of businesses, but where it does it's quite nice.
A good client can provide more than revenue. All the staff that have contact with them will be exposed to their expertise, inspired by their high standards, and bring back their good business practices.
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.
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.
That's true, but that being said, most of the bugs/issues are reported by low-paying clients that like to complain, so they also do provide extra value (apart from revenue).
These are all good, but I want to reiterate the 3rd point about refunds. It happens occasionally. And it's wrong. And it drives you crazy because it's wrong. Consider it a cost of doing business, and move on.
- 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.
- 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.
Agenda, timeboxing and action items for meetings is absolutely the biggest, best, low hanging fruit in the modern workplace.
Good technical people are critical to success. Most technical people aren't good so pick them with care.
typo: great product with LOW churn is hard to build :)
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.
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."
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.
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.
"Verify that co-founders are emotionally committed to stay."
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.
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.
> 1. Verify that co-founders are emotionally committed to stay.
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.
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.
Yes :< I heard that there are cofounders that think so superior. Luckily, I found mine on https://founderscafe.io/ They are actually nice solo-founders (Experienced and newbies are there too). Felt comfortable meeting them the first time I joined the community. :D
> 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.
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?
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?
You can borrow money long-term and then use it to buy safe stocks, like ETFs. If done right, the stock yields will cancel out the interest rate payments, so then you have sort of like a pre-approved credit that the company keeps around.
> And some people change their character 180 degrees when they are drunk. Not sure how to defend against that, though.
maybe not letting people coming to work drunk? Or forbidding drinking while at work?
maybe not letting people coming to work drunk? Or forbidding drinking while at work?
People used the company PCs on the evenings and weekends to play LAN games. Disallowing alcohol would have seriously reduced morale for the rest of the team. But actually I was referring to friendships between people who met at work and then when the work became too stressful, their personal relationships suffered for it.
About #2, 3, and 4, yes, quality starts at the supply line, and the supply line is all abut relationships. You should vet those carefully, and if you can't get enough quality from the immediate market you want, go into their suppliers and do it yourself (or co-start with somebody that can meet your expectations).
Hamming, as always, is quite insightful.
Hamming, as always, is quite insightful.
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.
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.
It depends on people, some people can get more information from document than others.
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.
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...
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...
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.
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.
In 10+ years of startup experience on the science and engineering side.
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.
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.
> Sales isnt something you can learn to do
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.
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.
Spot on. As a techie learning sale for my side project, I will never be the best at sales in the same way someone out of a bootcamp doesn't match the skillset of a Bjarne Stroustrup or a Rich Hickey but quite often you don't have to be the best at something for it make the difference between 0 and something that grows.
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.
Now, this is highly subjective, but I think the general lesson applies: Programming language choice is important for culture.
Which would you choose now in retrospect?
Charge more. Charge more. Charge more. Every problem you have gets easier if you charge more. Every metric you track will improve if you charge more (including customer satisfaction).
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.
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 took me a year or so to learn when I first started. I was trying to bring value to the customer - fine. But to me that meant 'cheap work'.
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.
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.
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.
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.
This is so true. I would say it applies to all advice. Advice can be great, but you have to understand where it comes from and how/if it applies to your situation.
- Sell! Even if you dont have a product, you need to sell. 'Build 'em and they will come' : I've never seen this happen.
- 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.
- 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.
Employees / Contractors / Customers / Suppliers are NOT your friends.
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.
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.
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!
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!
> Don't build something that the world needs, build something that you can sell!
A very sad reality :(
A very sad reality :(
It seems like a good reason to have a marketing co-founder if you're a tech/product person.
[deleted]
23 years exp...
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.
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.
How do you suggest to get good at user testing?
Yep
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.
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.
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
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
- don't ignore critique but instead aim to understand it; the person providing it is taking a social risk to give it to you.
- 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.
- 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.
Here’s one that is counterintuitive. As you start to scale yourself, hire first for the things you know/do best. You will only be able to identify what good looks like if you understand the job. It will be tempting to keep doing those things yourself, because you want to feel competent. Startups are all about allowing yourself to be incompetent, but overcoming it.
Intriguing one since I often hear the opposite advice.
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.
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.
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
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.
Or they leave
7 & 8 are excellent points!
No-one cares if you fail and in the absence of unethical behavior, your identity and your company's identity are distinct. As a founder you think the world has its gaze on you and inflict enormous amounts of pressure on yourself. If things aren't going well, it's completely fine. If it's time to kill it, even better. Fail fast, fail often, and take care of yourself so you can run it again.
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.
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.
Customer acquisition funnels are multiplicative (E.g. Ad -> Landing page -> Signup -> Trial -> Actual product usage -> Purchase). Double any factor along the way, and the final output doubles. But it also means that if any factor along the way is 0, you get nothing out in the end. That can be incredibly demotivating when you're first starting out, because you don't get any payoff (or money to pay yourself or employees with) until you've made every factor non-zero. It also means that as long as any factor is zero, attempting to optimize any factors downstream from that is basically done in the blind (i.e. improving the product when you still don't have anyone even getting to your landing page).
1. The job of an employee at a for-profit company is to create business value. This is often lost on engineers and other technically focused startup employees. Working on a project that you consider interesting or of technical merit is a waste of time if it's not creating business value.
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.
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.
1. Know when to listen to criticism
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. 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.
1. Care about technical matters and show that you care about technical matters - if you're selling something technical it's good to have complicated opinions on technical matters
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
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
My 2 cents.
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.
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.
Technology isn't the business. Technology enables the business.
Amen. I'll add to it:
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.
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.
Don't define your target market as "we just need to get 1% of this $100B market".
Define your market as "for this $XM sub-niche of a sub-niche, we are the 800 pound gorilla that is the obvious choice."
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.
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.
Hardest lesson: Ship it means flip the on switch.
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.
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.
It's super easy to fall into the trap of working on things that don't matter. Most startups are busy toiling on features/partnerships/etc that don't actually impact their growth or move the needle in a significant way.
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.
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.
I've been running a software business before work for over a year now, wrote up recently what I learned over my first year: https://onlineornot.com/what-learned-running-saas-for-year
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.
Focus is about saying "no" to everything else. You don't get focus by saying "yes" to the thing you want to focus on.
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$).
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.
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...)
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...)
Beware the potential for death spirals, and the bigger you get the harder they are to see. Early on, this is easy; last long enough to get to a profit. Later, if you have several products and you're allocating overhead among them, you could be tempted to cut the one with the worst margin. Then the overhead gets reallocated to the other products and pushes a second line underwater.
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.
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.
If you're operating in a grayish legal area, start worrying about laws once you're so big that your government worries about you. If I did my last startup now, I'd spend all the money I spent on lawyers, on marketing. By the time we had on paper that our business is operating within the law, we were down a big chunk of money that we later desperately needed to gain traction. If you fail, no one will care to sue you anyway (specially not your government). But if you make it, you'll have money for lawyers and money to eventually make it more legally acceptable.
Be honest and humble. The business won't work as you expect. Keep an open mind and adapt. Ego will prevent this from happening, don't let it.
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.
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.
- 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?
How are these things non-obvious? Isn't that like business lesson numbers 1, 2, and 3?
Market size means absolutely nothing. Every startup can twist the data so the market size is "billions of gamers/mobile phones/developers/cows". It translates to nothing.
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.
Dilbert on this: https://dilbert.com/strip/2012-09-19
The sad thing is that the boss is right.
The sad thing is that the boss is right.
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).
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).
I've worked as a normal employee at 2 startups and both failed. Some people invested their own money for different classes of stock.
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.
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.
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.
Including second and third degree implications as far as this is possible.
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.
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.
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.
Tests are for teams of contractors that don't know how the product works.
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 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.
> Tests are for teams of contractors that don't know how the product works.
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.
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.
In my case, I haven't really considered integrations tests, as I didn't have the time. Only the bare minimum unit tests "it('should render or shouldnt fail')"
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)
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)
> if i have 24h to chop a tree, i'd sharpen my axe 23h.
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.
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.
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.
No offense but this is awful advice for a startup.
[deleted]
Please read my comment below. You are right, but we cannot generalise.
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 with each project. I know it because I went through the same phase in my career. Good luck!
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!
You have it completely reversed, a rock solid codebase is much more important in an agile environment than a waterfall one. In waterfall you just need to tick the feature boxes. In Agile you not only need code that readily accepts changes, but you need to provide visibility to the business side about the state of your technology so they know not only the opportunities but also the costs of the problem.
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.
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.
Well, I don't disagree that a rock solid codebase is important in either environment. It's the cost of change that is usually at stake, like you mentioned, and that's why I'm arguing that flexibility is more important.than code quality in an agile environment, particularly at the beginning of a project when there are the most unknowns.
You're hitting the nail on the head about burning out though. I suppose it's just the way the cookie crumbles.
You're hitting the nail on the head about burning out though. I suppose it's just the way the cookie crumbles.
> 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.
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 ?
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 ?
You may have supporters but at the end of the day the buck stops with you. If you are not in a position to deal with emotional roller coasters just wait on a startup.
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.
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.
When signing up for marketing/SaaS specialized blog/aggregator article submissions, don't use an email address you want to keep using, because you will end up on thousands of marketing lists.
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.
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.
I've learned that creating a solution for a X problem doesn't really scale as I though. I focus more now on creating a neccessity more than trying to solve problems for people.
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...
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...
Sometimes, you'll be faced with a situation where it seems like you have to decide if you should trust someone. A situation where you have to evaluate someone's honesty and whether they will follow through with their commitments they make to you.
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.
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.
Be careful mixing friendship with business. I have worked on a lot of different projects with friends which ended the friendship.
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?”
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?”
What I found after a few failed businesses:
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.
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.
[deleted]
Don't "play house" -
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.
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.
Eat your own dog food.
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.
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.
Timing is really important. A good startup sees where things are heading or pivoting. There is nothing that can fix bad timing of an industry or market short of complete transformation of what you're doing.
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.
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 talking to your customers.
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.
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.
ShapeUp is about product development and not ‘Selling’
The partners you work with can make or break the best idea; don't let your enthusiasm cloud a colder view of the people you'll be making important commitments with. I've read that it's like a marriage, and I thought that was an exaggeration but it isn't...don't be paranoid, just be careful.
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.
*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.
Know when to walk away. Be aware of the signs you should, and heed them. When the people you respect are all leaving, there is likely a solid reason to do so, yourself.
And when you're leaving, if the company suddenly feels compelled to grant you more stock options, or increase your salary, keep walking away.
And when you're leaving, if the company suddenly feels compelled to grant you more stock options, or increase your salary, keep walking away.
Don’t get a salesperson day one unless they are a partner or you have a boat load of cash to keep them happy- you get what you pay for.
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.
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.
A mantra that actually helps to ship: "good enough" is better than perfection.
Boring businesses are the best.
PMF matters more than anything, and scaling up or raising lots of money before you truly have it is one of the worst things you can do. I’m now hyper aware of this but it’s so easy to delude yourself in the early days
Get paying customers, then start a business. not the other way around.
Market before you build.
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.
You can't please everyone.
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.
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.
1) The challenges of one business can lead to opportunities for an additional (and different) business.
2) Diversifying business is nice, but diversifying businesses is nicer.
2) Diversifying business is nice, but diversifying businesses is nicer.
Have an unfair and protectable lever from the get-go.
From a family business started by my great grandfather, been running for over 100 years.
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.
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.
Non-technical CEOs can probably add the most value by focusing the majority of their energy on building a strong culture.
Never put your personal phone number on any business documents ever. You’ll regret it forever.
Keep your customers, listening them, they know better what your app or service need !
Agreed it's crucial to listen to your customers.
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.
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.
Charge your customer from day 1
Companies that can't invoice promptly and correctly are in trouble.
don’t listen to anyone
Customers will pay late. Some never pay. Plan for that.
Sales cures all.
GAAP is crap.
Cash is king.
1. Make sure your business model doesn't mean growth will kill you.
@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.
@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.
[deleted]
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.
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.
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…
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.
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.
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.
* This message pre-censored by HN in order to preserve curiosity.
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?