5 ms·

As a person who has worked at many startup, I get it, "shipping" features is important. As an engineer working at many startups, this is a sad and painful real

As a person who has worked at many startup, I get it, "shipping" features is important. As an engineer working at many startups, this is a sad and painful reality of working under product driven ideas and "first to market" type things- basically anything that doesn't (usually) involve life or death, or federal regulation is rushed out the door when it can be. As a user, I absolutely 100% hate this mentality. You skip features you don't consider necessary, do things in ways that make them difficult to return to later and throw it in the "technical debt" pile.

ysavir 6y ago
I think the "ship asap" is necessary for brand new startups. If you can't generate the user growth necessary to secure the next round of funding you'll be out of business, and that time spent writing the ideal code was not only a waste of time, but also a potential cause to the slow user growth. In its first year or so, until it receives enough funding to stabilize, it makes sense for a startup to give more weight to the short term than the medium term. But once stabilized, and there's no immediate danger of running out of runway, things shift, and the medium and long terms become much more significant. But many startups fail to realize this; they've become too accustomed to the fast-paced, ship-asap mentality. Breaking from it seems to them a decline in productivity, where it's actually just a shift in priorities. There are a lot of contributing factors to this oversights, and they can vary from company to company, but it's continuing to prioritize the short-term is a dangerous act that usually serves neither the end user nor the business.
- chiefalchemist 6y ago
  Yes. But if you're not meeting user expectations they're not going to tell anyone, and so and so on. The satisfaction of current users has to factor in some where. Else no word of mouth, and expensive churn.
- afarrell 6y ago
  > ideal code One problem in these discussions is that people quickly start using absolutist language, which makes it hard to find balance.
  - ysavir 6y ago
    Balance also is not quite the correct thing to strive for. The proper course of action is to work with the leadership to figure out when the expected critical points are for the business. This includes fund raising, IPOs, acquisition, or any other time when the company receives a valuation. The goal, for both the business and the dev team, is to make sure that the company has the best possible value at those exact points. You don't want to peek too early or peek too late. The proper course of action then is to prioritize things in accordance with how they impact those points in time. If one's coming up soon, prioritize the short term almost exclusively. If it's years out, plan ahead as a marathon, not a sprint.
    - afarrell 6y ago
      Know the enemy, but also know thyself. For example, it would be a bad idea for me to say "I am not going to write any automated tests" for a 3-week MVP. That decision would lead to me producing nothing.

ysavir 6y ago

I think the "ship asap" is necessary for brand new startups. If you can't generate the user growth necessary to secure the next round of funding you'll be out of business, and that time spent writing the ideal code was not only a waste of time, but also a potential cause to the slow user growth. In its first year or so, until it receives enough funding to stabilize, it makes sense for a startup to give more weight to the short term than the medium term. But once stabilized, and there's no immediate danger of running out of runway, things shift, and the medium and long terms become much more significant. But many startups fail to realize this; they've become too accustomed to the fast-paced, ship-asap mentality. Breaking from it seems to them a decline in productivity, where it's actually just a shift in priorities. There are a lot of contributing factors to this oversights, and they can vary from company to company, but it's continuing to prioritize the short-term is a dangerous act that usually serves neither the end user nor the business.

chiefalchemist 6y ago
Yes. But if you're not meeting user expectations they're not going to tell anyone, and so and so on. The satisfaction of current users has to factor in some where. Else no word of mouth, and expensive churn.
afarrell 6y ago
> ideal code One problem in these discussions is that people quickly start using absolutist language, which makes it hard to find balance.
- ysavir 6y ago
  Balance also is not quite the correct thing to strive for. The proper course of action is to work with the leadership to figure out when the expected critical points are for the business. This includes fund raising, IPOs, acquisition, or any other time when the company receives a valuation. The goal, for both the business and the dev team, is to make sure that the company has the best possible value at those exact points. You don't want to peek too early or peek too late. The proper course of action then is to prioritize things in accordance with how they impact those points in time. If one's coming up soon, prioritize the short term almost exclusively. If it's years out, plan ahead as a marathon, not a sprint.
  - afarrell 6y ago
    Know the enemy, but also know thyself. For example, it would be a bad idea for me to say "I am not going to write any automated tests" for a 3-week MVP. That decision would lead to me producing nothing.