Previously, we talked about prioritizing the features and had an introductory look into the matter. In this post, we will dive deeper and take into account the time and resources that it takes to develop a feature.
After talking to users, we will have a good idea about the set of value propositions we can deliver to the customer. The next step is to figure out what features we’ll have to include in the MVP. It is not a good idea to start with a product that has all the features that were thought of in the product. That would be crazy because we don’t know which features are going to be used most often and which ones will be barely used.
In the lean development process, once you understand the problems that your users have, you’re ready to work on the solution space. At this stage, we’re trying to pick the set of features that solve the user’s problems. What’s important at this stage is to think of as many different configurations as possible. This process is essentially a brainstorming session with your cofounder, team, or even yourself. You don’t want to limit yourself to a few ideas. Sometimes, we tend to lock on ideas and prevent ourselves from considering other ideas.
You should get a list of all ideas considered in the brainstorming session. It’s now time to prioritize those features and most likely throw out some of those ideas. We want to pick only a few (less than five) features to go with.
User Stories: Which features deliver the most benefit?
Bill Wake is a pioneer in Agile development and he has a set of rules for user stories. First of all, what are user stories? User stories are generated by overlapping many user interviews. It simply explains the user’s situation and what they are trying to achieve. For example,
As a mom, I’m trying to feed my child to stop her from crying.
As a data scientist, I need to quickly identify and remove the bad data to train my model.
According to Bill Wake, user stories should have a few qualities to be valid:
- Independant: Different stories should be independent of each other. In other words, they should not have overlaps.
- Negotiable: Founders should have the ability to negotiate the details of how the value can be delivered to the user. In other words, it should not be in a contract.
- Valuable: A good story should be valuable to the user
- Estimable: The scope of a good story should be clear. In other words, it should be easy to see the scope of the story.
- Small: Not only the boundaries of the story should be clear, it should also be small. Each story should point to a small benefit and not multiple ones.
- Testable: Similar to a scientific hypothesis, a story must be testable with user testing.
From user stories to feature sets
How do we break down user stories to feature sets? That is a very important question that most of us face when building a product. For example, the data scientist who wants to quickly train their models need to quickly and reliably clean the data. There are countless ways that one could achieve that and for an MVP, we would like to choose the most cost-effective ways.
For example, one way would be training models that look at anomalies in the data and does fancy statistical analysis to detect issues with the data. But for an MVP, we don’t have too many resources to do that. We can start with a rule-based system. First, we can think of a feature that finds NaN (Nonnumerical) values and remove them from the data with the user’s permission. Other features could be plotting the data and ask the user to put limits on the data or manually remove the data points that they think are outliers.
So, this way, we can break down user stories into small sets of features with very well-defined boundaries.
Once we identified these sets of features, we’ll have to look at our user stories and see which features are needed the most. We will have to start with features that without them the service almost becomes unusable. For example, on the Club House app, users could not chat with each other for a long time. They had to leave their links to their social media in their profile so people can send them messages directly. This feature did not stop people from massively using their platform. I am sure that this must have been a very calculated move. They prioritized other features over direct messaging without preventing the users to use the product for its main function which is audio chatrooms.
Return of Investment and prioretization
When we’re considering implementing a feature, we usually think in terms of ROI or Return of Investment. The question is how to quantify that ROI. The good thing is that we can do this without defining real physical metrics to do. As long as we roughly estimate the number of resources needed to develop a feature and the value that it delivers, we can calculate the ROI.
ROI = Return/Investment
We can calculate this quantity by associating an arbitrary unit for the return that we get. For example, we can use a number between 0 and 100 to represent this return. The more value a feature delivers, the closer to 100 it will be. There is not a scientific method for associating these numbers to the value of each feature. What’s important is that we can somehow be able to relatively scale the amount of value. For example, we should be able to say, Feature A delivers roughly twice as much value compared to Feature B. As long as we make sure we compare these features in a rational way, we should be able to compare their ROIs.
How do we calculate Investment? We have the freedom to choose units of time or dollars for this quantity and as long as we do it consistently, we should be able to compare the ROIs. Let’s say that we quantify the Return using a scale between 0 and 100 and Investment in units of weeks. Imagine that feature A takes three weeks to develop and it delivers 50 units of Return to the customers. Feature B however, takes five weeks to develop and it delivers twice as much value, 100 units.
ROI(Feature A) = 50/3 = 16.67 points/week
ROI(Feature B) = 100/5 = 20 points/week
Here, clearly building feature B takes priority compared to feature A.
THAT IS IT!
It really is simple as that. What is hard is having the discipline of sticking with this method and not getting distracted by the day-to-day operations of the company. I personally am trying to stick with this method of developing ideacooker.