Your MVP & the Founder’s Flaw
Photo by Casey Horner on Unsplash
Let me tell you a story about a hiking trip that could have gone wrong, but didn’t.
I’d heard about a cool, moderately difficult hiking trail a few hours away, so I set off alone after work and arrived later in the day than I meant to. The sun sagged in the sky, like the day had gotten a flat tire.
Foolishly, I resolved to press on and reach my campsite before dark. But not a third of the way in, darkness swallowed the trees and the trail. Using my flashlight, I trudged from one reflective trail marker to the next for what felt like forever. I doubted every step. Every rustle of leaves and every snapped twig felt like danger.
Sometime after midnight, I reached my campsite, and the next morning, I woke up to a different world. Families were out. Children and dogs raced up and down the trails that had felt so treacherous mere hours before. I made the hike back in half the time.
Even if you’ve done it a dozen times, setting out to build an app is like heading into a dark forest. At some point, you’re so far in the thick of it that you can’t see clearly. Every little detail about your app feels critical and all-important — threatening, even. You can become blinded by your own perfectionism to the point where you lose your sense of priority and proportion.
I’m no stranger to this sensation myself.
As we built the Who Farted?! App, I found myself sweating so many things. Like right before launch I though we absolutely needed to change the app’s navigation. Thankfully, my team told me to chill out, and after launch, everyone complimented how simple and organized the nav was.
It struck me how blind I was to the fact that it wasn’t even broken. And I’m not the only one. I know someone who’s built their product twice. I still don’t think they’ve actually launched it.
I call this the Founder’s Flaw, and every serious creative person I know — musicians, writers, filmmakers — faces some form of it in their work.
As you enter the forest of your app development project, accept this will happen to you, too. To assess whether the thing you’re fretting over is actually important, ask yourself these three questions.
Think of them as reflective trail markers that lead you to launch, even if you can’t see so clearly.
How many users will the issue impact, and will they even feel that impact?
We recently inherited a client whose previous development partner did bad work, and we’re hustling to get their product live. They don’t have a single user yet, but they are fixated on a minuscule issue: a third-party video player that — on Android only — pauses the video when the user rotates their phone from portrait to landscape.
The video is maybe 1% of the content they have, and Android users will only make up around 5% of their user base. Plus, the “issue” is barely noticeable, certainly not enough to cause a user to abandon their journey.
There will always be tiny, nagging issues like this. One of the biggest challenges in app development is making the app usable across an insanely wide array of devices, operating systems, and OS versions.
If the issue won’t affect the vast majority of your user base, put it on your post-launch to-do list. Why withhold your product from the majority of users for the sake of just a few?
2. If you show the project to someone without pointing out the flaw, do they notice?
As you bring your app to life, you’ll spend so much time looking at it that your eyes will cross and you will feel a car-sicky sensation in your stomach. Many of the details that stick out like a sore thumb to you are imperceptible to the average user.
For example, I’m building two things right now: That Thing I Told You About (TYA), and WLCM’s new website.
TYA is a mobile app, and I’ve been around this block over a hundred times. As the creator, I know that, even when it doesn’t feel like it (it never does), I’m stuck in a certain level of myopia about how I view the product. For example, we built the “add an item to a list” UX. This is a core function. It needs to be easy and obvious and as close to perfect as possible. Enter my obsession.
I saw this finished function in the app, and I found what felt like critical problems with the flow (we should reorder the fields, we should add a field, we need an expensive integrated Google image search function for sure…). Because I know better at this point, instead of moving on these items, I showed the function to an external tester, and trust me: this took discipline. I wanted to apologize before she even looked at it, point out all those things I know are imperfect about it. But I didn’t. She went through that workflow multiple times as she created her list. What did she have to say about it? Not much at all. It was easy. She barely noticed the UX, in fact. Creating workflows that people don’t notice is a hallmark of UX success. This function is FINE. I can move on. I didn’t think I could, but… I can. 🙌🏻
On the other hand, we have WLCM’s new website. I’m using an external team for this – WLCM doesn’t design or build marketing websites; that’s a whole other ballgame. This external team encourages its clients to launch right away, and I wanted to do that, too, because I’ve been obsessing over the layout of the homepage alone for over a year and it’s time to just get it done. So you know what I did? I obsessed over the layout of the GD homepage for even longer. But I’m proud of myself: I launched it! I launched it even with what I consider outstanding UI issues. Pat on the back, right?
But here’s the thing. For some reason, companies that build marketing sites generally don’t have quality assurance (QA) teams testing their work. And while I obsess over UI, there are things I know I’m not paying attention to that should be paid attention to, like checking every last little link and sign–up form. So I asked Katya, one of WLCM’s QAs, to test the site, and guess what she found? Actual critical issues. 🔥
So when in doubt, test it out. Hand it over to someone new and see what they notice. Sometimes what you think is broken really isn’t. And sometimes what you think is great… really isn’t. When you’re THIS close to a project, it’s hard to see it clearly.
3. At the end of the day, does the app do what it’s supposed to do?
By nature, your app should help users do a specific thing. Ultimately, everything else is just polish.
Therein lies your minimum viable product (or Minimum Lovable Project, but let’s hold that discussion for another day) — the app’s first launchable version. You will learn so much by getting this version out into the world, so get it out there, even if just to a team of pre-launch testers.
Whatever the user is trying to get done, does the thing you’re obsessed with prevent them from doing that? If not, worry about it later.
Defining your MVP
“What does my app help the user accomplish?” should be the second question you ask on your app journey. The first should be “Do people want this” or perhaps “Is this actually solving a problem?”
From this raison d'etre, you can plot the functionalities needed to enable that basic goal. These functionalities serve as your MVP checklist, which should be fairly small. Once you’ve checked those items off, your app is probably ready for launch.
Sticking to this checklist can keep you from going insane, and it can lay the groundwork for user tests. User testing is the phase of development in which we gather a small group of real potential users and have them perform tasks on the app. As they do so, we watch their behavior and collect feedback.
It’s dangerous to go alone
If you’re working alone, there’s no respite from the Founder’s Flaw. Working with a team that’s launched a ton of products, and who you trust to steer you, is like having a guide in a helicopter above the woods you’re wandering through. There are many things a founder needs to succeed, and one of them is surely this: someone on your side who you can trust to give you reality checks on questions of priorities and launch readiness.
Not only will they help keep you on track, they’ll help you abolish the founder’s biggest fear: the fear of getting it wrong.