Why you should always assume you are not going to make it on time.
MVP vs MVE
When developing a product or a feature, if you follow the lean methodology, you first need to validate demand. This means you apply the build-measure-learn cycle and try to ship a minimal viable product (MVP) to validate your hypothesis.
In a lot of cases you actually start with a minimal viable experiment (MVE). It may be a brochure for a product before you even wrote your first line of code, or it may be a landing page. It may also be a button for a feature (a trap door) where nothing is behind it, just to test if your customers would push that button before you go and develop the full-blown feature. There are of course many other ways to conduct experiments.
This article is not about the experimentation phase. It's about the phase that comes after you validated the demand. It is about the phase when you want to develop and launch your product or feature with a clear value to your customers.
This is where many people find it very hard to split the work to small minimal delivery units. Some people prefer to call this phase a minimum valuable product, in order to reflect that your minimal product must provide enough value.
Estimations Hazard
When you need to make decisions on a launch of a product, a big or small feature, you usually need to make some estimations. The challenge is that no matter how experienced you and the engineering team you are working with are, estimations will usually be wrong.
When making estimations, you might be too optimistic or too pessimistic. In any case, you definitely cannot plan for all of the surprises on the way.
Whether you are making precise estimations or T-shirt size estimations, you will still probably not be on the spot and might miss your target.
Scope or Schedule
Once you accept you are going to miss the target, you need to consider the dynamics. You usually have the following variables you can play with: scope, timeline, resources, and quality. For the sake of our discussion, let's assume the resources are given and you are not willing to sacrifice quality. While in rare cases you can play with the timeline, I would argue that this is usually not the right direction. A slipping timeline is not liked by anyone, whether it is the team that do not have an anchor, the customer who may be waiting for your product or feature, or your stakeholders that are never in the details. I would argue that for fast and value-driven delivery, it is always better to have a fixed timeline, known resources, and agreed quality. That means you need to play with the scope.
Who Prioritizes
You look at the scope and everything seems important; you cannot seem to give up anything.
Just remember that if you don't prioritize, someone else will.If you don't assign the right priorities, your engineering team will decide on the priorities according to what is comfortable for them, and not according to customer value. Then the timeline decides for you what gets left out.
How to MVP
Whether it is a product or a feature, I think it's always good to think MVP.
First, you need to think big, because you want your concept and design to be the best. Start by thinking about all the use cases and keep in mind the best experience.
Then, think what is your MVP in an unorganized and intuitive thinking. Make it value-driven, i.e., out of the big concept, keep only the things you think are a must for delivering any value to the customer. Think extreme.
This is where most of us stop, and start delivering. Usually, we also split the delivery into logical or architectural components.
This is where if you do it right, the magic happens. Now, after you think the scope is really minimal and you believe that you cannot reduce it anymore, make a big effort to go split your product or feature into 4 delivery units as follows:
Critical path: The things that if not implemented, will cause the feature or product to not work at all and bring zero value.
Barely made it: The things that you cannot launch without. If you just make it you will feel very embarrassed, but you can launch, with apologies.
What you want: This is the scope that you really want to launch.
The nice to have: These are the cherries on the cake.
Whether it's a product or a feature, I believe this method works for both and helps in creating a framework for making it on time.
Some Real-Life Product Example
A few years ago, in a startup I worked for, we just signed our pilot agreement with our first big customer. We had almost 6 months to launch the product, but it seemed like a lifetime. We thought hard about our MVP and came up with a reasonable scope.
Fortunately for us, even though we thought the scope was very minimal and easily achievable, we split it further into 4 delivery units according to importance:
Critical path: To give any value to the user on the field, the product had to be able to record some data on the mobile phone, pass the data to the cloud, analyze it, and give results. If any of the stages did not work, the user got zero value out of his day work.
Barely made it: The second part was to enable a user to create a reasonable model around the data he had to record, so he can easily access it later. The user experience could still be embarrassing, but we had a working product.
What you want: The third part was to make all the work really intuitive and friendly as well as to allow our experts to also analyze the results and learn from them.
The nice to have: This part included some nice enhancements we thought, at the time, were important.
We delivered the product just in time with only the second part achieved.
To this day, the 4th part and some of the 3rd part were never completed because on the way we found out that there were more important things.
A Feature Example
In a mission critical product, you need to properly monitor any perceived service outage.
This is the type of internal feature, where usually we don't think MVP. If we do think MVP, our instincts usually lead us to split the product by what we monitor and maintain a full scope for each monitored component.
Thinking about what is critical helps also here.
Critical path: The critical path includes the problems that are time sensitive. These problems happen rarely. When they occur, all you need to do is monitor and alert the team. There is no need for any dashboard."
Barely made it: The second part includes the less critical issues. Those that you are OK with taking a day to fix. Again, all you need to do is alert the team.
What you want: Now that you have the basics working, you want a nice dashboard that anyone in the team without any expertise can look at in order to identify issues.
The nice to have: You may want to include some nice filtering capabilities on the dashboard to allow a better understanding of the data.
In this case the customer is the support team and not an external customer. However, the external customer is deeply affected by the good work you are doing.
Summary
To make sure you give the right value on time, you need to start by thinking big, shrinking the scope as you can by considering where is the value, and splitting it into delivery units: critical, barely made it, what you want, and nice to have.
Apply this method for almost every product launch, big feature, or enhancement. It almost always helps.
Go MVP.