- The speaker faced problems in the early stages of their companies due to a lack of a process for getting products out the door
- They developed a process for releasing products every two weeks
- They had someone in charge of product who ensured goals were met and products were released
- Key performance indicators (KPIs) were established to focus on new content, new users, and retained users
- A brainstorming session was held to generate ideas, with no idea being debated or shot down
- Ideas were categorized as new features, bugs, or tests
- Ideas were then graded as easy, medium, or hard to determine feasibility
- Hard ideas were prioritized, followed by medium and easy ideas
- Ideas were then spec'd out and put into a product management system
- Once the meeting was over, work began and no further debate was allowed
- Testing was a team effort, with everyone in the company participating
- Bug fixing was done after all testing was completed
- This product development cycle worked well for the speaker's company, but may not work for everyone.

Y Combinator CEO and Partner Michael Seibel shares a process for building product as a small startup.

 https://twitter.com/mwseibel

Topics 
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

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.

Instead, me and my co-founders would have long debates, which would often turn into arguments.

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 product out of the door quickly.

Needless to say, you don't have to copy this process exactly.

In fact, you don't have to copy any part of this process, but what I'll tell you is that 1 of the more formal first processes that most good startups have is some process for getting product out of the door.

First, we figured out that we wanted to release our product once every 2 weeks.

We had an iOS app, it required getting approval from Apple, which took some time.

So a 2 week product development cycle made the most sense.

Second, we dedicated someone in charge of product.

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 1 was new content created, the second 1 was new users, and the third 1 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 the people in the company together, which at this point was tiny, it was 4 or 5 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 1 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 3 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.

Every single idea was written on the board.

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 1 of these categories.

Is this a new feature or an iteration existing feature?

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.

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 go through a process of easy, medium, hard that's headed by whoever's leading tech at the company, where they basically grade the ideas based on whether This could be done in a couple hours, whether it take half a day, whether it take multiple days.

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 2 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 1 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 1 or 2 hard tasks during a 2 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 wanna 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.

What you need to do is basically write up exactly what you want to build around that idea and exactly who's gonna 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 that everyone can be looking at the same document and everyone is building the same thing.

Then, once the meeting's over, you shut up and get to work.

If your idea didn't get built, that's fine.

There's gonna be another product meeting in another week or 2 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 idea should be built.

Either way, because you know that another product 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 product 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 1 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.

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 what 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 in that list.

We tried to figure out how to repeat them.

And then only after all the testing was done would 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.

I don't know whether it'll work well for you, but I can recommend that you


Speaker 0: 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. Instead, me and 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 product out of the door quickly. Needless to say, you don't have to copy this process exactly. In fact, you don't have to copy any part of this process, but what I'll tell you is that 1 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 2 weeks. We had an iOS app, it required getting approval from Apple, which took some time. So a 2 week product development cycle made the most sense. Second, we dedicated someone in charge of product.

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 1 was new content created, the second 1 was new users, and the third 1 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 the people in the company together, which at this point was tiny, it was 4 or 5 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 1 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 3 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 1 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 go through a process of easy, medium, hard that's headed by whoever's leading tech at the company, where they basically grade the ideas based on whether This could be done in a couple hours, whether it take half a day, whether it 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 2 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 1 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 1 or 2 hard tasks during a 2 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 wanna 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. What you need to do is basically write up exactly what you want to build around that idea and exactly who's gonna 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 that everyone can be looking at the same document and everyone is building the same thing. Then, once the meeting's 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 2 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 idea should be built. Either way, because you know that another product 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 product 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 1 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 what 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 in 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 would 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

See all Y Combinator transcripts on Youtube

How To Build Product As A Small Startup - Michael Seibel