"Too much building and not enough selling" is the major mistake in the list. It's the reason for my first startup failure too. You need to be generating revenue within a few months of starting. If your product solves a real problem people will pay money for less than the minimum product just to make sure your company survives long enough to build the minimum product.
Ultimately, money is the only thing that can keep a startup going. That means either sales and revenue or investment, and getting investment is a lot easier if you have sales and revenue.
Eating more healthily, getting more sleep, and doing some exercise are useful for staying focused and selling better, but the number of successful startups whose founders had horribly unhealthy lifestyles yet still managed to sell their product is significantly higher than the number of startups with healthy founders who didn't sell anything.
Extremely important corollary: Build pipelines, autoscaling, CI, unit test, et al are not a real problem customers want you to solve. Not a single penny is going to roll into your coffers because you have tremendous infrastructure in place.
NB: I'm not talking about selling a product for build pipelines, I'm talking about allocating excessive resources into internal tooling pre-traction.
I applaud this attitude, but I think you are wrong about the specifics. If you are serious about this craft, you should have a stock build/test/ci harness you can spin up without effort. Even if it's just "copy some boilerplate from a previous project". This is just basic software literacy, like using git.
If you are using something like Google app engine or heroku, all that autoscaling and other devops stuff is taken care of for you. There is no reason to go without.
I think there is a core truth you're point to that when you're working on the initial months of a start-up, knowledge and time to acquire it are massive weaknesses. If you're using that time to learn how to build your CI pipeline, that's probably not the best allocation of that critical time. An entrepreneur would be best served by CI practices they can employ off their own shelf and focus their attentions on the billable problem solving.
This. It took us three months to market back then, mostly because we skipped everything nonessential. Like, really everything. Sure, these days we have CI/CD with static checking, ChatOps, full observability, all the nice stuff that attracts good developers. But all of that is completely irrelevant to customers. It's just relevant to scaling a dev team.
The very first version we launched publically, we checked out, compiled and deployed through SSH directly on the servers. My first monitoring tool was htop in 3 screens plus some CloudWatch dashboards. A lot of credentials and endpoints were hardcoded. Not because we didn't know better, just to save time.
The number one thing pure techies completely get wrong is opportunity cost. Especially in the beginning, almost nothing beats time to market to validate product/market fit.
Ignoring the "eat your vegetables" part of software engineering isn't a savvy startup hack, it's a deliberate taking on of tech debt for short term product velocity boost. It's also pretty dangerous for you engineering culture - most engineers don't like to work in this environment and good ones don't have to.
It's really all about making principled choices when it comes to how much jankiness you can tolerate for a short term velocity boost.
Doing awful things to rapidly try out an idea and see if it warrants further investment is good, as long as you kill the ugly as soon as you understand that your POC is good and you are going to invest further or you know it's not a wise place to invest further.
But there are definitely places where you know you're going to need sanity no matter what. This is anything you know you're going to do a lot, especially under a time crunch. For SaaS work, deployment is one example. In these cases, it's worth investing in building a low friction solution that meets your needs.
I pretty much agree with you, but the stronger counter-argument would be that having those things makes recruiting a lot easier.
Top-talent engineers are going to be a lot more reticent to join a startup where the systems are constantly on-fire and held together by duct tape. The first few hires set the standards and corporate culture, so this can have a real impact on the company's long-term viability.
You're talking about two different scales: if you're at the stage where you're choosing between selling and building on a daily basis, worrying about your recruiting pipeline is a second-order problem (if not a third-order problem).
Once you, as a founder, have the luxury of hiring (presumably because you've done step one correctly), your time is then a choice between selling and recruiting, and in the early stages of that, recruiting isn't going to be much more than trying to convince good people you already know to join your team. These people aren't going to say no based on your CI system.
Having made the mistake myself (multiple times), OP is 100% correct, and it's one of those messages that can't have any nuance, or people won't do it right. It's a treacherous vortex of failure for programmers-turned-founders: coding is much easier and more familiar than selling, so you find all sorts of reasons to write code when you should be talking to customers.
I've had to clean up from this once the product matures into maintenance mode.
It's fine to start this way but people have to realise they will need to put some structure in place. At some point you'll struggle to get new features out on time without a ton of bugs.
100% and I see this kill startups from time to time. Particularly ones with very technically sharp but unwise founders.
That said I think that investing in a minimal, quick and dirty CD system can be valuable for very early startups that need to move very fast on the road to product/market fit.
or just run npm test / make test locally without setting up anything. But I feel like writting the tests takes usually more time than setting up CI/CD.
Customers pay for velocity. You can get velocity by installing a freight elevator, or by jumping off the side of the building every time.
Tooling is tooling, not a religion. But if you've ever looked at the regimen of an elite professional athlete, you'd be hard pressed to discern it from a religion. It is necessary, but insufficient, and I don't think most people get that.
I was more talking "We don't have a single customer yet, but we have an industry standard set of redundant freight elevators, with automatic load balancing and travel optimization" versus "We have 120 paying customers, and still take the stairs".
> You need to be generating revenue within a few months of starting. If your product solves a real problem people will pay money for less than the minimum product just to make sure your company survives long enough to build the minimum product.
No wonder nobody does hardware startups. It seems unrealistic that you'd have a prototype that anyone would be comfortable paying for within a few months, unless you're selling something as simple as a pre-programmed Arduino in a box.
Be careful not to confuse consumer hardware with business hardware. There are plenty of business hardware use cases where customers are definitely willing to pay money for something that amounts to a few hundred dollars worth of off the shelf components, custom PCBs, well-written control logic, and fanatical customer support. You just probably don't encounter this kind of hardware because it's out of the public eye in manufacturing, logistics, etc. operations and getting to those customers requires knowing the target industry (or knowing people who do).
I work in this area and the customers are still very picky. A lot of our funding has come from a few very large purchasers that are okay with a farther horizon, but most customers don't care about the product no matter how good it will be in the future. They want it good now.
I've got a real life case I can provide an anecdote for. I recently got to try out a candy depositor with a temperature controlled hopper. The machine costs about $12000.
The machine consists of a base depositor that can be purchased on its own for about $2000-$3000. The heating elements consist of a few metal plates worth maybe a couple hundred dollars, a couple of off the shelf temperature controllers worth less than $100 each and some housing and circuitry for the controllers that's can't be worth more than $1000. Overall, I'd say the temperature controlled depositor has maybe about $7000 worth of parts in total, being generous.
That's a decent markup for something comprised nearly entirely of off the shelf parts.
It seems unrealistic that you'd have a prototype that anyone would be comfortable paying for within a few months
If you're thinking "No one would pay for that" without asking customers then you're doing it wrong. Let the customer decide what they're happy to pay for. Some of them will give you money even after you've made very little progress.
I see this a lot but I feel its quite difficult to actually pull off. Even though your mvp can and should be shitty sometimes it still takes a lot of effort and talking with potential customers to even figure out what you should be building, and its extremely difficult to do when your still trying to work a full time job. Maybe someone who has actually done this before can offer their perspective
It resonates with me a lot. I have this idea I would like to test. But once I'm done with my work (I'm a PM under french lockdown, I spend my whole day in front of my computer), I really need to disconnect, spend time with my 3 kids and wife, or exercise.
I'm afraid that if I spend my evening and nights into trying my idea, I would either 1/ not get results fast enough and hence loose faith in the project or 2/ get burned out and hence disgusted by the project.
Or maybe it's just the lies I like to tell myself to be comfortable with keeping on procrastinating this...
I also was thinking like you but at the end I understood that I shouldn't have huge expectations. I decided that I just need 1h each day for implementing MVPs. After 3 months, I get used to this and can't imagine day without this hour.
I'm in a similar situation, although with only 1 kid yet. I think you're spot on that building a working prototype in your free time will be either slow or exhausting.
But most of this start-up advice seems to be geared at single college students, and they'll have enough free time to pull it off.
This trade-off doesn't go away when you start a company. It actually gets worse because not only do you lose that personal time, but you also have 100x the amount of stress.
But the right approach depends on your goals. If your only metric is money, then you should probably spend a lot more effort on marketing than engineering. But if it is a lifestyle business and you prefer the engineering, do a more than optimal amount of engineering. Just make sure you do enough marketing to pay the bills!
I'm willing to bet most startups have horribly unhealthy codebases, at least that has been my experience. However, it ultimately doesn't matter much. The things that matter are the things that gain and retain customers, like stability, uptime and functionality. While it's unlikely you'll have stability and uptime in a bad codebase, they're not mutually exclusive.
No - bad coding practices for a company are like bad personal health practices like eating junk food and sitting on the couch all day. It won't hurt too much when you're young, but you sure pay for it later.
The vast majority of startups fail and usually they fail early. Increasing your early chances of success at a cost in the future (which you may never need to pay if you fail) is a net gain.
The right thing is whatever the business needs to succeed and spending more time on cleaner code isn't it for startups. You're assuming employees don't know how to write cleaner code rather than them choosing not to for the sake of lower time to market.
My experience of startups isn't that the code is terrible because they were in a hurry, it's because they were inexperienced or learning to code on the job. Experienced coders might cut corners but they'll make good foundations to fix things layer.
The only thing I'd extend this with - but with some hesitation - is demonstrated traction. People are using your product, even a very very early version. (The reason for the extension is many social media apps don't monetize for a long while, and users seems as adequate substitute for revenue here.)
Correct. The other thing selling does is give you very instant feedback on whether your product actually solves a problem at all and if you are marketing the value proposition correctly. You have product <> market fit if and only if people are paying you. Alphas and Betas are fine to point you in directions but money talks.
> the number of successful startups whose founders had horribly unhealthy lifestyles yet still managed to sell their product is significantly higher than the number of startups with healthy founders who didn't sell anything.
I see the point you are making, but I'm skeptical of this; if we ignore the health factor entirely, the number of startups that sold any significant amount is probably a very small fraction of the total number of all startups.
I'd be more interested the proportion of founders with healthy lifestyles in the pool of "successful startups that have sold a nontrivial amount of product", versus the proportion of healthy people in the _general_ population (either all founders, or all people).
My completely uneducated guess is that there would be two competing effects for the "successful startup" pool: the "dedication at all expense" factor would result in a negative correlation between success and health, and the other obvious effect would be healthier living causing better decision-making and execution. Of course, this is just a guess and I could very likely be wrong.
OP: Thanks for sharing this. I have a few questions, if I may:
> We shipped features at a tremendous pace. But we never talked to enough users to identify if it was something necessary. We assumed things and kept building – in a few months, we had a product which was an engineering marvel – but nobody cared to use.
I am curious because the YC application needs one to clearly articulate who ones target customers are, what they do today, why is it such a pain, and what one is building to solve that pain-point. And it looks like you folks at Marketfox did have it figured out [0]. It is interesting to me, then, that you'd cite this as a key mistake. What am I missing?
> We were very naive to think that building software is the hardest part of building a startup.
Well, there's a balance here: Both are equally hard. Writing code is less hard if you're a software professional and same goes if you're a Sales or Marketing professional. You did say you shipped features at a break-neck pace... but usually, for an enterprise SaaS, isn't that the bread and butter anyway? I am curious why you'd consider this a mistake. Not every (SaaS) product is novel anyway, and learning from your competitors is a shortcut to the otherwise long arduous road of defining a category / industry / market. Assuming that you folks did not build a feature in a vacuum (that is, you'd have would thought a feature was necessary only after looking at competitors do it better or a paying customer ask for it), was it the case of feature mis-prioritization / building too many bespoke features that only one or two customers wanted?
1: Correct, we had "assumed" who the ideal users would be. Because the market was already huge, and we "assumed" people who used our competitors would use our product too.
And when we were not able to sell, we thought It was because of lack of feature. The "one more feature" mentality was bad.
The surface area of products like Hubspot(our competition) is huge - and we tried to catch up with them in terms of feature and this was a mistake. We didn't try to identify a niche.
I think this is one of those things that is easy in theory and hard to practice.
2: Agree that both are hard. I'm still happy with the pace which we shipped at. Looking back at it I think we were not shipping the right features.
There are a few reason for this:
- We got a bit desperate at some point and started building features for single customers(which we thought would be useful to others, but was not). And this spiraled downwards and our product started doing things that we initially didn't intend to. (Like email automation, push notifcations, website builder, form builder, inapp messaging, blogging platform, social media management etc)
- At some point we blindly started copying features, without thinking why we need to build it. (I know this sounds really stupid now, hence the title)
- We were young and we thought we could brut force(or hustle) our way out of every problem.
I hope that helps. Happy to explain more if you have questions :)
Sorry for being a bit too inquisitive, feel free to answer only what you're comfortable answering:
Funnily enough, I was about to cite the example of Freshworks (in that building SaaS companies from India gives one an unfair pricing advantage; and also that focusing on one product for a large but under-served (read: small companies) market that can be sold "repeatably" (read: feature set everyone needs) is the "key" before moving "upmarket" to large enterprises [0]) but it looks like you are an ex-employee and so you'd know all of this already!
That out of the way, a few follow-ups:
> ...we "assumed" people who used our competitors would use our product too. And when we were not able to sell, we thought It was because of lack of feature.
I mean, I'd naively think it to be true as well-- that not being able to sell (to target customers) would be usually be due to lack of features. If not that, what, you think, were some reasons Marketfox couldn't?
> At some point we blindly started copying features, without thinking why we need to build it.
You mean Marketfox didn't know if a missing feature (that a competitor had but Marketfox didn't) was important / critical but expended engineering resources on it anyway? If so, what you'd have done in its stead? How else you'd approach figuring out what to build?
Also, I am assuming Marketfox had access to founders/mentors who had done SaaS before... why you'd think that didn't make a difference (given your analysis that the mistakes you enumerated were avoidable)? What'd you, in the light of that, do differently?
Re: Freshworks - Yes we had a ton of learning from there and the plan was to execute something similar. Had lot of advantages in terms of cost. This was also a serious part of the business plan.
Re: Selling to customers: This was not easy as we thought. Most people just doesn't switch to a new product based on features. Either the new product needs to be substantially better - so that it overcomes the pain of the switch.
This means we had to build a product that is much better than existing products - and we failed placing our product correctly. Marketing is an area with a lot of verticals. Content, Digital, Email etc.
We tried to do a lot of things at the same time. For example we could have focused on just email marketing, or just content marketing. Instead we tried to do all of these together and they were mediocre. I guess that was not enough to force the switch. After a point we couldn't tell who were we competing against - The email marketing solution, the push notification solution or the enterprise marketing solution.
If I were to rebuild it today I would have focused on a single thing and built a great product out of it.
About mentorship - I'd say I didn't have enough "access" to mentors or the network due to several "internal reasons" (Slightly touching upon this on the decision imbalance)
If it was solely up to me, there are things I would have done different back then too.
At least now, I have wonderful people helping me through my startup journeys. And I'm a big believer of having the right mentor. At the startup I co-founded last (Carrom - which was acquired https://money.yahoo.com/oyster-acquires-carrom-accelerate-gl...) I had the opportunity to work with some great people and this was something I did right in terms of mentorship.
Yes, brutal-force our way out of every problem some times is our "human natural" way to react against problems out of "our scope/control". But for the same premise that are out of our handling are in majority of cases wrong reactions to face problems.
We started out as a Shopify plugin for marketing and had some users. But before expanding the product we didn't really talk to any potential users. Again, another stupid mistake.
Once we started building we got the opportunity to talk to a users(Other YC companies in the same batch) - which thinking of it now was not the ideal user persona.
If you are having to take customers with whom you share the same investor, it's probably a sign that you are not doing well enough to find customers on your own. Plus I don't think YC derives much benefit if its companies survive by selling services to each other.
> YC application needs one to clearly articulate who ones target customers are, what they do today, why is it such a pain, and what one is building to solve that pain-point ...
Which in my opinion is the hardest part. If you don't know what you're doing, it doesn't matter if you're selling or not, it doesn't matter if you're building or not. That comes later.
But that's not it. How do you know what you're doing, or going to do? It doesn't happen by sitting down with buddies or co-founders and having a brainstorming session. This is where 'you have to be at the right place and the right time' but also 'you have to have spent the right amount of time thinking about it'
The right amount of time could be 1 week, or could be 10 years. Yes sometimes you need 10 years to get to the point where when you found a company, you start generating sales within a matter of months.
Thanks for writing this. Sales is hard because it means you have to face the fact that you’re whole passion project is not yours to control, it’s theirs and always will be. That’s a hard thing to face and, in my opinion, the primary reason why it’s so often ignored.
I really appreciate you taking the time to write this down and allowing us to read it. Thanks again.
When bogged down in some horrible XML soup or similar, I get motivated by thinking about how this integration or whatever will improve things for the end user.
It's especially nice when sales get back from a demo and reports about jaws being picked up from the floor. Or when the base you made allows you to whip up a solution to a pressing customer issue in 5 minutes.
It's not always fun to write that code, but it can fun to have written that code.
I was in a similar situation as author, only in Chicago 'burbs. We were working hard to build our product, and there was free unlimited fizzy sugar water in the kitchen.
I drank so many MtDews that when I got back home, to the house we rented where I was living with 3 other startup members, and passed out in bed, I ended up peeing myself in my sleep for the first time as an adult. Worse, it happened again the next night!
It didn't happen after that, to my knowledge, but I've sworn off both MtDew and doing more than 10 hours per workday since then.
It also made me realize that if a startup can't make it without taking a huge toll on health and happiness, it's not sustainable by definition, and should be modified. There are occasional exceptions, but most of the time this rule stands.
Wow! Thanks for sharing this. We all have had our lows.
I think anything that is not sustainable over a period of time is not a good idea. It is ok to try and do things that don't scale in the beginning. But it shouldn't come at the cost of physical and mental health.
My co-founder just left our company after 4 years because we basically had to pivot and restart with a new product that fit with COVID (we are in the events space).
Looking back at everything that lead up to him having to leave, I've come up with the one mistake I regret doing:
Splitting up duties.
We were technical founders but we decided one of us would handle the business side and one of us would handle the technical side.
I think this ended up isolating us rather than having us work together as a team. As we grew I hired account managers, sales, etc and he hired devs. We chose to start a company together but never really worked together.
Now 4 years later I'm working in the backend for the first time. I wish I would've spent more time pair coding with him and discussing architecture together. We worked at 3 other companies together and went to university together and I think we missed our opportunity to truly work together on something WE want to build.
This was a fun read. I was in the same YC batch as you(BicycleAI) and we made some of the same mistakes too.
I remember Marketfox really well because I've never seen a team build so many things so quickly! The execution speed was legendary and it made us feel so slow in comparison. :D Good luck with your next startup!
As far as I can tell (never having gone through YC), some of these mistakes are exactly the ones YC spends a lot of time talking about. I'm curious what caused you to make them anyway. Did YC change, am I wrong, or is it simply a case of practice being harder than theory?
Meeting smart people was always great. We learned a lot of things. It was life changing - Still I feel like we didn't make the best out of it due to several reason. One of them was our self doubt when it came to communication - This was our first time outside our home country(India)and we had a lot of inhibitions socialising with people. We always kept thinking if we were doing something right or wrong in terms of western culture.
I think under pressure we made a lot of stupid decisions. We were inexperienced and we were doing that for the first time.
I don't think these are harder to practice - My second startup was recently acquired and I think I did a decent job there. The reason why YC emphasise about these mistakes are probably the same - they have seen a lot of first time founders make the same mistake.
You say this was your first time outside India. May I ask, what was your path to setting up a company in the US and moving there? Was this via an L1 intra-company transfer, an E2 investor visa, or something else?
Everyone knows the third hardest part of building a company is making products.
Everyone knows the second hardest part is figuring out what products to make.
Everyone knows the hardest part is finding customers who are actually buying your products.
I'm not saying the easier tasks are unimportant but if you don't solve the hardest problem your business won't go anywhere, no matter how good you are at the first two. Meanwhile someone with a good sense of business can often delegate the first two to someone else.
I have not repeated any of those mistakes I mentioned in the post. I think that itself was enough to take us to a good place. Apart from that it was good timing, a lot of luck and market I knew down under.
Another thing was consistency - we also had lot of ups and down, in fact we stopped operations at some point. But kept going to come out of it. Consistency was the most important thing there.
"You can go a long way if you avoid stupid mistakes."
I find this true whenever I decide to take on a new endeavour. If you can learn from someone else's mistakes, you're better off than 80% of the competition in ANY MARKET.
So many people have an idea to make money, look at the competition, and give up. But if you keep going just a bit further, you find out that most of the competition, which looked so daunting at the start, is actually awful.
Yep, agreed. Most of this advice is useful even if you're just building an open source project that you're passionate about, and your post helps a lot.
Nobody wants to build a product in vaccum that has no users, no matter how brilliant the idea.
My other two cofounders are building an open source tool - https://www.chatwoot.com/. I'm sure they have used a lot of wisdom from this experience too.
I was thinking the same thing, but the other aspect is that YC is not a baby-sitter. They have 100 companies in a batch. If you're attending the meetings but not taking the advice, they'll probably write you off fairly quickly as the chances of success are low and they can focus on helping those who are leveraging the knowledge and experience.
Yes. Interesting.
It is for me a difficult problem the product vs selling...
It seems simple at first - "yea, just sell" , but I'm fact often you need good-enough-pridict to sell.
Moreover, the energy(ie money ) to sell will be lost if you try to sell a not-baked-product whereas spending to upgrade the product is never lost...
So yes, this building vs selling is to be nuanced ....
Interesting, I thought YC provides a lot of coaching for the business side of things they messed up on. I vaguely recall reading against all those practices in YC related blogging.
I guess they aren’t too heavy handed about it.
Also the coding on the floor thing, wow.
But after all is said and done, major props for getting to be a YC startup to begin with!
YC doesn't intervene in your day to day operations. They are there to give any guidance if necessary - But they have no role in running your startup. That would be impossible and unnecessary.
YC is as good as what you can make out of it. It can be anything from average to great, depending on how much effort you put into learn from smart people.
The first start up I worked for we made our desks out of doors that had been discarded.
There's an IKEA in East Palo Alto. Sleeping on the floor for extended periods of time is ridiculous. Even a $30 inflatable air mattress is better than that. Come on. It's not like SV carpets are tatami mats.
Totally agree. That's why I mentioned we should have spend more on improving quality of life. Having moved from India, our brains also did this Dollar to INR conversion, that made it hard for us to spend money.
A $30 inflatable air mattress is bad for your back. It deflates overnight, and you end up waking up from sleeping in a bad posture, and having a sore back. It’s better to just sleep on thick padding on the floor.
Surprisingly, programmers don’t require a lot of room to work. Just a small table and a laptop. And multiple monitors are a great productivity tool.
If you've built something that's buried under 3 menus, then that's not going to have great returns. Every feature added is is another node in a graph with multiple branches to any related features. This includes non-code related things like ux, maintenance cost, marketing, tie-in with product vision (i.e. how well does it fit into that brief description of your product, and if it doesn't how to do you communicate it).
Building the software is the hard part. It takes a few hours to talk to dozens of customers. People will use your product if it solves a pain point. It takes 100x more time to actually implement that feature.
Bad examples set by people who have been there previously?
We have always romaniticised hard work - especially in the "American Dream" culture.
It has changed a lot these days. We can see a lot of sane startups vouching for work life balance.
Shipping features without talking to users is a death knell. You end up with an bloated product that serves no one particularly well.
It sounds like all the other problems are just derivatives of this because all of the time was spent head down and "working" and no time spent being strategic, creative or learning what your customer base actually wants.
Marketing software is really hard, as others have mentioned, due to switching costs, the number of niche verticals, and user to user requirements.
I also notice that in the past few years, there are a flurry of new products in this space offering lifetime deals as well. This makes it so that a traditional saas offering needs to incorporate some sort of up sell later on.
Hard work is romanticized by the startup world. I used to brag how many hours I worked a day as if it is an achievement.
Yep. And it is still romanticized by the investor class looking for tireless worker bees and some successful founders who believe that because they built startups that way, it's the only way.
Correct. There are a lot of people who considers 24x7 hustling as the only way to build a startup. Worse, many founders and VCs expect that from you. This is mostly the case in US centric startups. The work culture in Europe is much different, relaxed and life centric.
Is this how most ycombinator funded companies general work? You have to move California even if you are sleeping on the street? Wouldn't staying in home country make more sense until profitibility is discovered?
At least before covid, companies had to move to Bay Area.
But I don't think everyone sleeps on the floor. YC funds you enough (120k then, 150k now) to afford decent housing. We were just a bit too concerned about the runway since we didn't make enough revenue.
I want to make it clear that YC definitely recommends a healthy life style and this was strictly our choice.
If only the author knew of all the free furniture being given away in the bay area. Back in 2017 I furnished my whole apartment with only free furniture in just a few weeks. Facebook groups like "Buy Nothing SF" are littered with free beds, chairs, couches.
I'm currently going through with my first startup, I'm a technical founder and this post definitely helps me to try to invest more of my time learning how to do sales. Thanks for sharing.
Glad it helped. If you have a co-founder whom you trust can do sales for the company you need not worry about it. Nevertheless, a bit of soft skill can go a long way.
Ultimately, money is the only thing that can keep a startup going. That means either sales and revenue or investment, and getting investment is a lot easier if you have sales and revenue.
Eating more healthily, getting more sleep, and doing some exercise are useful for staying focused and selling better, but the number of successful startups whose founders had horribly unhealthy lifestyles yet still managed to sell their product is significantly higher than the number of startups with healthy founders who didn't sell anything.