Minimal Viable Product (MVP) is such a nice idea. Let’s build something that is as small as possible and at the same time viable, which translates to “provides value and thus make sense to build it.” Two adjectives in a mix where one counterbalances the other and vice versa.
Since I currently run a web software house I hear the term MVP very frequently. Or to be precise I hear the term MVP being abused very frequently. On some occasion the viable part would be ignored. Much more frequently though the way people understand MVP has virtually nothing to do with the minimal part.
During the early discussions about products our potential clients want to build I would typically ask about a business case behind a project or an app. It’s not about what it is that someone wants to build. It’s about why it is worth building that thing in the first place.
Note, I’m not judgmental. We contributed to better or worse ideas but I don’t reserve the right to know what’s worth building and what’s not. In fact, my questions have a very different purpose. What I want to achieve is to learn the value behind the app so that we can have a meaningful discussion about stuff in a backlog.
Now, this is the part where typically I’d really like to have people read Lean Startup before they are even allowed to talk to any software shop about building their product. And then, read it once again to understand what they are reading in depth.
The reason is that most of the time I can instantly come up with a batch of work that is one third, one fifth or one tenth of what was labelled an Minimal Viable Product by a potential client and it would still validate a business hypothesis behind a product. It likely means that with a bit of effort and better understanding of the context our clients would be able to cut it down way further than that. It may mean that they’d be even able to validate the basic idea without writing any software at all.
These so called “MVPs” wouldn’t recognize a real Minimal Viable Product even if it kicked them in the butt.
A sad part is that most of the time discussion around what really is minimal is futile. While I can provide my insight and encourage to learn more about the topic an argument often boils down to “we really need to build it all because, well, we don’t believe anything short of that would work.”
The long story short, I believe that MVP is in the top 5 most abused terms in our industry. By now referring to MVP is mostly meaningless unless you ask a series of questions to understand what one means by that. We could have skipped he MVP part, have the same discussion and we’d save a little bit of time.
That’s why I believe we need another frame for discussing what the initial increment of a product is.
What I caught myself on a number of times was proposing our clients a different constraint. Let’s step aside from discussing what is minimal and what is viable. Let’s figure out which features will be the part of the product in every single, even most crazy, scenario that we can think of. And I really mean every single one of them.
What I try to achieve with this discussion is to find the set of features that is a common denominator for all the options of building the product. There’s always something like that. A core process that the app support. A basic idea that the app is built upon. An ultimate issue that the app attempts to solve.
What I don’t expect is to see the full solution, even the most basic one. It would be an MVP on its own and we’d be back to the square one. What I expect is just a bunch of bits and pieces that are required to eventually build the app.
It is neither minimal nor viable.
It is indispensable though.
There are a couple of reasons to do that. The first one is that it reframes how both parties, the client and us, think of a product. We don’t try to settle on what is viable and what is minimal. We simply go with something that we know will be useful.
The other one is that it addresses the huge challenge of building a relationship. In fact this part goes really deep. It typically starts with a question how much building something would take. Some sort of an estimate. Well, it’s another thread. I’m not fundamentally against the estimates and see value in understanding generally how much something would take. At the same time I acknowledge that humans are simply not well equipped to estimate as we can’t learn to assess stuff in abstract measures. At the end of the day though, the smaller the batch size of work the smaller the potential risk and the smaller the estimation mistake.
In other words the smaller the initial batch of work the easier it is to start working.
It is true from another perspective as well. The most important modifiers of the cost of building a product in a client-vendor scenario isn’t anything related to the product itself. It is the quality of collaboration. It’s about both parties feeling like they’re the part of the same team. It’s about short feedback loops. It’s about working together toward the goal.
Unless it is about lack of transparency, distrust, and exploiting the other party.
The tricky part here is that you don’t know where at this spectrum you are until you start working. Building the smallest possible batch of work together pretty much gives you all the knowledge you needed. Seriously, you don’t need more than just few weeks to get a good feeling where collaboration part is going.
That’s why this the idea of Minimal Indispensable Feature Set is so useful whenever more than a single party is involved in building a product.
Minimal Indispensable Feature Set is perfectly aligned with building an MVP. In fact it is a subset of an MVP. At the same time it addresses the part of the setup that goes way beyond simply defining of what product is.
We live in a world where more and more frequently the building part is outsourced to another party. Getting the collaboration right at least as critical as getting the product idea right.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
10 comments… add one
The MIFS seems like a clever and promising trick!
Question: has any of the customers that you’ve build MIFS with actually released it to verify their business idea? How did that end up?
@Igor – Minimal Indispensable Feature Set assumes that it’s not really feasible to deploy it.
It validates the quality of collaboration and from that perspective it worked on a number of occasions even before I started framing it so aggressively. The original message was something like “let’s work together for just a few weeks and you won’t need to worry about the collaboration at all as you’ll have seen how it works.”
The framing provides a business justification for such a decision. It also builds some positive pressure on our and as we explicitly introduce a scenario with multiple commitment points.
Clear, thank you for the explanation!
Hey Pawel,
Love this idea! It’s interesting as at first I thought you were taking this another way. I thought you wanted to use MIFS instead of MVP as it is a term that can be immediately understood for those not familiar with Lean Start Up.
To be clear though you’re saying use this new term/phrase almost as a proof of concept – the proof being to show clients who are sceptical about the collaboration element just how effective it can be if they embrace it?
Assuming that is correct, a couple of points spring to mind:
1) Costs – As this is a bit of trial does the client pay full costs for this short period?
2) Failure can good here – I know as a supplier you’ll always want the client to jump on board and have a really successful relationship (which majority of times I know is the case) but surely for both parties if you discover this relationship isn’t going to be successful then ‘fail fast’ applies right? Better to have found out in such a short space of time in the interests of both parties?
Chris
@Chris – I guess you may frame it as a proof of concept for collaboration between parties (not for a product itself though). My preferred way of framing that is that it’s just a fairly frictionless way to build trust.
My assumption is that we don’t have to prove each other that we want to collaborate well, yet normally we need some time before we start trusting each other. Personally, I assume that everyone is trustworthy unless proven otherwise thus all one needs to do is not screw it up.
Cost issue is orthogonal to Minimal Indispensable Feature Set definition. I can think of any scenario between doing it for free to charging normal rates for that. The context of cost is most relevant in a sense that we create multiple commitment points thus it’s easy and safe to walk away even when we are early into a project. Even better, even if you do it a client still leaves with some valuable work.
Failure is of course an option here and you’re right — fail fast applies here. Over the course of the first couple weeks we learn a ton about a new client and so do they about us. What I found true in almost all dysfunctional relationships we went through is that we could basically tell why the relationship would fail eventually during these first weeks.
Of course then there’s a question whether you act on such knowledge, but that’s a another story.
Cool Pawel, that all makes sense!
I think clients will find it really refreshing that a supplier has the confidence in how they are working to say let’s try this for a couple of weeks as opposed to just trying to tie them down to longer term Costs. That in itself to me speaks volumes for the Agility of Lunar Logic (I assume).
@Chris – Yes, the origins of the idea is what we do at Lunar Logic.
On a side note: from my experience agility doesn’t sell software development services especially well. More often than not I find myself explaining the basic ideas to potential clients. I guess that’s not a perfect marketing strategy, yet of course still worth doing.
Great post Pawel – I love the way you use MIFS as a collaboration-building tool!
A couple other tools for driving towards a genuine MVP.
Story Mapping. Once you’ve built the Walking Skeleton there should be exactly one way of doing everything in the product (or site). Therefore a very strong candidate for MVP. People could be buying stuff so does the client really want to delay release while you build a second payment mechanic?
MoSCoW prioritisation. If you keep Musts to It-Literally-Won’t-Work-Without-It (everything else is Should or Could) then the completed set of Musts is also a strong MVP candidate. The product should be working at that point, if a little barebones.
Guy
@Guy – I rarely find MoSCoW solving the problem of wanting too much. What typically happens is that assessments of where features should go get inflated. Sometimes even nice-to-haves are interpreted as must-haves and then there rationalization to explain why they are so badly needed.
I guess it is mentally difficult to let go and often the answer to “you can’t afford all these features” is something like “so let’s find a cheaper service provider,” which most of the time is only making one’s situation even worse.
I personally prefer Story Mapping although, again, it works miracles only as long as someone is ready to discuss cutting the scope down. Ultimately with this situation I’m not at the point of a discussion where we decide which features stay and which go. I am at the point where we don’t even realize that it’s enough to build a fraction of the original scope and still (in)validate a business hypothesis.
And again, someone who is attached to their idea can rationalize almost any feature.
My big problem is not deciding which features to build first. Of course on one hand MIFS or MVP is a frame to make such a decision. However, the important part here is that I want to commit to the work that won’t be wasted, yet the key goal is something else. In the case of MIFS it’s figuring out collaboration and building trust.
This by the way results in a whole different discussion about further features as suddenly we are proven partner and not just a potential vendor that wants to get someone’s project and money.
@Pawel, good points all, and thanks for your detailed response! What I really welcome is new approaches to broaden the toolset :)