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

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. 😱

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:

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.

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.

…

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?

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. 

Each category is pretty self-explanatory. You simply need to assess each feature and ask yourself:

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.

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!

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