Are you developing gigantic features and modules and just picking things off the list to progress through? If so you might want to re-assess your situation and start planning the development of smaller modules.
It’s important to have your MVP (Minimum Viable Product) defined and understand what components of your platform are critical to release first, these are the ones that will immediately provide value and will engage your users. By doing this you can then work in a Full Agile or Managed Agile approach and be able to quickly iterate your product, get feedback and improve upon it.
When working in the old ways of the “waterfall” module or a less organised approach of just picking things at random, you can get stuck in the process of just continuing towards the direction you were last headed. You don’t have a reason besides it’s on the list as we said we would do it. That is not good enough to deliver a successful project. You must pick features that deliver instant value.
Do not implement an entire User module in the MVP, while you may think you need the ability to :
- login
- logout
- forgot password
- register
- view profile
- update profile
- upload profile picture
Which of those are actually critical to delivering an MVP, what will allow your users to engage with the software and start seeing immediate value. The User module in the MVP would probably look like this:
- login
- logout
- forgot password
Those three elements are enough to get people using the system and provide authorised access to the rest of it. Unless you’re making a social network then you don’t need the other features yet. They are nice-to-haves during the MVP phase.
You would only add “register” initially if you wanted to release it to the public, not a closed group of people. The register functionality could be added as a Milestone 2 release and the rest would be included where they fit with the vision and scope of the project. Based on the feedback you may not event need to upload profile pictures. Now by listening to that user feedback and asking/polling for features, you might save yourself the development effort of building something that no one really needs or wants.
In maintaining these small modules and feature sets you can release quick and adjust your plan as you go. No one wants to map out and get involved with a 12-month development. Things change all the time and you need to adjust and pivot, whether it be based on feedback or external factors. Things can change at any time.
We’ve gone through scenarios where:
- Budgets were removed altogether and all development had to stop
- Budgets were cut-down and only a certain amount of features could be made
- Clients business changed direction and the majority of the planned work was no longer relevant
- The idea for a project was not viable and cost-effective when we looked into how it would be implemented
- External factors affected the project
The only reason we could pivot and adapt to those changes is that we work in small features or modules and only deliver the core features as we go. This prevents us from getting stuck in a path wasting effort. In the scenario where budgets had to stop altogether, they had an MVP that could be delivered. If we were working in any other model they wouldn’t have had a working MVP as we would have been delivering complete modules one after the other.
We’ve even experienced this in developing our own product. Shopfront Solutions is a retail marketing platform that was Version 2 of an existing desktop ticketing platform. The product was commercialised and on-sold to the rest of the market. We followed the processes we describe:
- DevReady – planned and designed the platform based on the existing features and feedback from stakeholders
- Prototyped the concept to prove it was technically feasible – we chose a technical solution and proved it’s validity
- Planned the MVP
- Started development
Our plan was to use the ideas proven in the prototype and our entire DevReady process which identified user stories, requirements and business model was built around this.
We then planned the MVP based on the prototype and had a clearly defined plan. We then started the development and began to complete core features and release them internally for testing.
Then prior to the integration with the technology we had proven to work in the prototype, we had discovered that it was being deprecated by web browsers and would no longer be a viable solution to bring development. The small module deliveries afforded us time to review each thing we released and asses its viability as we progressed. After each release we would then plan the next development and look into how it would be implemented, it was in this step where we discovered this giant problem that affected the product and the entire business model.
If we had not followed this process and defined an MVP and core features, we would have leveraged the prototype and built out full modules over the course of 6-12 months and then found out upon completion of the system that our solution would not work and would have to start over again. This process saved 6-12 months of development and allowed us to pivot and adapt the product to new technology.
It really is critical to have an MVP defined that will allow you to focus on the core features, how you define what those features are is unique to your product. Keep in mind the following:
- an MVP can be developed in multiple stages
- each stage needs to be assessed as it’s released
- ask for feedback from users
- analyse and asses feedback
- always look at your external dependencies, they can change at any time
If you follow these points you will be creating an environment of constant releases and development maintaining momentum in your project, setting up an environment that allows you to pivot or adjust your product to feedback and constantly provide value.
