Toolbox: Product Development Cycle

Hey Indie Hackers, here's our product development cycle for constantly ship products and measure them.

What is your process looks like? Do you think our process is good? How could we improve it?

Toolbox: Product Development Cycle

How not to be all over the place, and to ship constantly great products/features

It’s obvious for the startup folks that product is one of the most important things in the early days. Yet, most of the time founders think, they can build great products without a system. Even if there are exceptions, a high percentage of great products are the result of a concise system within a constant iteration.

Product Dev Cycle

In early days, startups usually don’t have any process for their product development. This is the reason why in early days you are probably all over the place. I’m not saying that you should optimize everything. Actually I think quite the opposite, you shouldn’t optimize anything but your product development cycle. I am not even saying your product, I am saying your cycle because you have to be constantly shipping and testing new things. This is how you can create luck for yourself.

We realized this very early, because we observed that each time we came up with a product/feature idea or improvement, we had different silhouettes molded up in our minds about our product. Also, we were all over the place; on Mondays we start building X and it becomes Y on Thursdays.

For short context, we are building Jooseph which is a content directory for human-curated learning collections from the entire web. When we are working for different specs with the same idea in mind, it was certain that we needed a process. If you don’t have a product development process, probably you need one too.

Therefore, I would like to share our product development framework. This process is not entirely our unique creation, we have searched for the best advice we could find. We have followed a list of great product development and management advices from Y Combinator which includes my favorite advice about the product development cycle from Michael Seibel.

Needless to say, you need scheduled meeting time to create a solid process. Our product meetings take 3–5 hours and we meet on a weekly basis. I recommend that you should create a weekly or biweekly process, longer periods are not fast enough for a startup.

I will explain following aspects in this essay,

Product/Feature Development Map
Conducting Product/Feature Meetings
Deciding and writing product spec
Measuring product/feature

Product/Feature Development Map

Core of our process is a 4 by 4–6 matrix for deciding what we should build next week; this can be product, feature, bug fix/maintenance or UX improvement in color coded cards. In our vertical line there is time which will be allocated for that product/feature. In the horizontal line, we have problems or micro-problems we expect to solve with that product/feature.

Here’s an example,
Product Dev Map

Problems to-be solved

Let’s dive into the horizontal axis, you’re trying to determine which problems or aspects stops your product from being more appealing, useful or powerful. In our case there are 5 core conditions that makes it hard to adapt our product; “Trust”, “Trigger”, “Friction”, “Stickiness”, “Frustration”. Some of those might be applicable for your case as well, but it can vary by product. They’re pretty vague terms but we have precise definitions for them.

Trust: Any question that comes to our users’ minds that creates doubt about our product. For instance; “How can I know this list is worthy of my time?”, “How can I know these resources are better than the ones I could find?”. If you have a marketplace startup, the chances are you have this problem. Since marketplaces’ whole existence is about trust.
Trigger: According to Dr. BJ Fogg, you need 3 things to change a behavior; motivation, ability and trigger. If your users already have motivation to look for a solution and your product has an ability to solve that problem, you just need the right triggers. For us, trigger is a some event, which we can influence, that reminds our users the problem and our solution.
Friction: Imagine a car moving fast, but there is friction between road and the tires. With less friction it can move faster. Basically, anything that makes it hard to use our product. To be clear I’m not just talking about usability. For instance, does your product need any hardware to be used or can they easily integrate their life.
Stickiness: Our product can be really easy to use and has no friction to integrate our daily lives. But is there anything stopping me from using it on a daily basis or is there anything that stops me quitting? We define it as “Any component/group of components that make your users very disappointed without it, so disappointed that might stop using your product all together ”
Frustration: These are basically the things that leave your user frustrated. This can be bugs or unoptimized flows.

Those are our product’s core problems but it can vary by the product and change over time. You can find yours by looking at the pitfalls that makes your users churn or complain. For example, we found out that there is a trust problem from a user at an interview in which she asked us “how can I be sure those resources are better than the ones I could find?”.

Allocated Time

Every time when we were discussing a new feature or improvement, I’d asked Tolga “How hard is it to build this?” and I always get vague answers. That is because difficulty can be a subjective term. Also, something easy can take a lot of time by having too many components in it, and vice versa.

Therefore, on the vertical axis, we basically reframed the question to “How long does it take to build this?”. This will help you to understand the difficulty of that feature/product, especially for non-technical founders. When you’re trying to move fast, it’s really important to understand how much time you’ll allocate to build a feature/product.

We have 4 stamps on the vertical axis; hours, days, weeks and 1 month. We think, there shouldn’t be a spec that’ll take more than a month, you’re in a world where everything moves crazy fast. You can only afford that if only it is vital, or you’re pivoting.

Another perk of this approach is elasticity. For instance, a feature/product can take weeks for the teams who have one engineer but if you have 3 engineers then weeks might be hours for you. In short this approach is much more adjustable.

How to use it

Your goal with this map is to let everyone in the team see the big picture and communicate easily about solutions. For instance, let’s assume you founded Airbnb. There is a massive trust problem for your users, then you start coming up with solutions and you know how much time each idea will take. You place those ideas on the map and you have a bigger picture about what to build next.

You might be asking but what if one of those solutions is more effective at solving the problem than others, isn’t it still foolish to choose the fastest one? I have two answers for this question. First, there is a high percentage of chance that you’re wrong about your assumptions (like us), so the feature you assume to be more effective might be useless for the user but another one can be ground breaking. Second, that is the art behind the science, you have to predict which feature will take off according to the insights from the data you have, and the user interviews you have done. Still do not rely on your prediction, this whole process about being fast and creating luck for yourself. Rely on the luck you created for yourself.

Conducting Product/Feature Meetings

Now that we know the basics, we can get into deep on how to conduct those meetings. We have a couple of specific methods which we use in our meetings to come up with ideas.

At the beginning of each meeting, we determine the micro-problems that we have under the subset of main problems(Trust, Trigger, etc.), by looking at the data and user interviews we did. Then we usually try to find root causes of those micro-problems. For example, you’re building a social app for wine drinkers, and engagement of your power users is dropping down. Why could that be happening? You find out there are too many spammers that share unreliable information in your app which creates trust problems. Now you have your micro-problem under the trust which is basically churning users because of unreliable information in the platform.

We have the following cards for these micro problems

Micro Problem Card

If you’re having hard times to find those core reasons of the problem, one of the ways to overcome this, to ask why for 5 times. It’s a really simple but effective method to understand the root causes of problems by Sakichi Toyoda. After finding out those problems and core reasons, you should write it down to address them over the course of the meeting.

You have problems and hopefully root causes in front of you. It’s time to come up with ideas. If you have tons of ideas to address those issues, it’s nice. You can just place those ideas on the map to see the bigger picture and decide upon your features and specs. But what if you have no idea how to solve those problems?

If this is the case, from time to time we find ourselves in the same situation. It’s harder to come up with rational solutions than it seems, on the other hand, being daydreamer and coming up with science-fictional ideas is easier since you have no restrictions. We start using this method of coming from perfect/out of mind ideas to reasonable ones which we got the inspiration from Airbnb’s CEO Brian Chesky.

Imagine a ruler that goes from 1 to 15. You’re standing at 15, coming up with most out of mind and science-fiction ideas/solutions. When you look down from this ruler, you see 5 which is the current state of the world, under 5 you have the old solutions. You’ll descend this ruler from 15 to 6, one by one with your teammates finding more reasonable solutions in each step. When you come to 6, it’s your MVP for the problem you’re trying to solve. Your short term goal is to build 6. If it works, if your assumption turns out to be true, you’re trying to reach 7 or 8 as soon as possible.

15 Ruler

For instance, you’re building TurboTax Online which is a software that helps you to calculate and pay your taxes. For TurboTax Online itself, 4 would be pen, paper and calculator, and 5 would be excel. In the first step, you’re aiming for 6 which is creating an easier way to pay your taxes. Standing at 15 you can think of an all integrated AI solution for calculating and managing all your taxes and accounts, it just makes all the work for you.

Now you have the ideas and you started writing down those on the cards. We have 3 sections in our cards which consist of name and short description of the product/feature, and Goal KPI.

Here’s an example,

Solution Card

Deciding and Writing Product Spec

Since your map is all set up, you can start choosing ideas which ideas to build next week. We don’t have a specific method for that, like choosing the top right corner of the map. As the name suggests, it’s a map. It does not guide, if you don’t know where to go. On the other hand, at this stage you should be able to see the more profound and better ideas which takes less effort.

You can now try to pick ideas to fill your weekly chunks of time. For instance, you can choose four bug fixes which takes hours and a feature that takes days to build.

After deciding what to build next, it’s time to specify your product/feature to make sure that you and your teammates agree upon details. This will help you to create a similar image on everyone’s mind, then write your specs in a very detailed way. We use a simple google doc to log our specs.

One of the things that you must pay attention to is prioritising. For instance, X feature has 3 different objectives, in the order of importance those are F1, F2 and F3. If something unexpected happens or somehow you misestimated the production time, you’d know which components to prioritise.

Measuring Product Feature

Some people can underestimate the importance of measuring, but I believe most of us know how important it is to measure what you do.

As a startup, you’re being chased by a bear called time in a foggy winter at a canyon and in a matter of seconds you can fall off the cliff. Measuring is your flashlight, use it or you’ll be dead soon.

We track most of our tests in a spreadsheet. Basically we wrote the name of the feature/product, short description, Goal KPI name, Last 2 Weeks Average of Goal KPI and Following 2 Weeks Average of Goal KPI. Those are the things we track for measuring our cycle and progress. For each feature/product we have specific goal like increasing retention 10%.

Never Ending Process

I tried to explain our product development process, I hope it inspires you to shape yours or you can basically use ours. This is a never ending process, it only changes its form. Our process has been performing great for a small sized early stage startup, you might need something more advanced. You can follow Y Combinator’s curated product list to find great advices from industry experts.

Our process basically consists of 4 parts which are understanding root causes and micro-problems, mapping ideas according to root causes, choosing ideas and writing specifications and lastly we measure what we build. We try to determine micro-problems under the subset of main problems, and understand root causes of those micro-problems. Then, we follow up with ideas that can solve those problems, and map them on our development map. We build consensus on which product/feature we’ll build, and write specifications of those features/products. Lastly, we measure what we build and we either kill or improve the product by the outcome.

Jooseph is a content directory that enables you to find/share high quality resources through curated collections.

You can find human curated collections of resources about product, growth, technology, design and more in Jooseph: Sign Up Now

Hey Indie Hackers,

What do you think about our dev cycle? Do you think it is good? How can we improve and what do you use for developing your projects?