Introduction
Let's launch?
Omo! This is a big question that needs all variables checked. I will say that it's a big step in a product cycle.
Mapping out how to deliver features for a product can be very tricky, and it's a thin line to differentiate between v1 or MVP from the long-term deliverables of the product. Some individuals will claim to be dreamers that want to see all features scale in the first launch but forgive me (I am not trying to discourage you) launch date is N days + 1.
Launching a product can be delayed and where it gets frustrating is when quality and efficient hands are not on the project.
Here is a mathematical expression of launching a project with a feature base and launching with all assumed features.
Launching with stated MVP feature
N - 1
Launching all Features at once without a clear MVP feature (long-term feature)
N + 1
Where N is the assumed timeline.
When building a product, this could help to scale for your long term deliverables;
1. List long term deliverables:
It's the prelaunch stage where long-term deliverables need drafting. Research can help highlight some of the long-term deliverables. Most people often perceive long-term deliverables as their first MVP, which will only prolong your launch date.
You don't need to have the long-term deliverables figured out while developing the product. You scale through as you build what is acceptable in the market for your users. Also, while figuring out your long-term deliverables, you need to have something flexible that you can grow and adapt.
2. Extract core features for MVP
Core features help you clearly define what features you need to launch. Clearly state these features in the clear and most precise ways to designers, developers, and stakeholders.
Having these core features for MVP, I believe you are a step toward your long-term goal. Enough ingredients will be required here for the product to launch. Check out the article I wrote on the design process before developer hand-off. You can then launch in this stage while you move to the next.
3. Scale up by systematically releasing other features.
It's the post-launch stage. You carefully plan different features to be released within a specific timeline. Testing can be a good thing here as you can measure your success metrics to know what works best for the product feature and what will affect the future of the product.
Note: While doing these three (3) things to scale, they need testing. Not forgetting the fact that the main aim of launching is to first test the product with live users and backing decisions based on R&D as times change.
What is in vogue now might not be in the next 10years. So make sure your long-term deliverables are flexible to change or modify. An example of this scenario is the acceptance of Crypto (Blockchain) and Web3. So, your product should be flexible enough to fit in.
Case Study;
Having a look at Stripe
Stripe didn't start with all the features they have now on the platform. They scaled to what they have now since these updates are feature-based and released for testing to better user experience while having the business move forward. While still working on some features.
Another is Click Up
While having other project management tools that people consume, it doesn't mean JIRA/Confluence is their first MVP. They have their core elements/features and scale to what we currently have on Click Up. And I am sure that they have some things going on underground to be released that aren't public yet to beat their competitors in the space.
The downside of not differentiating MVP and Long-term product goal
Some mistakes people make is that because the designer research to pinpoint users' pain points, they now have to implement all pain points in one go. A look-through is needed, which can be your main selling point, and might require a lot to implement, prolonging your launch time.
If you don't have this line drawn, it's not certain users will be able to consume your product since you are focused on the long-term product features. Because long-term product features need to be flexible to adapt to any situation change, you need to draft out core features to launch.
Furthermore, you can't expect to have a full-grown product feature from other platforms as your first MVP when launching as this platform you want their current build to be your MVP has dedicated enough resources. You can make this your MVP, but the question to answer before proceeding is, ''Are you ready to put in the number of resources, face-ups, and downs to the point they are? I'm sorry to say if your answer is NO, you might not be launching anytime soon or in the future from facts gotten from my research. This platform you use as base elements for features is still working on some features underground, and making them your MVP feature will make you always be on the run to meet their hours of research and resources that aren't available at your end.
Advice from me, take these things in Little bits to launch. You can now add other features/elements as time goes on that won't take much time since most of the elements/features variables (design systems, branding tone, copy style, etc.) are in place. Though, these variables might require some modification based on testing. Always remember to make a feature for launching simple. The simple fact is that I want to use your product.
Build your ship while it sails.
A debate for other time is, ''what do we consider an MVP for launch in any product?'', ''Is it general or specific to a digital product type?''