I recently had the opportunity to talk to a great group of Product Creators about The MVP Checklist — the framework and best practices to build a Minimum Viable Product. You can catch the webinar here. My detailed take on this topic and how I am building product at Workomo below.
As someone who has spent her time journeying 0-to-1 a few times, I can happily vouch for the madness that ensues in this phase. Lack of data, constrained resources, and practically no users / customers force you to think long and hard about building a product up from scratch.
So how does one go about it? Converting an idea into a tangible product?
Enter The MVP checklist.
If there’s one thing that has kept me going @ Workomo and excitedly so, it is this framework, that I swear by, that helps me develop a method around the madness.
At Workomo, we have spent these last few months honing and owning this checklist for our product development, and building systems around it to stay true to the course.
Here is what I have learnt so far and how I go about implementing the MVP framework in our day-to-day product building.
What is an MVP?
Let’s first start with defining what an MVP is.
The traditional MVP, the Minimum Viable Product, is a product which has the minimum functionality which lets you test out the viability of a product or a business idea in the market, among its intended customers.
But my definition differs, and is more inclined towards what the folks at Salesforce spoke a few years ago — The Minimum Valuable Product.
As software products have evolved in the last few years, especially in their experience, viability in terms of plain technical capabilities is not sufficient anymore. Today you can differentiate between different products just on the basis of the core value that they provide.
At Workomo, value delivery is one of our core product principles.
What is the value our user is looking for?
And what value CAN we successfully deliver?
We do not shy away from trying over and over again to find that one value that we can provide to our user. When Soumitra Sharma started building the very first MVP of Workomo, it was a relationships management hub. Today, Workomo at its very heart is still a relationships product, and the tangible value that it delivers is not a management hub, rather people intelligence.
But how did we reach here?
That brings us to how we went about figuring this out.
How to build an MVP?
Your learnings feed back into the building. But how do you start building when nothing exists, there are no measured results, and therefore no learnings.
The most logical first step then — Figuring out WHAT you are building, from the Idea you have.
The what directly connects with your BML feedback loop, but there’s a gap between the idea and the what; and that gap is the WHY.
- WHY are you building this?
- WHY are you building this now?
- WHY should someone use your product?
Asking the tough WHYs is another core product principle at Workomo.
Time and again when I get user feedback, or I’m proactively doing user research, this why sits at the core of all I do.
- Why is a potential user saying A?
- Why is she not saying B?
- Why will she not use Workomo?
- Why is it even valuable for her?
So in this MVP framework, the order of priority of M, V & P, is thus not as straightforward as their appearance in the acronym.
And this brings us to the first point in the MVP Checklist.
#1 Find why before what, define value before product.
How to find Value?
The answer is simple.
TALK . TO. PEOPLE.
Whether I’m building a new product, or a new feature in an existing product, I first list down all my assumptions, and then, talk to users, current or potential.
While making something new, one is at their creative best in the beginning, lots of ideas, high optimism, a groundbreaking (produc) world view. Talking to potential users matches that world view with reality; and quite often, the reality is surprising.
While building Workomo, we went on an exhaustive, all consuming, user research cycle a few months ago. And it blew our minds (as it always does).
One of the core assumptions we made while talking to potential users, and still do, is that nobody cares for our product.
Shreyas recently put this hypothesis in tangible, beautiful words.
A sensible null hypothesis for consumer products is that the user doesn't care about your product, doesn't have time to use it, doesn't understand its purpose, will skip any onboarding tutorials, won't read UI copy, will forget about it after signing up or installing it…
— Shreyas Doshi (@shreyas) June 12, 2020
Reading between the lines in a user interview, especially at this early a stage, becomes a critical requirement, and this null hypothesis helped me clear my head, invert my assumptions, and ask the right questions.
In a nutshell, this is what we did.
How many people should I talk to?
This is an interesting question, and there is no right answer. Based on my experiences so far, for a brand new consumer product, it looks something like this.
In our first user research cycle at Workomo, we had lined up 30 detailed user interviews, 2 every day, over a period of 2 weeks. It was the 18th interview, and we were very excited about it. In our heads, this was a perfect user for Workomo. He fit in all our criteria of the persona we had drafted and we were sure that he would definitely find value in what we had to offer. 30 minutes into the interview in this person’s office asking him all sorts of questions about his professional networking habits, his work relationships, how we views his career etc., we begun to realise he was very far away from our ideal user’s persona. A light bulb flashed in our heads, and we began defining the anti-persona there and then. We then went back over all the previous interviews and began connecting the dots. A clear pattern started to emerge for who would benefit from using it, and why, and what exactly are these people looking for.
And this brings us to the second point in the MVP Checklist.
#2 Talk to real people, gather at least 10–12 patterns.
Who else provides that Value?
Once I figure out what value can I drive for my user, I need to understand who am I (my product) competing with. Right?
At this stage, my product doesn’t exist. Nobody knows about it. Nobody is my competition. So WHO am I really competing with?
I’d argue that my product is actually competing with a WHAT instead of a WHO.
And to nobody’s surprise, that what is the user’s habits.
- What is it that my potential customers are doing for which I have to build something better?
- Is she using another product? Or is it a hacky solution she has devised for herself?
- What is it that the user is doing today?
The subtext in studying user habits here , the emphasis on right now, is really important to capture. This ladder of evidence framework by Teressa Torres is one of my absolute favourite user research frameworks, and for the reasons she has well explained in this article.
When we spoke to users about professional relationships and what they wanted to do in this area of their professional lives, almost everyone said that they want to be able to capture and manage all information in one place, kind of like a personal CRM. When we dug deeper and asked them if they already maintained some sort of context, very few said yes. And that is how we moved from an exploratory relationships management hub use-case, to a defined workflow use-case.
And so we are at point #3 in this MVP Checklist.
#3 Study hacky and tacky user habits in action right now.
How to spec the Product?
First V, then P.
When I start listing down the feature specifications of what I’m building, I segregate everything into 2 buckets — Core and Housekeeping.
The core is what defines that one singular value that this product has to drive home. Anything and everything I need to build for that comes in here. My best practice is to visualise how would this product look like if it were live today and had thousands of users.
“I want to look up the most relevant people insights before meeting them.”
The housekeeping list consists of, well, housekeeping features. Basic sanity, bare minimum functional expectations that a modern user has from any product.
“I want to be able to create an account and navigate through the product easily.”
Once these buckets are ready, I list down everything.
For Workomo, our stack looked something like this.
So the fourth point the Checklist is then.
#4 List all features that you would visualise in a live product.
Wait, isn’t this counter-intuitive to the entire philosophy of building a minimal product?
How to make it Minimal?
Let’s take our full list of features, separate them into different layers as they would be experienced by the user, and stack on top of each other.
Years ago as a new product person, I used to optimise only for functionality and reliability. After all, MVP is supposed to be minimal.
I learnt it the hard way that slicing this pyramid horizontally sent me on a wild goose chase and almost always invalidated the learnings.
Minimum Valuable Product, remember?
The experience of the product is one of the most important values to provide, and so the top 2 layers are as critical as the bottom 2.
Putting this in practice, from the full list of features above, this is how we went about trimming Workomo to build a truly Minimum Valuable Product.
- Trimmed the extra fat from the full list
- Added more constraints to the remaining features
We’re checking if users would like people insights right before a meeting in a combination of productivity + intelligence use-case. Why do we need to add notes for this? Let’s validate whether this is even a usable, useful scenario for just 1 meeting, with only 3 insights.
This brings us to the final point of the MVP Checklist.
#5 Draw the product pyramid, Cut a delightful, usable slice across layers
Once I reach this stage, it means this system is already in place. All I need to do with each iteration is follow the same checklist till my product can deliver one core promise.
Lather. Rinse. Repeat.
- MVP is a system of iterations, not a product.
- There is no such thing as the Right MVP.
- MVP owns the problem; the solution is an outcome.
This framework is how we build everything at Workomo, from a new feature to a minor UI change, clinically yet instinctively.
We iterate, sometimes in the design process itself, at others, after shipping and measuring results. What we truly control is the process.
(Contd..) Now as a founder, my core operating philosophy reolves around 1) “lean” iterations, 2) systems-thinking & 3) agile dev (hypothesize-build-get users-learn-iterate-repeat). When facing high failure rates & random outcomes, only thing you can truly control is the process.
— Soumitra Sharma (@soumitra_sharma) August 8, 2020
With this philosophy intact, we continue to keep getting closer to that one core promise.
If building successful professional relationships is a priority for you, do sign up on our waitlist.