Have you ever considered cutting the scope of your project? ⌚

I've really honed in on the agile development/fast iteration mindset. I just throw out a half baked product and then iterate over and over until it starts to take shape. This doesn't work for everyone but when you accept that you'll never be 100% perfect, it's more easier to just take the leap IMO.

I like to think of app building like building a house. You should not skimp on foundations, walls, or a roof, and anything that must be in place because adding it later will be very hard (plumbing or electrical). Everything else like trim, paint, or landscaping can wait. You can also build a small home rather than a mansion.

What you build should be complete in terms of providing a useful function to someone with the ability to expand later. Keep in mind, the market will favor finished homes over just four walls and a roof, but people being interested as you build your dream home is very motivating.

I'm doing it right now. The first version of my MVP was so bulky with many features. The users found it overwhelming. Now I'm working on the 2nd version of the MVP which will be focused on only one thing.
Though the 1st MVP was packed & it looks like time wasted, there was a ton I learned from, I'll be using it for later.
So I'll say I'll scale down/cut the scope of the MVP to accommodate user interest. Then I'll slowly increase the scope when the customers are ready.

Scope scaling is the phantom of indie game development. I spent the last 5 years working on my game. It included: 3 complete assets overhauls, switching from top down 2d to 3d fps, switching from a framework (libGDX) to writing my own engine on top, it is wild.

The I encountered the "Stop it. Get some help." meme. I stopped it. I got some help. I decided to scale back down to 2d. All my work is saved, all my 3d assets, the rendering engine, is all safe, I have nothing to worry about. I reflected back on the old, reasonable scope.

With that, my targets switched to. From "I will make a game that will grant me a place in history" to "I will create a game and a sustainable business around it, so I could do this full time. Then, I'll be in a much better position to try crazy, ambitious scopes."

I honestly believe it was the right decision. I feel like there's a finite sequence of steps that I can take and see results. I will be able to post gameplay and get feedback, build a community, be healthy and release after some time in early access and hopefully leave the 9-5 rat race behind.

One term I've heard thrown around a lot more in recent months is Minimum Loveable Product (MLP) instead of the more common MVP. I like the idea of MLP since it encompasses the same core idea of scope reduction as an MVP would. The idea being that you identify and build not just the minimum version of the product, but the minimum version of the product that drives real value for customers.

In some cases MVP = MLP, but other times they differ either by scope required (sometimes MLP requires slightly more scope) or by what initial functionality is chosen. The only real way to understand what an MLP should consist of is by fully understanding the problem you're solving and by talking to some potential customers so it also enforces best practices in that sense.

For more than a year I just added features like an idiot and now all I'm doing is cutting the features and making sure it's good enough to address the needs of small group of people initially.

For me, it's less about reducing and more about preventing additions.

For example, I have a client who is the kind of scope creep. I have to be very, very clear with him every time a new feature comes up.

Question #1: Why?
Question #2: Who wants this? And will it actually solve their problem?
Question #3: Will it improve our KPIs?
#4: No, but seriously, will it?

I'm of a similar mindset but there's always a line that can be drawn. My vision will always outgrow where my product is. It's about discovering where that line is and it's going to be different every time. I use questions like yours to help find that line.

I find it much easier to reduce the scope of a project by asking myself the question, what's the most important assumption I have to prove? Once I know which, I determine which aspects of the project are essential to that assumption and which are unessential.

I always do this. To get some ideas, read the book "Pretotyping". Here's a quick summary of the principles.

You don't have to cut the scope of the project.
Just cut the scope of the next release.
Save everything else for future releases.

Valid approach. It depends on the vertical and the use case though. For some products / services, the expectations at launch in terms of feature set are higher than for others.

All the time. I used to obsess over every detail and still do. The adjustment that allowed me to launch instead of staying stuck in a perfectionist loop was to constantly ask myself: does this help the customer make a purchase? A lot of the copy/features/visuals get discarded, no matter what my personal feelings about them.

Finally launched getbristlecone.com after 6 weeks in dev mode.

Long live mvps indeed :)

From what I have learned, it simply is: to always do the minimum necessary, but most critical, for that sprint / version launch.

Yes, 100%.

Sometimes while developing you start day-dreaming about all these awesome features that aren't really vital or important to the product you are building. You end up wasting a lot of precious time.

After a few products, I started realizing this and now what I do is refrain from implementing features that don't serve as much value as other ones. Ship less but just enough to keep users happy and save yourself a lot of wasted time.

I think the scope of the project is intrinsically related to the product's definition. Questions like, "What is the product?" "Who is it for?" And "Why should customers choose it?" are super important and can help to refine the scope of a project.

With Sonar: (sonar.winterdelta.com), we stripped down the scope and are now focused on long-form messaging. You can use the app to create text-to-speech messages and speech-to-text responses as voice or as text. It's as simple as we could make it.

I guess I can say that I learned my lesson the hard way. I initially built features that only fed my ego as a dev and we're not providing actual value for the users. I was too invested in them to ditch them once I realized they added no value. But, thankfully, I eventually realized that it was better to cut the scope of the project.

I've grown fond of the idea of having a fixed time to build and launch, with a variable scope. It really focusses you on what matters and stops the perfectionism that comes with indefinite timelines.

Sometimes cutting the scope will give you a new direction for the app. Finding a cheap way to launch, like utilising an integration you already have instead of building an all new UIUX, could be the key to finding a simple way to fulfill the needs of your users. Either way, you get the feedback you need. You get none of that if you don't launch.

I massively cut the scope of Parthenon (getparthenon.com) my SaaS bootstrap. While I still want it to do all the things I had originally planned. I realised I am not at that place and I need to spend more time marketing and other things. And I really want to polish what I do have.

You can check out my original roadmap at https://imgur.com/a/N8VNq80 and this was after I originally removed a bunch of stuff I had in the original scope, I had scalable logging infrastructure setup, tons of scalability stuff.

The scope of Parthenon is still extremely large, I think I have more functionality than nearly all other bootstraps. But it was hard to cut out all the stuff I want to do and really start polishing stuff and making everything that is there the best it can possibly be and grow out new stuff later as and when it becomes needed for my customers.

What? I am not going to scale back on those 100 new hot features no users asked for because I have no users...