How To Build Product As A Small Startup - Michael Seibel

a lot of the problems that i faced in the early stages of my companies were because i didn't have a process to get product out of the door um instead me my co-founders would have long debates which would often turn into arguments we wouldn't write clear specs we wouldn't hit our deadlines and we would get very discouraged over time i realized that very few people actually teach you how to get product out the door they tell you it's important to push but they don't really explain how so here's the process that we came up with at my last company to try to get a product out of the door quickly needless to say you don't have to copy this process exactly in fact you have to copy any part of this process but what i'll tell you is that one of the more formal first processes that most good startups have is some process for getting product out of the door okay so this is what we did first we figured out that we wanted to release our product once every two weeks we had an ios app it required getting approval from apple which took some time so a two-week product development cycle made the most sense second we dedicated someone in charge of product uh that was me to be clear in charge of product doesn't mean they get to decide what's being built what it meant was that they were responsible for making sure that we met the goals of our development cycle and that we got product out the door third we established what our kpis were our kpis in that company the first one was new content created the second one was new users and the third one was retained users the next step was that whoever headed up product would create a theme for this product development cycle based on the key pi we were attacking so let's say this week we're attacking how do you retain users we would bring all people in the company together which at this point was tiny it was like four or five people and we'd have a brainstorming session we told everyone was that the product development cycle would start with a product meeting and it'd be the only formal meeting we'd have but it had to go as long as it took for us to come to conclusions so only one meeting but we have to get to a conclusion on what we're going to build so at the beginning of the meeting what we did was we had a big whiteboard and the whiteboard had three different categories on it new features bugs and tests that we wanted to run then we went around the circle and everyone came up with whatever ideas they thought would move our kpi remember would move user retention every single idea was written on the board no idea was debated it was not the time to shoot people's ideas down if you had a question about what the idea was someone could clarify it more but otherwise people would say it be written on the board of course it was written in one of these categories is this a new feature or an iteration existing feature is this a bug or is this a test the cool thing about putting bugs on that list is that oftentimes bugs are the things that are preventing you from growing or preventing you from retaining users and oftentimes they're kind of put in this weird maintenance category and they don't get done with us bugs were actually put directly in the product development cycle awesome so once that brainstorming was done you had a whiteboard full of features full of things that we could do the next step in our process was called easy medium hard so we had a variety of people in our team some more technical than others and sometimes it was hard for people to understand how easy or hard their idea was to actually build so you go through a process of easy medium hard that's headed by whoever is leading tech at the company where they basically grade the ideas based on whether this could be done in a couple hours whether it would take half a day whether it would take multiple days easy medium hard now once you see all the ideas on the board first of all you feel included in the process so every person in the company feels like they've been involved in the process of coming up with what we're going to work on in these two weeks second once you see other people's ideas you start thinking maybe some of them are better than mine maybe i want to back some of these other ideas instead of my own and then third once you see easy medium hard that's when things get really fun because suddenly you realize that maybe one of the best ideas on the board is an easy idea that's fast to build and maybe the idea that you were pushing was a medium or hard idea that's slow so suddenly you have this kind of objective framework to look at what's going on and to figure out what to build as opposed to just arguing based on what you believe or what's in your head then the next step in our process what was called pick the hards first you know with a small team you could probably do one or two hard tasks during a two-week period of time so it's easier to debate just the hard ideas because once you see those medium and easy ideas that might be more effective a lot of the hard ideas fall by the wayside once you've picked the hard ideas that you want to work on then you pick the mediums then you pick the easies you write those in a list and the very very next step while everyone is in the room is to spec those ideas out you need to do is basically write up exactly what you want to build around that idea and exactly who's going to be responsible for what part you do that in the room so that there's no confusion about what's going to be built and then you put that spec in whatever product management system or software that you're using so everyone can be looking at the same document and everyone is building the same thing then once the meeting is over you shut up and get to work you don't continue to debate if your idea didn't get built that's fine suck it up there's gonna be another product meeting in another week or two where you can bring your idea up again even better maybe you can go into your analytics system and find more evidence for why your ideas should be built either way because you know that another part development cycle is coming up soon you don't have to hold on to the baggage of not having your idea being picked as the product person especially part of person who isn't engineer it's even more important to shut up don't change the spec don't change what people are working on you have this fixed period of time and the most important thing is to get product out the door into customers hands and then learn from them and if you have confidence the development cycle is working well you'll know that even if this cycle doesn't produce the results you want the next cycle will or the one after for us specifically doing a mobile company the last part of our product development cycle was testing it's kind of hard to push bug fixes out on mobile apps it takes some time you have to go through apple approval so you have to be a little bit more careful about testing for us testing was a full team job because everyone hated it so we did was we had a long list of things to test that was historical and then every time we did a new release we added things to that list and then we had a saying everyone tests as a result all the engineers and everyone else in the company we all tested everything on that list once we found bugs we wrote them down we tried to figure out how to repeat them and then only after all the testing was done with the bug fixing be done as a result everyone sucked up the painful part of testing together so this was a product development cycle that we created it worked very well for us i don't know whether it'll work well for you but i can recommend that you create some sort of cycle with some sort of cadence as soon as possible thank you you

Channel: Y Combinator

Views: 104,074

Rating: 4.9513888 out of 5

Keywords: YC, Y Combinator, How To Build Product As A Small Startup, Build Product, Michael Seibel, Product Development, Product Development Cycle, Startup, Tech, Building Product, Product Management, PM

Id: kzVvjKLdAbk

Length: 8min 21sec (501 seconds)

Published: Fri Dec 27 2019