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, my co-founders and I 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 don't 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 KPI 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 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. 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 of an 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 on 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, or 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 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 going to 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 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 part of a person who isn't an 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. 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 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 create some sort of cycle with some sort of cadence as soon as possible. Thank you.