Hacker News Reader

Comment by superfamicom | Hacker News Reader

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.

View on HN

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.

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.

> ideal code

One problem in these discussions is that people quickly start using absolutist language, which makes it hard to find balance.

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.

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.

Reply on news.ycombinator.com