I think most people intuitively know the difference between an MVP (Minimum Viable Product) and a POC (Proof of Concept).
But I think that sometimes people start work on an MVP when they should be working on a POC. And sometimes people don’t stop after a POC, they keep adding more features and continue proving more concepts, hoping that they will end up with an MVP.
Difference Between a POC and an MVP
We build a POC to demonstrate feasibility, this helps us: derisk technical implementation and explore unique concepts. Very often a POC is for internal use only and therefore doesn’t require the rigour of a normal development:
- insecure, hard-coded logins
- not tested
- no GUI, explored purely from @Test methods
- unusable except by a developer
- undocumented
- etc
An MVP is for customer use, it demonstrates viability i.e. can this Product survive in the marketplace, is there a demand, does it meed user needs, would they use it?
And MVP is typically designed for gather feedback, either explicit or tacit. An MVP needs to be usable, robust enough that it doesn’t fail in normal operations, secure enough that it doesn’t leak user information, etc. But all of that can be done in a Minimum fashion.
For example - minimal security could be: instead of creating a login procedure and storing usernames, personal details, and passwords. We instead, authenticate via Twitter or Facebook, store access credentials in the server session, and allow the user to save any persistent data offline rather than storing it on our servers. This may not be the best persistent usage experience, but it may support the minimum functionality required for the product without requiring a full architecture to support the implementation.
The most important part of working with a POC or an MVP is knowing which you are working on, and explicitly making the transition between them clear. They require different approaches to testing, implementation, evaluation, and commitment.
An Example - Instagram ‘See Link in Profile’ Posts
As an example, for Instagram, I wanted to maximise my ‘see link in profile’ functionality. For those of you that don’t know what this means, Instagram only allows one clickable link (in your profile), if you embed a URL in a post, it is not clickable, so the common approach is to include a URL and also say “see link in profile”. And then, you change the link in the profile to point to the link in the most recent post. I thought it better to link to a page that had an archive of all the posts which included clickable links. That would then require less maintenance and I thought might add more value.
As a POC, I needed to demonstrate the feasibility of triggering a process when I posted an Instagram post which included a URL.
I considered:
- a CRON job that would trigger a PHP script to use the Instagram API to find recent posts
- a desktop app that would run on user login i.e. every day, and use the Instagram API to find recent posts
- IFTTT
- A Zapier flow
I thought Zapier or IFTTT, if they worked, would be easier to start with, since I wouldn’t have to write any code.
I tried Zapier, found a recipe that called a URL everything a new Instagram post was created and tried that. By writing a simple PHP script that could be called, I demonstrated the feasibility of the Zapier approach.
I had not used Zapier before, so all my POC had to demonstrate was that this worked. I already knew how to use PHP to parse JSON information POSTed to it.
I then moved on to creating an MVP:
- expand out the PHP script to write a subset of the Instagram post details to disk when the post contained a URL
- create a simple PHP list view that rendered all the cached details
An hour or so after the POC I had an MVP running.
- the view is a single page and could do with pagination functionality
- the cache is only stored on the server and I need to manually FTP the cache to my desktop version control system
But it works, and with Google Analytics I gain tacitly acquired feedback about how many people are visiting the page.
An Example - Instagram Post Archive
I wanted to have an off-Instagram cache of Instagram Micro Blogs because part of my social media strategy was having an easily searchable archive of all my online posts.
When I started working with the Instagram API, I created three POCs. All with hardcoded app authentication details, to experiment with different approaches to extract information with the API. My POC finished when I had instantiated a local collection of Objects with the data I wanted to extract from the API.
My POC did not include:
- serializing the Collection of Objects to disk
- tracking the progress of which Instagram objects I had processed between executions
- creating a GUI to render the Objects
I already knew how to serialize data, persist it to disk and create GUIs in SWING, JavaFX or via HTTP server. The POC did not need to cover any of that.
I didn’t know which libraries to use, or how to authenticate or create an Instagram app. The POC did need to allow me to explore that.
I tried three times until I demonstrated to myself an option that I thought I could feasibly take forward.
I then created the MVP.
As an MVP, I did need to:
- serialize the collection of objects to disk
- track progress so I did not reprocess Instagram entities from previous sessions
- test that it works to my satisfaction
- use it, and deploy it to production
But, since this was for internal use I did not need to:
- create a GUI to execute the code - I can happily run it from an @Test method
- create an OATH flow, or login process - I can use hard-coded application level authentication
An Example - ChatterScan
An even more recent example, I wanted to have a lightweight and faster reading experience for Twitter as I was getting bogged down in too much noise.
As a POC I wanted to see:
- is there a library I can use to authenticate and access Twitter API?
- can I filter Twitter feed to exclude re-tweets?
- can I filter Twitter feed to only show posts with URLs in them?
This turned into a three-phased POC.
First selection of an API. And the PHP https://twitteroauth.com looked like a good first choice as it had clear documentation. Because OAuth required a callback process to a live site, I had to ‘build this in production’ so I used a subfolder on my main website.
Each of the POC phases built on the other. But there was no sense that I was building an MVP, I was only rendering ‘just enough’ information to support the POC.
When I was satisfied that I could use the library to do what I wanted, I then moved into internal MVP mode.
- I tidied up the GUI
- Complied with Twitter API usage rules
- Added pagination.
I had something that I could use internally, but I clearly couldn’t give to anyone else and expect them to use.
When it was at the point that it wasn’t super ugly. I moved into external MVP mode.
- added a privacy policy page
- added instructions
- added contact details
- bought a domain name
- uploaded to a cloud server under the domain
I then ’effectively’ went live as an MVP.
I then built on it as an MVP:
- added Google Analytics to gain tacit feedback on usage
- submitted it to Google to have it appear on search engines
And now I can see that it has been used by people in the UK, USA, Brazil, and Japan.
You can see the MVP at ChatterScan.com and the development of the ongoing MVP features are on my plan.
Clearly, it still requires work:
- it isn’t pretty
- probably doesn’t inspire ’trust’
But it has ‘minimal’ functionality to be usable, it is live and ‘viable’, it has a name and has been released as an external product. And personally, I find it incredibly useful for reading my twitter feed.
It very quickly moved from POC to MVP, but it did so in clear stages and there was no blurring of the lines.
Be clear on POC or MVP
I see too many companies blurring lines between POC work and MVP work.
A POC is often delayed due to an ROI statement, or discussing the scope of the POC, because it is not clear what ‘feasibility’ questions people have in mind. Sometimes, what people have in mind for a POC is actually an MVP.
Move on to an MVP after all the risks and feasibility questions that you have identified have been addressed. Then your speed of creating the MVP increases because you are building on the knowledge that you already have. And you’re building it to answer the question: will anyone use this?
When the lines between the two are blurred there is often no clear endpoint. There is often no release to the end user. There is often no plan. There is often a high risk of cancellation with no value being generated: either in terms of learning or potential revenue.
Also, bear in mind that an MVP probably isn’t Version One of your product. It is just Step One. And the lines can become blurred even more when you start expanding your MVP.
