How To Take Your Digital Product From MVP To Finished Product

So, you’ve got an idea for a new website, app or another digital product… but how do you know it’s actually any good? And how do you prove to stakeholders, investors and other parties that it’s worth investing in? That’s where your Minimum Viable Product (MVP) comes in.

All great products start with a problem. What problem is your user-facing and how can a new digital product solve it? The majority of our clients come to us with an idea for a digital product that may have great intentions, but fall somewhat short when we ask them: “is it what users want?”

Generally, an idea by itself is never going to be enough to get confident stakeholder buy-in, never mind defining your user behaviour.

You can have the world’s best theory, but without something that collects tangible, actionable data, you risk failure to launch.

Enter the MVP

The MVP takes things back to basics and helps you to focus on creating something that makes a tangible difference to your users’ lives, without the distractions of nailing the fine details right away.

MVP is a concept from the Lean methodology, which basically describes a product that has the minimal amount of effort invested into it, but can start to capture validated learning about users. Think Pareto - MVP’s focus on the 20% of features that account for 80% of the impact.

Many of our customers come to us with just a proof of concept or even just an idea of how their product ‘should’ work. While other businesses' customers come with their own MVPs, which have yet to be tested or progressed into a finalised viable product.

Whatever state your product is in, to actually finalise a product and call it viable, you must first launch a working MVP which often requires the implementation of the MoSCoW prioritisation technique. 

“MoSCoW - an agile method that breaks down a product by priorities: ‘Must-haves’ ‘should-haves’ ‘could-haves’ ‘will-not-haves’. This lets you quickly progress to launching a product with its bare functionality and begin iterative development as the product progresses. ”

— Product Plan

This is a simple yet impactful process: we either plan a new MVP or adapt an existing one to a roadmap designed around ‘must-haves’ first. We then plot out the ‘should’ and ‘could’ features - but these will change as user feedback begins to roll in.

Why can’t I skip the MVP and pay for a full launch?

Want to have more features at launch? A client can, of course, ignore our advice and instead delay the launch until the ‘should’ and ‘could’ features are built - but this typically extends the timeline and means you don’t get any feedback that may be critical to the experience.

BEWARE: This mindset can lead to the terrible ‘feature addiction!’

Imagine spending thousands on an app feature your team thinks is great, but post-launch users hate it and you have to remove it?

An MVP allows you to get to market faster, securing early sales and gathering feedback that may help save you money in the long run and make your product better. 

Without it, you’re acting solely on guesswork and what you and your team think is best - which is never as accurate or insightful as genuine user testing.

Launching The MVP

The ‘Must-have’ version of the product is the MVP that we launch. This meets the minimum functionality required to actually use the app and allows the user to accomplish the task it was designed for.

The MVP is launched and immediately, data should begin being captured through product testing, A/B testing and analytics. Our job is to monitor how users are interacting with the product so we can begin to create a new set of ‘should/could/will-nots’ based on real problems the user has, and not just your own assumptions.

This brings us to the iterative development process, which will change the roadmap originally planned by the MoSCoW method. Each stage of development should be based on users - and to do that, we’ll create user stories.

The Importance of User Stories for an MVP

It’s amazing how many companies wait until after their product is launched to ask their users’ thoughts and opinions.

You need to make your user concerns and desires your absolute priority, and user stories are a fantastic way of doing this in a way that all stakeholders can understand. A typical user story follows a standard process:: “As an X, I want to X, so that I can X.”.

Crucially, it’s not your job to create user stories - your job is to ‘collect’ them. If you’re thinking “we need to create user stories” you’re thinking wrong. Instead, a user story is generated through the experience of real-life users.

This again highlights the value of an MVP. It lets you see what a user is trying to do - not just what they think they might want.

Never Skip QA

Every digital product needs Quality Assurance (QA) testing - especially with an MVP.

A dedicated QA tester should be on board from the beginning to avoid pushing any updates live that would cripple user experience. QA is the last line of defence against issues that could impact your user’s first impression of your tool. When you build based on a user story, the QA’s role is to check for any critical issues that delay the launch date.

An Ever-Changing Release Journey

The best products are never really “finished” - Facebook is launching new features every month and Apple keynotes are the biggest date in the tech calendar. However, for you to get to the place where you’re comfortable releasing your product to the masses, you must go on a journey.

You should be iterating on the original roadmap as much as possible - what was originally outlined is always changed by user feedback which is only gathered as a result of the MVP process. This allows you to release in a more Agile method, implementing little changes more often to rapidly meet customer needs as they present themselves - this is particularly crucial for early-stage startups.

For example, at KOMODO we work with a client on a product that runs in 2-week sprints. The client has a product owner who is responsible for collecting feedback, feature requests and customer commentary to our team.

But remember: even if the user is specifically requesting a feature, don’t just build it - instead you need to consider what they’re TRYING to do and build something that enables them to achieve that.

This prevents a product from growing out of control. Imagine you launch and have 100s or 1000s of users - how would you possibly implement all of the requested features without the product becoming clunky, unwieldy and unattractive? This would make updates slow, user integration poor and overall experience sub-par.

BEWARE: That’s feature addiction coming in again…

Why the “Finished” Product is Never The End

When it comes to building digital products, the work is never done.

Take famous examples such as the apps owned by Facebook, Instagram, Twitter etc - they are still being developed, changed and updated as the product grows and new generations of users use the apps and the user stories change and grow.

A great product is one that is released as an MVP - It takes user data into account and then makes rapid, iterative changes that enable users to achieve what actually they need from the product. Only then can you really consider your product a viable release - but it must also continue to grow with you as your business and your users all evolve.