TL;DR
If I build all these features it will take me 6 months for the first release where the feedback loop is huge had probably there is a huge risk of failing.
The issue is that you have fundamentally misunderstood both the purpose and scope of what a "minimum viable product" is, and what it is supposed to do. This is a common problem, and you are certainly not alone in misunderstanding it, but you need to reframe what you're doing (which sounds more like developing enough for alpha or beta testing) which you are unprepared to invest in, or switch gears to a real MVP approach. In either case, you must pivot from what you are currently doing, and take a radically different approach.
What an MVP Should Do
What you're describing is not a "minimum viable product" at all. You're describing a ready-for-market product, which is a very different thing. An MVP is a tool for validated learning, and is really intended to be the barest minimum you need to test a market hypothesis. In the laundry list of things you describe as being essential, most of them simply don't meet the definition of "minimum," nor do most of them really provide a clear path to validated learning about your target market.
If you're really striving for an MVP, you should toss your laundry list of functionality and replace it with the smallest amount of work you can do to gain useful feedback from the marketplace and your target customers. This might take the form of:
- Wireframes or models.
- Some pretty UI mock-ups with decent artwork and a clearly defined user journey.
- A walk-through of the user experience a customer might experience, whether in visual or narrative format.
- Possibly a small piece of working functionality like a home page, or something else you can show off as unique or special, but that is designed to elicit feedback rather than for actual use.
An MVP that creates validated learning lets you know whether whatever you're planning to build is viable in the marketplace, and tells you whether you're on the right track or need to pivot. In other words, you want to gain knowledge or fail early; it has absolutely nothing to do with whether the product is functional or usable in its current state, and everything to do with whether people would be interested in investing in it now or paying for it later if it was.
What You Have Now
You have a large project with no defining unique characteristics, no incremental or iterative seams, and no opportunity for validated learning short of building the whole thing from stem to stern. There are plenty of e-commerce platforms and software systems already on the market; building another one may be a project, but is not in itself a business justification for doing so.
If you decide to go down this path anyway, then what you should do is define a set of minimum vertical slices that you can deliver quickly so you can get maximum UX/UI and business feedback about those slices as fast as possible. For example, and probably in this general order:
- Build a home page, but grey out the "add to cart" button as future work.
- Build the minimum back end you need for a product database, but populate it with a single product for demonstration and feedback purposes.
- Build a login page, but leave user validation, management, and other complexities for future iterations.
It's pretty much the same for everything else on that list. If you want the benefits of agility, and the benefits of validated learning and tight feedback loops, then you must adopt a development process that embraces small increments of functionality, iterative development, tight feedback loops, and most of all an unconditional embrace of the YAGNI principle.
Look at it this way:
- If the market is not interested in what you're proposing, you want to fail early and possibly cancel the project before you've spent a lot of money on an unsalable idea.
- Alternatively, if you learn something from your MVP that requires you to pivot your product or business model, you may end up building something entirely different from what you originally envisioned. In that case, having built it already represents a sunk cost that could have been avoided.
In either case, while you might need all those features for a working e-commerce site that's generating profit to continue bootstrapping the company, you do not need them (possibly at all) for an MVP, and certainly not all at once as part of an emergent design process such as Scrum.
See Also
