Project Development

You Have an MVP. Now What?

About a week ago, I reached a breakthrough in Leder. I finally finished the basic functionality in my app. The user can create a project, import notes from their Evernote account, highlight and extract quotes from those various notes, rearrange those quotes into an outline, and export that outline as an Evernote note. 

I was thrilled! Leder was working! First-class honors was in my future. (See Irish grading system.) 

About two minutes later, reality sunk in. There was—and is—much left to do on my project in addition to the basics. Some of the outstanding issues are crucial to Leder’s functionality (for instance, what if the user imports the same note twice?), some crucial to its user experience (what if the user wants to clear the highlighting from a given section?), and of course, many issues fall under nice-to-haves (search, filler notes, etc). 

After investing five hours trying to get a relative date library to play nicely in my app, I knew I had to tackle problems in a more methodological way.

I had an MVP—what do I do next? 

The Merits of an MLP

An MLP, or minimum lovable product, is a hot term right now in product design. Laurence McCahill defines an MLP this way: “The version of a new product that brings back the maximum amount of love from your early tribe members with the least effort.”

McCahill goes on to say that sticking to an MVP—which, though functional, is scaled-down and delivers a second-rate experience—misses a valuable opportunity to hook potential customers. He argues that additional investment in the user experience and design should be considered as crucial as issues of functionality. He offers some suggestions on how to do this, such as prioritizing features, adding instances of surprises and delight, and marketing like crazy. 

In my case, taking this approach means that I would invest in my app’s main utility, the highlighting functionality. I would divert some attention to marketing and branding, and table other features for another time.

The Merits of the 80/20 Rule

A perhaps supporting view is the 80/20 rule, or the Pareto Principle. This principle states 80% of the outputs in a system are generated by 20% of its inputs. In product management, that means that 20% of the effort generates 80% of the result—which means in order to get that last bit of results, you have to work really, really hard to achieve it.

I interpreted this to mean that I should consider difficulty when deciding which issues to focus on. Issues that are easy to implement, yet crucial to the experience, should consume the vast majority of my time.

Where Does That Leave Me?

I took a step back and documented everything I thought still needed to be done. I went through my app view by view, looking for bugs and areas of improvement. I also parsed my summer project plan and Trello board for things I may have missed. In the end, I came up with a list of about 30 features and changes.

I then rated each issue by how crucial it was to the app’s functionality (as an MVP) and user experience (as an MLP). I later added in a third metric noting how difficult the feature would be for me to implement (following the 80/20 rule).

Under that metric, relative dates, for instance, are not crucial to Leder’s functionality, somewhat crucial to its user experience, and somewhat difficult to implement. When compared against features that ranked more critical, it became clear to me where I ought to focus my attention.

My system isn’t perfect, but it gave me a solid indication where I should go next.

How do you prioritize product features? What’s your system? Leave your thoughts in the comments below.