00:00 - Have a process to get product out the door 1:02 - Decide on a release schedule 1:15 - Put someone in charge of product 1:34 - Establish KPIs 1:47 - Create a theme for the product cycle based on a KPI 2:00 - Product meeting 2:30 - Brainstorm new features, bugs, and tests 3:35 - Sort each into: easy, medium, or hard 4:59 - Pick the hards first 5:30 - Spec the ideas out and assign tasks 6:00 - Shut up and get to work 7:00 - Testing
Y Combinator is it not best to tackle the ideas with the greatest value add with regards to a specific KPI or KPIs - as opposed to simply ‘the hardest’? Just curious. Thanks for sharing.
Thanks Michael! Btw our method: 1. We defined AREAS of responsibility like product, backend, research etc. 2. We defined a person RESPONSIBLE for each area. That person DO all the job and TAKE any decision he wants in his area. 3. Everyone can and should ADVISE to others.
This is basically agile methodology. It definitely works for small to enterprise organizations. Agile always seemed pretty easy to understand because it's just common sense. I'm glad they tested this approach and it worked for them....it pretty much would work for most organizations. The important thing here is KPIs! Those who are presenting ideas should know what we are trying to measure and if we are accomplishing the goals we want to meet. Otherwise, ideas can get overwhelming and it's almost impossible to measure. Now, as far as testing, I would say what Michael is saying is not scalable at all. Maybe just for the initial stage, but testing automation should be done as new features are rolled out and that's all to it! If you don't have automated testing you will find release cycles getting ridiculously long as you have more test cases. PLEASE, for the love of everything dear, be serious about both Unit Test (dev) and automated tests (Test Eng). :) Love you guys and wish everyone the best of luck! :) Cheers!
"Shut up and get to work"... Jeff Bezos is also very big on this even at the highest level. Bezos' calls it "Disagree, but commit". If you trust the people around you (which you should if you're working with them), if your opinion is not the majority, and they don't place a disproportionate value on your opinion for this matter, it's best to disagree (not settle/fold) but commit to the plan and not hold anything against them if it fails. Bezos said he doesn't want disagreements to end in settling or negotiating, you should keep your conviction unless you see you were wrong, so if two people are VERY confident in their ideas and cannot disagree and commit, it goes to him for a decision. You shouldn't waste time on decisions that probably don't matter much in the long run.
It was exactly how I did to get a $200K+ offer from a full accelerator - completing work within a cycle, an important key metric, count number of users. It came first with content generating and now I have to shift to another version of the product given a better infrastructure. And then count again :)
I fully agree with the testing part that it should be done by everyone. I mean QA testing and basically all testing around 'does the app work as we intended it to". At a company I worked 2 years ago, they had no QA testers when I joined. My role was senior software engineer (fullstack) and I was doing most of the work together with the head of development (CTO in disguise). They were planning to expand the company and engineering team and we had a meeting about a QA guy they were interviewing. The CEO proposed we should hire that QA guy so we could keep on writing code. I said that we (me and the head of dev.) would still do thorough QA anyway, with or without the new guy. So hiring him would not 'save us two time'. He asked me why do I believe that. I said 'qa is not meant for a single guy or a small team -- qa is EVERYONE's job, the more people the better, especially in a small scale-up.' He agreed (all of them did) and not only what I said has been considered and put into action but this also but me in a very good spot in the company. (just a side effect worth mentioning :D). Great talk as always, Michael!
How to Get your Product out of the door: 1. Schedule release dates 2. Make someone responsible 3.Establish related KPIs 4. Brainstorming for improving KPIs: Pay specific attention to bugs and do not procrastinate on them. Garde the generated ideas based on the difficulty of implementation. First, implement the hard and medium ideas. ==> Write down what is going to be built around the ideas and who is responsible for them. *Don't talk about ideas outside of meetings. Shut up and get to work.* ==> Have frequent scheduled brainstorming sessions.
Thanks for this practical knowledge. Keep on doing it. I appreciate frameworks for processes that lead to better effects. I like explicit workflows and activities descriptions to model the process.
Fantastic video; thanks. It's such a nice change to have real advice given, in a respectful thoughtful manner, compared to the endless sea of big-mouths out there who seek self-promotion without actually contributing something useful.
At 4:59, you mentioned to pick the hard ideas first. What difference would it make if we pick easy ideas first, and hard last? That should allow the team to test more ideas, and be more selective about hard ideas. Any specific reason for picking hard ideas first?
Nice idea. Little problem on my team. When u're the technical guy and then u're asked to rate ideas into easy, medium, hard. Some might feel you're deliberately rating their idea as hard.
You should be stack ranking on business value as well as implementation difficulty. Then you’ll have a x/y graph. Difficulty on the x, value on the y Hard to build, low value Hard to build, high value Easy to build, low value Easy to build, high value You want to pick the concepts that hit the middle of the upper right quadrant (which will be medium to high difficulty plus medium to high value). The bottom left quadrant is the area to avoid which is low value and low difficulty.
App Store review doesn't have to take weeks or even days. Nowadays you can just use Expo or Codepush. This might not be applicable in some cases though.
Sir, your videos are great to listen but not so so great to “watch”... would you consider inserting slides or some visuals to support what you are saying?
That was useful, cheers! A question: Do you have an interim period after a product release for learning from your customers before you start the next cycle, or are you starting the next cycle straight away?
Theo I just wrote my new cycle down and made it essentially a 3 week cycle with the 3rd week devoted to seeing results based on analytics, fixing any unseen problems, and then preparing for the next brainstorm meeting to be had at the end of that 3rd week. Haven’t tried it out obviously but it’s what my team and I will explore
I have so many ideas that I want to create that I'm most definitely sure that will sale tremendously I'm very passionate about all of my ideas I just don't know the first place to start I don't know who to talk to to make patterns and manufacturer them and honestly I am nervous on sharing my ideas because I don't want anyone to take them I understand you supposed to copyright them but can I copyright an idea before it's created? I mean don't I have to create the ideal and then copyrighted it? and I just don't know where I can find that type of support and hope that won't try to steal my ideas
This isn’t how product development should happen though. Customer development and ODI should dictate what makes it in a sprint, as opposed to design by consensus. This reduces the risk of burning capital and years.
Good point. I was wondering where the customer got involved in all these. If I'm to the guess, these ideas probably came from a customer discovery/validation phase that was completely prior
00:00 - Have a process to get product out the door
1:02 - Decide on a release schedule
1:15 - Put someone in charge of product
1:34 - Establish KPIs
1:47 - Create a theme for the product cycle based on a KPI
2:00 - Product meeting
2:30 - Brainstorm new features, bugs, and tests
3:35 - Sort each into: easy, medium, or hard
4:59 - Pick the hards first
5:30 - Spec the ideas out and assign tasks
6:00 - Shut up and get to work
7:00 - Testing
Y Combinator is it not best to tackle the ideas with the greatest value add with regards to a specific KPI or KPIs - as opposed to simply ‘the hardest’? Just curious. Thanks for sharing.
Thank you.
It would be great to see more videos from Michael. He is the reason I have notifications on for the Y Combinator channel.
I love how Michael always qualifies his advice with, "this may not work in your situation." To me, that's the hallmark of genuine mentorship.
Thanks Michael! Btw our method:
1. We defined AREAS of responsibility like product, backend, research etc.
2. We defined a person RESPONSIBLE for each area. That person DO all the job and TAKE any decision he wants in his area.
3. Everyone can and should ADVISE to others.
This isn’t gold. It’s platinum. Thank you, this talk was really eye-opening
This talk was truly enlightening and exceeded expectations. It's not just gold-it's platinum. Thank you for the invaluable insights.
I watched a video where you talked about this in Startup School 2018. A lot of wisdom from you on this. Thank you Michael. You are a great Guy ❤️💖💖
This is basically agile methodology. It definitely works for small to enterprise organizations. Agile always seemed pretty easy to understand because it's just common sense. I'm glad they tested this approach and it worked for them....it pretty much would work for most organizations. The important thing here is KPIs! Those who are presenting ideas should know what we are trying to measure and if we are accomplishing the goals we want to meet. Otherwise, ideas can get overwhelming and it's almost impossible to measure. Now, as far as testing, I would say what Michael is saying is not scalable at all. Maybe just for the initial stage, but testing automation should be done as new features are rolled out and that's all to it! If you don't have automated testing you will find release cycles getting ridiculously long as you have more test cases. PLEASE, for the love of everything dear, be serious about both Unit Test (dev) and automated tests (Test Eng). :) Love you guys and wish everyone the best of luck! :) Cheers!
"Shut up and get to work"... Jeff Bezos is also very big on this even at the highest level. Bezos' calls it "Disagree, but commit". If you trust the people around you (which you should if you're working with them), if your opinion is not the majority, and they don't place a disproportionate value on your opinion for this matter, it's best to disagree (not settle/fold) but commit to the plan and not hold anything against them if it fails. Bezos said he doesn't want disagreements to end in settling or negotiating, you should keep your conviction unless you see you were wrong, so if two people are VERY confident in their ideas and cannot disagree and commit, it goes to him for a decision. You shouldn't waste time on decisions that probably don't matter much in the long run.
This is the roadmap to success!
Best advice I've ever heard 👍
Thank you very much!!!
Years of knowledge and experience conveyed in a just 8 Minute video.
It was exactly how I did to get a $200K+ offer from a full accelerator - completing work within a cycle, an important key metric, count number of users. It came first with content generating and now I have to shift to another version of the product given a better infrastructure. And then count again :)
I fully agree with the testing part that it should be done by everyone. I mean QA testing and basically all testing around 'does the app work as we intended it to".
At a company I worked 2 years ago, they had no QA testers when I joined. My role was senior software engineer (fullstack) and I was doing most of the work together with the head of development (CTO in disguise). They were planning to expand the company and engineering team and we had a meeting about a QA guy they were interviewing.
The CEO proposed we should hire that QA guy so we could keep on writing code. I said that we (me and the head of dev.) would still do thorough QA anyway, with or without the new guy. So hiring him would not 'save us two time'. He asked me why do I believe that. I said 'qa is not meant for a single guy or a small team -- qa is EVERYONE's job, the more people the better, especially in a small scale-up.' He agreed (all of them did) and not only what I said has been considered and put into action but this also but me in a very good spot in the company. (just a side effect worth mentioning :D).
Great talk as always, Michael!
I appreciate these tips. I need to get product out the door fast! Thank you 🌹
One of the Most importent videos on this channel helped me a lot.
How to Get your Product out of the door:
1. Schedule release dates
2. Make someone responsible
3.Establish related KPIs
4. Brainstorming for improving KPIs: Pay specific attention to bugs and do not procrastinate on them.
Garde the generated ideas based on the difficulty of implementation.
First, implement the hard and medium ideas.
==> Write down what is going to be built around the ideas and who is responsible for them.
*Don't talk about ideas outside of meetings. Shut up and get to work.* ==> Have frequent scheduled brainstorming sessions.
Love this, especially putting all of the ideas up on the board without debating it. I love the objective framework process.
That's valuable. Thanks, Michael. Happy Holidays!
It helps. For example, the brain storming process. The way ideas are treated.
Thanks for this practical knowledge. Keep on doing it. I appreciate frameworks for processes that lead to better effects. I like explicit workflows and activities descriptions to model the process.
Fantastic video; thanks. It's such a nice change to have real advice given, in a respectful thoughtful manner, compared to the endless sea of big-mouths out there who seek self-promotion without actually contributing something useful.
this is so good!!!, thanks for making this video
Incredible value, thank you!
At 4:59, you mentioned to pick the hard ideas first. What difference would it make if we pick easy ideas first, and hard last? That should allow the team to test more ideas, and be more selective about hard ideas. Any specific reason for picking hard ideas first?
I think this is a time management technique, look at th-cam.com/video/8FbWb3f-jLQ/w-d-xo.html
Found Adora's time management video. th-cam.com/video/XcCmMOWuAF4/w-d-xo.html Much deeper dive in task selection.
Nice idea.
Little problem on my team. When u're the technical guy and then u're asked to rate ideas into easy, medium, hard. Some might feel you're deliberately rating their idea as hard.
You should be stack ranking on business value as well as implementation difficulty.
Then you’ll have a x/y graph. Difficulty on the x, value on the y
Hard to build, low value
Hard to build, high value
Easy to build, low value
Easy to build, high value
You want to pick the concepts that hit the middle of the upper right quadrant (which will be medium to high difficulty plus medium to high value).
The bottom left quadrant is the area to avoid which is low value and low difficulty.
I love your advice
Just subbed, these videos will help me so much. THANK YOU!!
Thank you.
Very helpful to remind hear how you did it!
Wow this is exactly what I needed to hear. I’ve been delaying the launch of my app because I’m stuck on wanting to make it better.
But what about sorting ideas based on Influence and not only complexity?
Very insightful.
That's great. I wonder how you would do it if you were ONE person.
Hey Michael, a small flow chart in a deck will add value
Simple and useful
App Store review doesn't have to take weeks or even days. Nowadays you can just use Expo or Codepush. This might not be applicable in some cases though.
Thanks, that was great!
I am going to use this process
What an awesome video! Now I need to find a team ...
Would love to see an acctual meeting example of this -.
Sir, your videos are great to listen but not so so great to “watch”... would you consider inserting slides or some visuals to support what you are saying?
TAZ for this video, god bless you
That was useful, cheers!
A question:
Do you have an interim period after a product release for learning from your customers before you start the next cycle, or are you starting the next cycle straight away?
Theo I just wrote my new cycle down and made it essentially a 3 week cycle with the 3rd week devoted to seeing results based on analytics, fixing any unseen problems, and then preparing for the next brainstorm meeting to be had at the end of that 3rd week. Haven’t tried it out obviously but it’s what my team and I will explore
Just a blank comment to give this video a boost in the algo.
u r funny
This video setup is a good example of a MVP: a board on a stool. 😊
why we have to pick the hards first?
I have so many ideas that I want to create that I'm most definitely sure that will sale tremendously I'm very passionate about all of my ideas I just don't know the first place to start I don't know who to talk to to make patterns and manufacturer them and honestly I am nervous on sharing my ideas because I don't want anyone to take them I understand you supposed to copyright them but can I copyright an idea before it's created? I mean don't I have to create the ideal and then copyrighted it? and I just don't know where I can find that type of support and hope that won't try to steal my ideas
GREAT
Just decide what would create the greatest IMPACT that DAY.
Why are there so less views?
"Make something people want" - How true is this for selection of startups ?
🎷
Sounds basically like scrum.
This is just basic agile methodology, which software engineers learn and use within 2 weeks of entering the workforce...
This isn’t how product development should happen though. Customer development and ODI should dictate what makes it in a sprint, as opposed to design by consensus. This reduces the risk of burning capital and years.
Good point. I was wondering where the customer got involved in all these. If I'm to the guess, these ideas probably came from a customer discovery/validation phase that was completely prior
Another 8 minutes of gold dust
...nice pitch! ...are you Elon Musk?
This is too simplistic using easy, medium and hard. Often times, to get to the easy one, the hard feature needs to be built first.
u dont have a company...u just teaching people how to do a startup without having a startup
He started Twitch, which sold for $960m to Amazon