How To Do An MVP When An MVP Isn’t Actually Viable

timyo mvp

Before jumping into the nitty-gritty details of creating an app, or even the broad strokes of what that app should do, the product vision needs to be very clear. What is the one-sentence reason for this product existing? If this product really takes off, what do you hope to accomplish with it?

With Timyo, before we started on anything, we had a very clear vision of what we wanted to accomplish: introduce the notions of time and clarity into email, in order to save time and improve everyone’s lives (well, at least everyone that uses email!). Pretty simple, right? Once we were all clear on that, it was much easier to start into the actual product design and feature set. I mean, if you don’t really know what your product is trying to achieve, what good are a ton of features going to do anyone?

To MVP Or Not To MVP?

Once we had a clear vision, we needed to decide if our next step would be an MVP, (minimum viable product,) or a POC (proof of concept). In many cases, the MVP is the obvious way to go. First of all, you get an actual product on the market—you’re off and running! You also get a ton of usable data points that can polish and transform your “final product” into something the market is looking for, along with at least a baseline metric for inherent virality and customer acquisition cost.

Unfortunately for us, a “minimum” viable product was not very viable at all. There are a ton of features that go into even a basic email client. Then, to add the Timyo-specific “minimum” features on top of that would have made the MVP approach a long and risky venture.

So we decided to build a POC to make sure that our idea actually made sense to the general public, not just to us. We also needed to verify this was all technically possible with the rather long-in-the-tooth IMAP protocol. With the POC, we focused entirely on the minimum set of features that we needed to enable this new paradigm in dealing with daily email. We created a wildly new interface and from the moment you looked at the app, you could tell that this was not your everyday email app… which is not necessarily a good thing.

With the POC, we did validate the concept and received a lot of positive feedback on how this new system would work. People really got what we were trying to do and many commented on how great it would be if everyone used this system—and we agreed! Most of the negative (err…constructive) feedback we got was on the presentation and UX for this new system; it took a lot of hand-holding to point out the features and to teach people how to use the app.

We gathered a lot of great data from a very simple POC app and I highly recommend this methodology when dealing with something that has not been seen or done before. Sometimes you can just jump right into an MVP and go from there, but in our case, had we gone straight for an MVP, I do not think we would be where we are at today.

Once we had learned what we could from the POC, we set out to create an app which we could then take to market: one that users felt comfortable with to replace their existing email client, while introducing new, easy-to-use features that would greatly improve their daily email productivity. Easier said than done? You betcha!

Check out my next post to see how we went about creating our XVP. The “X” is for “Extra”!

Share this article
Email this to someoneShare on FacebookTweet about this on TwitterShare on LinkedInShare on Google+Share on StumbleUponBuffer this page