tip from personal experience(after working in two tech startup): always get at least a senior engineer in your team at early stage, its ok to have ducktape code, but you got to have someone in your development team that can minimize the code debt (things that you need to refactor later in order to enhance performance or to scale up) , else you most likely to rewrite the whole thing when your business scale.
58:04 was major MAJOR KEYS! Using a cross-platform codebase (even with the trade-offs) is paramount to speed. Also hiring faster vs doing all of the work yourself...also major. I felt that whole moment from Ralph.
@@eduardoblas2315 As I'm working to build out a product in my own time, it seems like there's a fine balance between too little and too much (or useless) testing like the panelists said. I was happy to hear that at least one of them advocated for it in the early stages, because it just seems overly risky to not having some form of test coverage (maybe 5 tests per feature) when you're dealing with user accounts, finances, critical paths, and whatever else. It's significantly more justifiable for me when I'm writing out the backend and API, though. The talk made me realize that even though writing out my React tests is fun and stretches what I know, it's absolutely useless for such fluid components in the early stages.
This was some great advice! Successful products are build by healthy, productive teams who have just the right amount of process in place to help them ship and iterate often. The general consensus is to hack things together until you've found product-market fit and then introduce quality-focused practices to 1.) add robustness to your product and 2.) help communicate and manage the growing complexity of your codebase.
This was very valuable. I've always had a fear of the hacker boogie man who is just waiting to rip my product apart the day after launch. So I spend a large amount of time on security. Nice to know that I can ease those fears somewhat.
Some more questions: 1) If there are multiple technical co-founders, how much overlap in code knowledge should there be? i.e. if one co-founder temporarily has less work, should he just take a break and recharge for a week or start learning new systems and adding code to something a co-founder has built? 2) Related to #1, if 1/4 of the technical people in the team only likes to build independent modules, and has an aversion to updating or debugging on other people's code, is that fine to ignore or something which needs to be fixed? 2) Thoughts on native vs non-native for mobile apps? 3) Design is extremely important for my company, but I am skeptical to hire a designer instead of outsourcing because the team is super technical and there might not be a cultural fit. Any advice here?
I don't have experience working with other tech co-founders only previously as an employee with other devs. My first impression would be that what matters for a startup is to get users, become profitable (it makes sense for your business). So make sure the team is used to ship. Weekly planning meetings are great. Everybody in the early days should know what users and what feedback they said to the person who was talking to them (we're still figuring out to do this) Regarding project management, figure out a way to split the tasks to build the features to quickly put it in front of users to validate your assumptions and see if they want what they said what they wanted. There is not one size fits all to organise people, because every person is different :) Agree on to try one methodology, meeting type, etc. for one week and get together for an hour to review what worked, what didn't work and what do differently. (See retrospective meeting) I've worked with other developers in previous companies and I was considerate a senior. I would help the junior people (in that language or whatever) get up to sleep and learn more. Make sure people are not working on silos. 3) Design. Don't be afraid of trying things out. A diverse group of people is better than a "monotonous" team. Different people will come up with a higher number of diverse type of ideas and if you hired 4 guys who grew up together, in the same town and never travelled. The world is more global and connected than ever. Embrace is sooner rather than later. Hope that's helpful :)
Peidi Wu good questions. i can speak on the third one as that’s a familiar background. i think you, like many others, have this misconception of design. design is simply essentially, fundamentally learning through problem solving to figure out how something works. so both a programmer and designer do exactly that. key difference is one has an interest, skill and experience in the logical(computer code), while the other in the illogical (human nature). so the popular misconception of a designer (as the person that makes things look good) is only the tip of the iceberg. the submerged part of the iceberg is a wealth of holistic knowledge of humans, and what drives them and how they’ll relate to your product. the soul of your culture should be around the overlapping in the venn diagram (which usually orbits around the realm of the problem your solving) regardless of the persons role. also, it’s inevitable that you’ll need to get non-programmers at some point - so why not do it when you have time to integrate before market forces force you to.
This is a true gem. I recently enjoyed a similar book, and it was a true gem. "The Hidden Empire: Inside the Private Worlds of Elite CEOs" by Adam Skylight
As seen in the video it was literally enlightening, you can see the panelist glowing by enlightenment. :) Not sure why there was a light, it was really interesting to see how these guys are running fantastic products without a need of an articulated process or a regime to achieve that, maybe less is more.
If the name of the game is finding product-market fit before anything, it's definitely more cost-efficient to build once with a cross-platform framework vs building it 3-4x beforehand.
Just wanted to thank you guys for making this information free and publicly accessible :)
yes thank you so much
tip from personal experience(after working in two tech startup): always get at least a senior engineer in your team at early stage, its ok to have ducktape code, but you got to have someone in your development team that can minimize the code debt (things that you need to refactor later in order to enhance performance or to scale up) , else you most likely to rewrite the whole thing when your business scale.
58:04 was major MAJOR KEYS! Using a cross-platform codebase (even with the trade-offs) is paramount to speed. Also hiring faster vs doing all of the work yourself...also major. I felt that whole moment from Ralph.
"No one's going to pay you for having excellent test coverage." Love it.
Lol unless you’re selling your test coverages as a service
Regression pays avoiding many headaches, so....
@@eduardoblas2315 As I'm working to build out a product in my own time, it seems like there's a fine balance between too little and too much (or useless) testing like the panelists said. I was happy to hear that at least one of them advocated for it in the early stages, because it just seems overly risky to not having some form of test coverage (maybe 5 tests per feature) when you're dealing with user accounts, finances, critical paths, and whatever else.
It's significantly more justifiable for me when I'm writing out the backend and API, though. The talk made me realize that even though writing out my React tests is fun and stretches what I know, it's absolutely useless for such fluid components in the early stages.
They pay you for something that works and isn't buggy.
ya, test coverage doesn't matter, tdd does.
The jeans company for all those startups is who you really need to interview.
I loved this talk! As being a technical founder this was some really good advice.
Segment is something so useful. Hard to believe it took so long for them to find PMF! Congrats!
Crazy expensive though. Once they gave us a $1m per year quote, to replace a tool that cost $16k per year. Faster and harder pass I ever made.
Great video of technical founders flexing their technical insights. Keep up the good work.
This was some great advice! Successful products are build by healthy, productive teams who have just the right amount of process in place to help them ship and iterate often. The general consensus is to hack things together until you've found product-market fit and then introduce quality-focused practices to 1.) add robustness to your product and 2.) help communicate and manage the growing complexity of your codebase.
Love the comment ‘we don’t have the challenge of a non-technical co-founder’ 👊😉
Yeah
As a technical founder they all look soooooo advanced and technical
This was very valuable. I've always had a fear of the hacker boogie man who is just waiting to rip my product apart the day after launch. So I spend a large amount of time on security. Nice to know that I can ease those fears somewhat.
Some more questions:
1) If there are multiple technical co-founders, how much overlap in code knowledge should there be? i.e. if one co-founder temporarily has less work, should he just take a break and recharge for a week or start learning new systems and adding code to something a co-founder has built?
2) Related to #1, if 1/4 of the technical people in the team only likes to build independent modules, and has an aversion to updating or debugging on other people's code, is that fine to ignore or something which needs to be fixed?
2) Thoughts on native vs non-native for mobile apps?
3) Design is extremely important for my company, but I am skeptical to hire a designer instead of outsourcing because the team is super technical and there might not be a cultural fit. Any advice here?
I don't have experience working with other tech co-founders only previously as an employee with other devs. My first impression would be that what matters for a startup is to get users, become profitable (it makes sense for your business). So make sure the team is used to ship.
Weekly planning meetings are great. Everybody in the early days should know what users and what feedback they said to the person who was talking to them (we're still figuring out to do this)
Regarding project management, figure out a way to split the tasks to build the features to quickly put it in front of users to validate your assumptions and see if they want what they said what they wanted.
There is not one size fits all to organise people, because every person is different :) Agree on to try one methodology, meeting type, etc. for one week and get together for an hour to review what worked, what didn't work and what do differently. (See retrospective meeting)
I've worked with other developers in previous companies and I was considerate a senior. I would help the junior people (in that language or whatever) get up to sleep and learn more.
Make sure people are not working on silos.
3) Design. Don't be afraid of trying things out. A diverse group of people is better than a "monotonous" team. Different people will come up with a higher number of diverse type of ideas and if you hired 4 guys who grew up together, in the same town and never travelled.
The world is more global and connected than ever. Embrace is sooner rather than later.
Hope that's helpful :)
Peidi Wu good questions. i can speak on the third one as that’s a familiar background. i think you, like many others, have this misconception of design.
design is simply essentially, fundamentally learning through problem solving to figure out how something works. so both a programmer and designer do exactly that. key difference is one has an interest, skill and experience in the logical(computer code), while the other in the illogical (human nature).
so the popular misconception of a designer (as the person that makes things look good) is only the tip of the iceberg. the submerged part of the iceberg is a wealth of holistic knowledge of humans, and what drives them and how they’ll relate to your product.
the soul of your culture should be around the overlapping in the venn diagram (which usually orbits around the realm of the problem your solving) regardless of the persons role. also, it’s inevitable that you’ll need to get non-programmers at some point - so why not do it when you have time to integrate before market forces force you to.
This is a true gem. I recently enjoyed a similar book, and it was a true gem. "The Hidden Empire: Inside the Private Worlds of Elite CEOs" by Adam Skylight
Thank you YC for uploading TH-cam content, it makes a huge positive impact! Keep it up 😃
As seen in the video it was literally enlightening, you can see the panelist glowing by enlightenment. :) Not sure why there was a light, it was really interesting to see how these guys are running fantastic products without a need of an articulated process or a regime to achieve that, maybe less is more.
“I would have built it in a cross platform framework” is exactly what someone who has never worked with a cross platform framework would say lol
Well, I would have 100% agreed a year ago ;D but honestly, Flutter won me over. If the app does not use AR then Flutter is my first instinct.
Hahah. Would you steer away from cross plateform...?
If the name of the game is finding product-market fit before anything, it's definitely more cost-efficient to build once with a cross-platform framework vs building it 3-4x beforehand.
Thank you for putting this out there.
We need this all the time
showing an accurate and deep understanding; great perceptive. Thank you for all the insightful information. 💡
Everyone should have a microphone.
I find this interesting. All CTOs have similar dress code. Except the segment guy.
They're thinking about everything else lol
Copy of Steve job stile
Thank you YC
Wow. What an amazing Panel and convo. Thanks for sharing
Thank you guys so much for the great content!
I love this level of honesty!!! Good job! #2020
Are use digital ocean. Everyone seems to be using AWS. But digital ocean is the second largest hosting company.
Any thoughts about DO versus AWS?
They have different target markets, AWS is expensive to start with DO is cheaper. Once you scale, AWS get's cheaper and DO is more expensive.
Thank you guys for sharing your knowledge and experience, this was awesome 🌱🍀
Finding it hard to get a good tech co-founder. As a non tech co-founder I’m here to get some knowledge on what to look for as a tech cofounder😳
Thanks for sharing all your experiences. :)
is there one for a non technical founder? like me?
literally all the other videos
Why is everyone on AWS, not Google Cloud ?
They all started a few years ago when GCP was in its infancy
Also AWS is very startup friendly with 10000+$ credits worth offered. Not sure if Google is as generous
In 10 years:
Technical Cofounder: Presses Button
Non-Technical Cofounder: Talks about button pressing.
“I take like .2% of every credit card transaction.”
who else thought- they ran a sorting algorithm backstage
44:56 uncomfortable finger touching 😏
this was fun
Yeah loved the interview
Helpful :-)
one single pair of jeans can change the world
#startuptechnology
Why is it that the women have to share the microphone but all men have their own? Please get them their own microphone or everyone shares one.
It’s possible one of them dropped their Mike during setup, of left it somewhere, many scenarios possible. But wow, what an observation.
Fun fact: everyone's wearing jeans
All software, what is your tech stack😅 software😅😅
"khoool"
Booooooooring...