The way we do product development

Our app, Skyvi, released a few months ago, has over 1.5 million downloads and our user base is growing strongly with every update. Skyvi is far from the first product we built. In fact, in the past 4+ years, my partner and I built over 20 products, and most were flops and some are too embarrassing to even list by name. But through those experiences, we developed a methodology to do product development that we believe is correct. And today, I'm sharing it.

The first step, also the hardest to get right, is knowing what to build. This one took us forever to learn because we are engineers. In the beginning, we just built stuff, all kinds of stuff, and it was easy for us. We didn't know if it was going to work, but since it only takes a week for us to build it, it didn't seem like it was going to hurt to try. But it does hurt. Experimentation is sometimes necessary, but it's never an excuse for not thinking. In the beginning we were building very simple products and it can take a week or so. But as things got more complicated, it started to take longer. Our last flop, cost us almost six months! Six months! How many six months do you have in your life? Tell me that's not expensive! So, everything we build now, we think hard about what we're going to build first. An engineer's habit of just going out and build things is very difficult to break. But I believe breaking that habit is absolutely necessary.

The next step we do is to try and estimate feature effectiveness. I think this is quite unique to the way we do things. Suppose a feature is going to say, increase revenues, we explicitly state the amount that the revenue is going to increase by this feature. This may sound impossible to anyone who hasn't tried it, but I assure you, it's very possible. This step forces us to break down the feature from the user's perspective. If we don't know something, we reduce it to something we do know. For example, if we have no idea how many people are going to pay to remove ads, we can break it down into steps based on the feature. How many people are going to see the "remove ads" button? How many are going to click on it? How many are going to click through to the in-app purchase link? How many are going to have a google checkout account? How many are going to finish purchase? We try to find comparable data from our current product, other similar products, and our best guesses at each of these questions. Plug it all in and multiply, out comes your estimate. The more we do this, the better we are at answering these types of questions.

Building the product is what we do best, but it is still not easy. Sometimes a feature is actually several smaller features. They need to be thought through, individually and in aggregate. In a team environment we have used scrum to manage the actual development, but when it's just my partner and I on the project, we use a much lighter weight solution. We cut aggressively. If there's a feature that we think only marginally help with our business objective, and it takes disproportionate time, it won't make it. Proper prioritization is key and everyone agrees on and sticks to the prioritized list. Hitting deadline is absolutely essential, and we don't miss. There's nothing worse than having a great idea, and get usurped in the market because you blew your dev schedule. This is also the step that is the most parallelizable with a team.

After the product or feature is built, it's not quite ready to go out yet. It needs to be tweaked. Product tweaking is a black art and is a specialty of my partner's. He has a very keen nose to sniff out which part of the product needs minor touch ups. Maybe the error messages should to be re-worded, or the activated version of the mic button needs a textured background. I hate this step, because I have no patience for it and the engineering is neither interesting nor particularly challenging. But it's absolutely necessary to take the product from good to great. It's awesome if there's someone on the product team that's especially good at this. All you have to do is give them a few days to do it and don't get in their way. But if you don't have a tweaker on board, time box this step and do as much tweaking as you can.

Lastly, after the product launches, we must measure feature effectiveness. You are collecting data, aren't you? If you don't know if your bullet struck the target, why the hell do you even bother to aim? So, in step two we made estimates, and now we check how close reality is to our estimates. From this, we can see either the feature did exactly what we set it out to do, or a faulty assumption exists somewhere in the chain. And we would know exactly which link of the chain to blame and do better next time. For the last few months, we've found ourselves being able to confirm our prior estimates. To us, it implies that we're getting better.

Not every product you build is going to work in reality. The challenge in product development is to make sure that when a product doesn't work, the fault should be in an assumption that lead up to the product, and not in the product itself. In other words, the product does exactly what it is supposed to do, well made, minimally viable, and released on time. The product failed because people just didn't care for the problem it solved for them. That my friends, is a separate problem all to itself...