How to Build a Minimum Lovable Product
userpilot.com
userpilot.com
Does that describe what you're doing? No? Buy some creepy instagram ads with more VC funding. Maybe that's what you need to inject more hacking the growth. To spread the love. Made lovingly in a cubicle farm by 100% real humans, not leetcode bots.
Years ago I once played a gig with my band in a place that was a coffee shop during the day, a restaurant in the early evening and a live music venue late evenings.
It was a delightful feature, not a silly bug, in a very small rural town in the Canadian Prairies (kind of our version of the US mid west).
Context matters. Especially in an article about “lovable”.
Somehow the entire article struck me as quite flimsy, just a small step above content mill material.
For myself, I have always loathed the MVP concept, and that has not made me fans; especially amongst this crowd. I've learned to just bite my tongue, and do things the way I do.
I'm in the later stages of a fairly ambitious native Swift UIKit iOS app (around 40 screens). It has been in progress for about 18 months (over two years, if you consider the backend, which I also wrote).
During that time, I have been sharing the built app with the team, using Apple's TestFlight beta-test system. I made my first TestFlight release on October 4, 2020. Since then, I've made around 600 releases. It's abusing the TestFlight process, which is really supposed to be an "end-stage" service, but it's worked well for us, and the Quality of the app is through the roof.
We have also made several massive pivots, and have settled on a UX that we think users will love, and will address the needs of the community that it Serves (It's a free app, for a non-profit).
I couldn't even imagine this being out there, during the last year or so (when we first thought we had a "viable" product). It would have completely destroyed any credibility we had (and we actually have quite a bit).
How do you know that it does address their needs and how do you know that they care?
> It's a free app, for a non-profit).
And what makes doing it worth two years of your life?
> How do you know that it does address their needs and how do you know that they care?
Let’s just say that I know the target demographic fairly well, having been a member of it for over 40 years, and having written a major, worldwide, infrastructure for it (over a period of ten years -also, on a volunteer basis).
I eat my own dog food. I use the software I’ve written, pretty much daily, along with thousands of others, worldwide. In fact, this app uses that infrastructure, and integrates it with a simple social graph, so you could say the app is actually the result of over a dozen years of work.
Also, the development process I use is highly testable. TestFlight[0] is, for all intents and purposes, a “mini App Store.” The app is a full-fat release, and is constantly being vetted by Apple. It’s not some crappy lash-up, like so many MVPs. It’s quite amazing, that it has been used constantly, since one month after I started coding.
I can write a lot of really good code, really quickly. What I released to TestFlight, in October 2020, could have easily been considered “The heck with it, let’s ship” by many corporations. Even six months later, when we originally thought we had our first “shippable” app, it was still pretty pathetic. What we have now, is something we are all quite happy with. We still have some months of testing and preparation to go, before we have our first public beta.
Brand damage is something that many geeks don’t understand, but is absolutely devastating, and almost impossible to repair. Even if there are some initial stumbles and hiccups (almost guaranteed), it won’t be an E.L.E. for the project or the team, and it won’t destroy our credibility. Even if it’s a complete flop (which it won’t be -I guarantee), people will still take our team seriously, so we will still be able to keep trying. I fully expect it to take several months (or longer) to mature, after we release it, but it is designed to be “infrastructure-level,” daily use, software. Good things take time. We have no problem with a “slow burn.”
Also, the software that I write Serves a fairly sensitive demographic. Security, Privacy, and Accessibility are of paramount importance. Failure in these areas could have severe and detrimental impact on people’s lives. It’s not hyperbole, at all, to say people’s lives depend on the Quality of my work. I can’t afford to “move fast and break things,” as said “things” could be people’s lives.
There’s a reason that I’ve repeated “people’s lives,” so often, above. I think it needs to be driven home.
> And what makes doing it worth two years of your life?
Two years is nothing (see 40 years, and 10 years, above). I’ve written software, professionally, and personally, that has lasted decades. I’m fairly adept at playing the long game (not particularly valued, in today’s tech industry).
Also, the software that I have written personally, has the potential to make a major impact on people’s lives. It’s pretty important stuff; not some “leisure/entertainment” app for bored yuppies. I take my job pretty seriously.
Some things are worth that kind of effort. If I had to explain, you wouldn’t understand.
MVP is “the first thing that stick”. The method to get there should be meticulously engineered to cut as much iteration time between prototypes as possible. When your ugly prototype shows strong traction by its own and test users are asking you to keep the prototype then you know you have a rough diamond to cut.
Obviously when you have a sizeable user base, know the market very well and your market isn’t that much competitive you are at an advantage.
Beware of market expertise ego and dogfooding as it only reinforce your expertise and biases. Bring industry newcomers to your project for feedback, it’s the only way to make sure your expertise doesn’t make your product only valuable for yourself.
Good point, but this particular demographic has no problem letting me know where the rough bits are.
The thing about the MVP pattern, is that software people seem to think that we get to go by different rules, from everyone else.
Software lets us iterate quickly, and I have found ways to leverage that (I call it "Evolutionary Design"[0]), but that does not give me license to deliberately foist garbage onto end users; especially ones that are quick to anger, and slow to forgive.
Every other craft, engineering discipline, and production system, throughout history, has had to take the risk of going through a design phase, based on expertise, user surveys, need evaluations, etc., then actually get to at least production prototype phase, before determining whether or not to proceed further.
It's a risk, but one that everyone has been taking, for hundreds of years.
For some reason, we software people seem to think that the flexibility of software absolves us of the Responsibility to deliver a high-quality prototype, and that we don't need to take the same risks that everyone else has been taking throughout history.
I totally agree that said flexibility gives us a great opportunity to actually deliver a much more suitable product, than was achievable, with other production methodologies, and ease of iteration is how we get there.
I just don't agree that we start by throwing out some junk, without first doing some real homework.
I'm really tired of seeing junk prototypes becoming the shipped product. Once it is out there, and running in production, it's quite difficult to make the kinds of pivots and changes that are almost certainly required, without turning the app into a disgusting mess. One of the nice things about the last couple of years, is that I have been able to completely nuke the database, several times, as we have pivoted. I'd never be able to do that, if it were a production app. I'd have to devise some kind of horrible kludge, or, more likely, limit the pivot.
[0] https://littlegreenviper.com/miscellany/evolutionary-design-...
Huh? How does Apple know what your users want?
Apple vets TestFlight, the same way they vet release apps; except not as stridently. They look for things like obvious crash bugs (indeed, they have sometimes found bugs I missed in my testing), security issues, private API access, obvious HIG deviations, etc.
They do an intensive, human, test, every time I bump the fix version, and fast, automated tests, when I do release bumps. The intensive tests usually take a couple of days, but the release tests take about 15 minutes. I generally do version bumps, once a month or so, but several release bumps, every day.
TestFlight is simply another Quality tool. Apple’s testing is yet another set of eyeballs on the product, which is always welcome, and, more importantly, it allows me to put working, near-release-quality product into the hands of people that represent the target demographics, very early in the project. The product has gone through tens of thousands of testing sessions, by a number of folks, that represent the target users, but aren’t actually unrestricted end users. These are not “kludgy, crashy, hold-your-nose” testing sessions. These are “running release-quality code” testing sessions. I often find obscure, weird, bugs, minutes after creating them, and that is awesome.
It’s impossible to overstate its importance to developing a high-quality, relevant, and robust end product.
I have made over 600 TestFlight releases, during a development cycle of 18 months. I often make several releases, every day. That’s quite a statement. I have not encountered another team that has done anything close to this.
It means that the product has been beta-quality, since one month after code start (it’s actually a technique that’s very old. I call it “constant beta”), and has been under daily end-user evaluation, the entire time, without risk of brand damage, and with the ability to do massive pivots (which have occurred multiple times). These pivots are possible, because we don’t have a large end-user base that we need to keep happy. I have just nuked the entire database, several times.
Try that, with an established customer base.
Taking 18 months to release it might cause you to waste a lot of valuable time with features/requirements that does not deliver any real value to your customer, and the competitors can gain this space delivering a much less complete product, with less quality, but with the right features because of MVP concepts.
Not teasing in any way, but just 2 cents to consider, as I see a LOT of issues with the MVP approach.
I understand the concept (It’s the standard MVP talking point), but read my response, above[0]. I am big on Quality. I also don’t think that we (software developers) get some kind of “get out of jail free” card, exempting us from the same rules that every other discipline has had to follow, since the dawn of time.
It’s entirely possible to do it without delivering shoddy product. People have been doing exactly that, for centuries. There’s a long, long history of “guessing well.” Steve Jobs did that (He also “guessed badly,” frequently, but his good ideas worked out well). History is full of products and initiatives that worked well (and that didn’t). I don’t believe that it’s possible to democratize creativity. Some of us are more creative than others. I think that I'm “in the middle,” myself. I don’t really come up with “groundbreaking” ideas, like Steve Jobs. I tend to devise better ways to address classic problems, and actually have a fairly good track record, there.
In any case, I just wrote about my approach, to software that I write. I wasn’t insisting that anyone else do it my way. If people don’t like it, they can vote with their feet. Folks have also been doing that, throughout human history.
In my case, I am literally incapable of releasing a product that I don’t consider to be of the best Quality possible. I guess you could call it a “disability,” on my part (but I don’t).
I’ve never been particularly interested in making a ton of money (most of my work is free, for nonprofits), or “going viral.” I have a craftsman approach to my work. I’m not competing with anyone else. In the past, I have actually withdrawn my own products, when others have developed ones that I considered better suited for our users. The stakes are too high for infighting.
So an MVP can be crappy, as long as it helps to answer the question it is supposed to answer. The lovable part should come, once you understand your environment and can build something that people actually need.
In the same vein "Minimal Lovable Product", shouldn't mean a product which someone could only barely love :]
If MVP does not solve a real problem, it does not validate the correct hypothesis, so what the post describes as an MVP that is not MLP is not an MVP.
And an MLP executed to be not MVP would be a thing built to be built, or taking unnecessarily risky bets spending unnecessary cost.
Cut the crap with fighting words with words. If the community used the word MVP to help introduce a more useful concept, real builders focus on executing it correctly, to the best of our ability, giving the inventors fair credit and most charitable interpretation. Alas, we have content marketers among us, and those who failed and wish to blame it on being given wrong instructions to follow, inventing empty words like MLP.
and listening to the entire internet say "if you don't like one tiny aspect of your work environment, its a huge red flag for a bunch of other stuff so just leave!" as if such choice in the matter is really there and that the next organization doesn't have some other tiny cringy thing
so then if you ignore that advice, you're stuck with the childish babble that the people in your organization use to cope
A teammate once told me he is frustrated with being asked to work on an MVP, that is minimum cost, minimum polish, minimally functioning. He said he wanted to work on MLP, so I said he can call it MLP if he wants, but what we must build does not change: prove the concept minimally such that we can verify whether the problem we seek to solve is a real problem in the first place, then we can add as much polish as needed once we know it's a good problem to solve. If we think customers are experiencing some problem that, in order to solve minimally, we need to give them polish, then the polish is a part of the MVP/MLP. Otherwise, it is not. It doesn't matter what we call it. What matters is what we must do.
He thought that my attitude taking the distinction between MLP and MVP lightly was a sign that I do not care about the best interest of our customers, and left the company.
You have to think about the long-term “thriveability” of the MLP and how it fits into the business model, so it’s not a free lunch, but I’ve found it to be an effective way to avoid the usual pitfalls of boiling the ocean, early abstraction, unmaintainable scope creep, and so on.
For example:
1. Has the Userpilot team failed at building and MVP and succeeded with an MLP? If so what did they learn and why?
2. Lots of people have succeeded with an MVP approach. They describe a handful of things you can do wrong when building an MVP... but what if you DON'T do those things that they claim lead to MVP failure?
3. Digging into one of the recommendations - don't sacrifice delighters. They talk about how they wouldn't include the Asana unicorn in their MLP and end with "balance delighters with effort". Fine. But HOW do you do that? What framework can you provide ME to do that?
This smacks of a writer doing a Google Research Project to offer up hand-wavy advice. 0/10 would not recommend.
https://review.firstround.com/dont-serve-burnt-pizza-and-oth...
Is this not already the definition of an MVP? As they put it - a skeleton that doesn't solve anything - isn't really a viable product...
If the problem is hair on fire bad, UX doesn't matter.
Just replying to make sure you know how profoundly true this is. And if you want the secret to mega success: solve a hair on fire problem with great ux and you will win almost automatically.
Or
2. You can tell when you talk to people who have the problem. They get really excited about having it solving for them and don't care about the price it costs to solve it.
Otherwise, consider these factors:
1. How many people are affected?
2. How much does the problem cost (in time or money)?
3. How much extra money can be made by solving the problem?
4. How much time can be saved?
5. What is currently blocking the way to dramatic improvements (in anything)?
6. What is causing people real pain, fear, suffering, or dramatic inconvenience in a large enough market?
That’s a good start, anyway. Good luck with the journey.
Developers see interfaces and user flows as a place to expose controls so users can operate the software. To users, the interface is the software and bad interface = bad software.
So it's super context dependent.
Not sure if copywriting (with or without space) is a thing but copywriter and copyediting is: https://www.merriam-webster.com/dictionary/copywriting
Writing copy, no idea what that's supposed to be: https://www.merriam-webster.com/dictionary/writing%20copy
Anyone here in the know of this jargon? And how is it related to "MLP"s (to stay in the custom jargosphere)?
"Writing copy" just means writing text for publication. "Copywriting" means the same, though I don't think most copyeditors would let the word "copywriting" go to print.
I think the terms is are used relatively clearly in the context of the article, so long as you know that "copy" means text to be published.
If people don't apply a concept well, does that mean we need a new lovely concept? What prevents it from being misunderstood as well?
Minimum monetizable product?
1. Yourself - was it just a stupid thought in your head or actually something useful?
2. Investors - see this isn’t just a pipe dream but an actual working product. Now give me money.
3. Maybe a very small set of actual users to act as a focus group and tell you how stupid you are.
Once an idea has passed validation by 1, 2 and 3, that’s when development can start. That’s when you build an MLP or alpha or beta or whatever else you want to call it.
If you think you are just going to slap a logo on a MVP and start charging $10/month for it, no shit people will laugh you off.
Just another attempt to kick start one more senseless hype cycle for no good reason
Doesn't sound any better, to be honest.
A Minimal Viable Product needs to actually be viable
https://uxdesign.cc/a-minimal-viable-product-needs-to-actual...
A prototype.
A concept value test.
A minimum viable product.
A thing a user will pay for.
Finding product-market fit.
Or simply put... customer development.
I do hate that the acronyms get overused by people who don't know what they are talking about. But I don't think we have to reinvent the wheel by changing a letter and giving it different meaning when it's the same thing.
The two great points hinted in the article are "outcomes over outputs" and "jobs to be done". Everything else is kinda meh.