4 ms·

This is a popular sentiment around here, because we care about the craft and want to build something that is beautiful/well-made. However, speed is not “the ki

This is a popular sentiment around here, because we care about the craft and want to build something that is beautiful/well-made. However, speed is not “the killer feature”. Speed does not add any value in isolation; your app needs to solve a need for the user first. If you don’t have PMF don’t think about speed yet. The article gestures at objectivity by linking some cases where people measured revenue gains from speed improvements, but fails to follow through and actually propose an experiment or ROI calc. If you think your app is slow, run an experiment and measure the impact on conversion. (You can even take a page from Google’s book and _add_ delay with a simple sleep() if you don’t want to spend any time on perf work before you get data. Or just do the first bit of low-hanging fruit and measure the impact.) Talk to your users and ask them what frustrates them in the app. It might be “takes so long to check out”, or it might be “it just lacks feature X that competitor Y has”. I’d suggest it’s unwise to spend time on perf work if you are pre-pmf and the main feedback was the latter. Again, do experiments too because customers don’t always tell you what they need. In particular enterprise users often don’t care as much about speed, as long as you tick all of the boxes. Many users are used to line-of-business software that is slow and buggy, so your bar in B2B is not always high here. Finally do an ROI calculation. If a perf iteration is going to cost you $20k in dev resource, and get you 7% improvement on $10k of monthly revenue, that might not be the right thing to focus on. Ideally you’re looking at features that will improve your top of funnel volume more than that. It’s all a trade-off. It depends on your company’s level of maturity, Product/Market fit, and the value of the marginal feature that you’d be deferring to make your app go faster. If we interpret this to be a political manifesto carrying the message “you should care more about speed/performance”, I’d prefer the meta-level “you should care more about trade-offs and marginal value”.

vp8989 6y ago
Maybe it's because I am not in "the Valley", but this line of thinking makes absolutely no sense to me. You are speaking in generalities, so you are essentially implying that most people are working on software that has not achieved product market fit? How could the majority of people collect a salary working on software that has no users? That makes no sense.
- karpierz 6y ago
  If you have 10 companies to invest in, each of which has a 10% chance to produce 20x returns, 90% of the engineers at these companies wouldn't really have users. Basically, if you think that software is feast-or-famine as an investment, then this would make sense.
  - DylanDmitri 6y ago
    If all engineers worked at early-stage startups, this would be the case. However most engineers (upwards of 95% outside of Bay Area) work at established companies.
- theptip 6y ago
  Hacker News is affiliated with YC, a startup accelerator. While there are lots of FAANG engineers and engineers from all parts of the spectrum here too, this community biases towards startups. If there is a place to discuss strategy for pre-PMF startups on the internet, this is it. I’m not intending to generalize, quite the opposite. I’m arguing against a generalization that “speed is the killer feature [for all products]”. In my post I presented a few cases where this over-generalization is not true (pre-PMF startup and potentially large B2B product) and suggested a more nuanced and objective analysis of the trade-offs. > You are speaking in generalities, so you are essentially implying that most people are working on software that has not achieved product market fit? Perhaps try parsing my post as “here are a few examples of common cases where speed is not the killer feature, and a sketch of a more flexible thought process that will get you to a better answer”. Product managers at both large and small companies use ROI and experimentation to figure out what to build (though in some ways it’s actually harder at a startup as your sample size can be too small to get statistical significance, or at least to run as many experiments as you’d like).

vp8989 6y ago

Maybe it's because I am not in "the Valley", but this line of thinking makes absolutely no sense to me. You are speaking in generalities, so you are essentially implying that most people are working on software that has not achieved product market fit? How could the majority of people collect a salary working on software that has no users? That makes no sense.

karpierz 6y ago
If you have 10 companies to invest in, each of which has a 10% chance to produce 20x returns, 90% of the engineers at these companies wouldn't really have users. Basically, if you think that software is feast-or-famine as an investment, then this would make sense.
- DylanDmitri 6y ago
  If all engineers worked at early-stage startups, this would be the case. However most engineers (upwards of 95% outside of Bay Area) work at established companies.
theptip 6y ago
Hacker News is affiliated with YC, a startup accelerator. While there are lots of FAANG engineers and engineers from all parts of the spectrum here too, this community biases towards startups. If there is a place to discuss strategy for pre-PMF startups on the internet, this is it. I’m not intending to generalize, quite the opposite. I’m arguing against a generalization that “speed is the killer feature [for all products]”. In my post I presented a few cases where this over-generalization is not true (pre-PMF startup and potentially large B2B product) and suggested a more nuanced and objective analysis of the trade-offs. > You are speaking in generalities, so you are essentially implying that most people are working on software that has not achieved product market fit? Perhaps try parsing my post as “here are a few examples of common cases where speed is not the killer feature, and a sketch of a more flexible thought process that will get you to a better answer”. Product managers at both large and small companies use ROI and experimentation to figure out what to build (though in some ways it’s actually harder at a startup as your sample size can be too small to get statistical significance, or at least to run as many experiments as you’d like).