View profile

 IndieDev Tips #6 - Guide to MVP • Part 4: Minimal Feature Set

 IndieDev Tips #6 - Guide to MVP • Part 4: Minimal Feature Set
By Edouard Barbier • Issue #6 • View online

Welcome to Part 4 of my guide to building Minimal Viable Products. If this is the first email you’re getting, feel free to catch up on Part 1, 2 and 3 here first.
In part 3, you’ve gone full on creative mode and listed all the cool features you could build for your app in a massive mind-map. Now, it’s time to not build most of them. How disappointing right? Keep reading, you’ll understand why.
In part 4, we’re learning how to say ‘No’ to ourselves. 😱
Saying 'No' to yourself
This is the hardest part. I struggle with it too. But it’s crucial to get it right for several reasons since it will define:
  • If you will end up shipping or instead give up and move on to the next thing
  • If you will utilise your energy & time the best way possible or if you will waste some of it along the way
  • If you are ready to treat your idea like a business that needs to be validated with real customer
I’ve always thought that like anything, this could be learned and mastered and I’d reach a place where telling myself to not do something becomes easy. But years later, I can say that it doesn’t get better. It’s always the same thing. I know I shouldn’t build that extra feature, but it’s a mental battle with my brain and my own enthusiasm… every time.
The good thing is that now… well you know it. Your brain is trying to make your work harder, longer etc… but if you’re ready for a little inner battle, you can be in control and your brain will just listen and comply.
What does it look like in reality?
I always find it better to deprioritize a secondary feature and instead allocate some extra time to the thinking process related to very important design, UX or data modelling decisions which will impact the project in the long term. 
You probably don’t need a fully fledge sync engine, automated data backups, a watch companion app or 10 widgets or [insert fun feature you don’t need on day one here]. That’s why it’s crucial to set your own boundaries. You will save tons of time, and you will reach a point where you are ready to ship much faster.
The first app that I got traction with shipped with 1 core feature and 2 secondary feature required to make the core feature functional. A login page, one tab and one settings tab with my photo and a contact form and it took three weeks (of evenings & weekends) to design, build and launch. There are tons of things I could have added to the v1 to make it more compelling but I didn’t.
Why is shipping fast so important?
Disclaimer: this paragraph contains sensitive language for indie developers.
If your product is bound to fail (it happens to all of us, and I said ‘if’), wouldn’t it be nice to know it very fast, without wasting time and resources? Our time is limited and if Idea #7 or #8 is the one that will work and put your on the map, you need to waste as little time as possible with your first 6 attempts right?
Well, shipping fast is the perfect way to put your products in the hands of your customers. Past this point, we can just hope they will show you the way with suggestions & feedbacks and you can start improving your product, release after release.
You’ll get the usual ‘complainers’ that do not understand what a v1 is and expect everything to work perfectly with all the features they can think of, on day one. Ignore those or filter their feedback and only keep what’s helpful to your roadmap but don’t let the negativity affect your motivation. Generally, seeing users talking to you is a great sign that you build something useful that can be improved.
But I’m drifting here. Let’s get back to where we were in Part 3: our mind-map full of exciting features. Where do we go from there? How do we build and ship this fast?
A radical approach to shipping faster.
*Brave Indie Dev grabs machete*
*Brave Indie Dev grabs machete*
We’re going to round corners a little bit in our. I usually do this in the mindmaps I worked on in Part 3… not with a machete sadly, but with a ‘boring’ red orange & green colour scheme. 
  • In green, all the things that will go in the v1.
  • In orange, all the things I’m not sure will go in the v1.
  • In red, all the things that definitely won’t go in the v1.
Each category is pretty self-explanatory. You simply need to assess each feature and ask yourself:
Will the app work if I don’t build this?
  • If the answer is no, absolutely not. Then it’s green and it’s getting into the MVP.
  • If the answer is a bit blurry, like… “well it would be nice to have this because…” then mark it as orange. Ideally, you want to skip over this one too. But if the MVP turns out to be too simple and built in 3 hours, you might want to spice it up a bit and add a few more ‘orange’ features before launch. Be stingy with the orange… it’s not a ‘kinda green’. It’s Orange! Orange is more red than green… got it?!
  • If the answer is a clear No, or if you don’t even know how you would go about building that feature. Mark it in red, and park it for later releases.
In a short timelapse format, it looks like this. Again, it’s not supposed to take a week. Sit down for 20-30 minutes, and just go through everything. If you’re being honest with yourself, one pass should be enough to chop off all the non-mandatory things that can wait.
Minimal Feature Set - Selecting MVP features
Minimal Feature Set - Selecting MVP features
That’s pretty much it for this stage. Once that’s done, I usually list down the MVP features in my Notion dashboard (any todos app/tool works for this) just to keep track of what I’ll be focusing on. And there you have it, your messy roadmap ready to be taken to the next level: UI & UX Design. How exciting!
Wrapping up
Stay tuned for the next issue which will cover my approach to UI & UX design. We’re almost breaking grounds for your new project. I’ve already started coding this new app I’m showcasing on here since I have to plan these newsletters ahead of time. Daily progress on Instagram: @edouard_iosdev. We’re approaching 10,000 lines of code as I’m writing this. A big chunk of it being reused from other projects (to save time of course), more on this later.
If you’ve learnt something with this issue, please consider sharing it with a friend or tweeting about it. Your support means a lot as always.
Cheers, Ed
Edouard Barbier  (@edouard_iosdev) | Twitter
Did you enjoy this issue?
Edouard Barbier

I’m Edouard, an Indie iOS Developer & Serial App Maker from Belgium. In 2015, I started to teach myself how to make iOS apps. In 2018, I left my job at Google to pursue the indie lifestyle.

This newsletter will include tips, mistakes I’ve made and tons of experiences I can share with others including a roadmap to escape the 9 to 5 and build products for a living.

In order to unsubscribe, click here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Powered by Revue
Barcelona, Spain.