What makes a "feature" a "feature"? Due to the nature of software, it's nearly impossible to adjust your "scope zoom" to be set on "feature." Example: If my

What makes a "feature" a "feature"? Due to the nature of software, it's nearly impossible to adjust your "scope zoom" to be set on "feature." Example: If my one feature were: "allow users to send e-mail," or let's make it easier... "allow users to write a comment." I'm already at a loss as to what exactly that means. It may or may not be a feature (and may or may not be work to implement) any detail of that, such as allowing comments to be multiple lines, allowing other characters besides a-zA-Z0-9, formatting, storing the date the comment was written, etc. Give me any 1 feature, and I can zoom into it and force you to accept other features that need to go along with it, otherwise rendering it near useless. Likewise, you can zoom out from any aspect of software and see that the "feature" really only works because it's part of a greater whole. That's where my confusion over "launching 1 feature" arises. There's really no such thing as a "feature" per se, but a some Platonic-esque form of your software that you strive to achieve. I think it's precisely this kind of mysterious trickery behind software that makes it so hard to make specifications, test, debug, etc... and why something like 80% of all software projects go either over budget or miss their deadline. This intangibility of software is also why I take advice about it with a grain of salt. It's easy, after the fact, to look at what you've made and point out the "one thing" that made it work. I like unalone's concept of the "core goal" behind your project. PG and others talks about this as well. Focus on the one core thing your software does, and do that the best. This has problems also... because there's nobody to tell you that your "zoom level" of the goal is just right. What if my software's goal is to "make users happy?" I could encompass nearly anything with that. Conversely, I could set my goal to be: "to allow users to post a 140 character message", which is way too specific in and of itself to create a useful product. I guess my point is that software, and nearly all other feats of engineering, are extremely organic. I'm skeptic about advice on the topic by "proven successes" for two reasons: hindsight is always 20/20, and selection bias. I think what it really comes down to is using your best judgment. AndrewWarner, I'd love for you to investigate: "What do you start with?" I think it's one of the biggest blockers for would-be entrepreneurs, and puts off so many people from even starting.