Maybe your friend is procrastinating. Does he even want to ship it? Maybe your friend likes developing and polishing.
Shipping a product is the moment of truth. Will people buy it? or even use it? Running a business means marketing, selling and support. Even releasing as open source means you start getting feedback -- both positive and negative and demands for support and features.
If you’re asking, you’ve waited too long. Give up on perfection and ship it. Get it into the hands of users, customers, whatever, get feedback, and iterate loop from there. Failure isn’t imperfection, it’s giving up or never trying. Ship it!
Ship with the minimum features needed. Add more on a set timeline, every x months. The costumers will tell you what they want so ship ASAP with no major bugs.
My personal motto is: “don’t chase perfection, and don't settle for mediocrity“. I can’t just ship the most basic thing because I find that boring and demotivating. I don’t like to make good enough things. I take joy in going a little deeper into things. But chasing perfection is a never ending road.
What helps me is to write down my vision of an mvp. As I start to work on it that vision may change. I may think of this or that feature. If I get that itch to add something new, I go back to that document. I ask myself if this is really a critical addition. Sometimes I come to the conclusion that yes, this new way of thinking is the way to go. Most times I just write it down as something to explore in the future and keep going.
If you're scared to ship the first iteration of a product and keep procrastinating, just go open or fair source and you'll start to feel pressure to get things into an MVP asap. You'll see the README needs work, those open PRs need to move, your repo need stars, that one feature isn't tablestakes, etc., etc.
Give yourself some immediate, immutable deadline that reasonably scares you and causes you to scramble (eg. 48 hours for initial release).
From there, give yourself a regular release schedule that makes sense for your work place and helps prevent scope creep (eg. weekly releases every Friday or whatever).
Thanks everyone. I just shipped what I've been working on for 3 months. Even though everyone says it was fine, I know that it was too early. I should have made some working demos, polished the API a little more, and done a lot better job on the announcement post.
Hopefully this will at least be a lesson for someone else.
For my case, I killed projects several time. The most recent one was because when the deadline passed, the team couldnt deliver it properly. We needed more time to fix all of the bugs, while the market already shipped better products. So its better to call it quit, and focus on other products.
Maybe your friend is procrastinating. Does he even want to ship it? Maybe your friend likes developing and polishing.
Shipping a product is the moment of truth. Will people buy it? or even use it? Running a business means marketing, selling and support. Even releasing as open source means you start getting feedback -- both positive and negative and demands for support and features.
Perhaps your friend needs support in those areas.
If you’re asking, you’ve waited too long. Give up on perfection and ship it. Get it into the hands of users, customers, whatever, get feedback, and iterate loop from there. Failure isn’t imperfection, it’s giving up or never trying. Ship it!
Ship with the minimum features needed. Add more on a set timeline, every x months. The costumers will tell you what they want so ship ASAP with no major bugs.
My personal motto is: “don’t chase perfection, and don't settle for mediocrity“. I can’t just ship the most basic thing because I find that boring and demotivating. I don’t like to make good enough things. I take joy in going a little deeper into things. But chasing perfection is a never ending road.
What helps me is to write down my vision of an mvp. As I start to work on it that vision may change. I may think of this or that feature. If I get that itch to add something new, I go back to that document. I ask myself if this is really a critical addition. Sometimes I come to the conclusion that yes, this new way of thinking is the way to go. Most times I just write it down as something to explore in the future and keep going.
If you're scared to ship the first iteration of a product and keep procrastinating, just go open or fair source and you'll start to feel pressure to get things into an MVP asap. You'll see the README needs work, those open PRs need to move, your repo need stars, that one feature isn't tablestakes, etc., etc.
Give yourself some immediate, immutable deadline that reasonably scares you and causes you to scramble (eg. 48 hours for initial release).
From there, give yourself a regular release schedule that makes sense for your work place and helps prevent scope creep (eg. weekly releases every Friday or whatever).
You ship when product features match the product you market verified. You did market verify before coding, right? If not, go do that now.
Thanks everyone. I just shipped what I've been working on for 3 months. Even though everyone says it was fine, I know that it was too early. I should have made some working demos, polished the API a little more, and done a lot better job on the announcement post.
Hopefully this will at least be a lesson for someone else.
For my case, I killed projects several time. The most recent one was because when the deadline passed, the team couldnt deliver it properly. We needed more time to fix all of the bugs, while the market already shipped better products. So its better to call it quit, and focus on other products.
Every two hours, roughly.
Cut scope to the absolute minimum (does the form submit, does the entire pipeline run) and release.
Then iterate.
Whatever is a departure from your original mission should be dismissed unless you have a proven market there
Presumably, there is a set of specific goals to be accomplished for the next release. I ship when those goals have been achieved.
It's time to go public. Your friend will know when it's ready. Open-source is public domain. 101
When u think u can extend it any time u want.