One thing I've noticed on a lot of teams is that sales/product believes their own hype and overestimates the importance of their software in people's lives. There's this belief that customers/users are waiting impatiently for features when 99% of the time, they're just not. Yes, features affect users, but often users don't know what features are coming, because they just don't care enough to know.
Software I use every day: Firefox, Slack, Vim, MacOS, Python, Bash, GCC, Android, StrongLifts 5x5 App, Gmail, Google Docs, Google Maps, Simple (Banking) App, VLC.
All of these (except maybe Vim?) have released some significant features in the past year. Of these features, I only knew about a few Python features that were coming before they came, and none of them were ones where I was thinking "I can't wait for this to come out! If this doesn't come out soon I'm switching languages!"
On the contrary, features take a long time after they come out for me to learn how to use them and for them to affect my decision making. In fact, my initial reactions to new features are much more likely to be a liability than to be an asset to the software company. I'm considering switching away from Simple because their expenses update doesn't really fit my needs, since as a freelancer I'm not paid on a regular schedule. And I'm definitely switching away from MacOS since their deprecations have broken some tools that are key for me. If they had taken more time, maybe someone would have noticed the problems and avoided them.
Sure, early on things are different: first-to-market advantage is real. But for most of the lifetime of a project, you aren't releasing killer features. You're releasing incremental changes that have a much higher chance of losing you users than of gaining you users (in the short run, at least). Never releasing isn't an option--death by stagnation is a thing--but releases should be done with painstaking attention to detail rather than urgency.
Another thing sales forgets is that the features you already have are more valuable than the new features to actual users. They always want to sell the new things, but provided features are added with most valuable first the earlier features will be more valuable than the new stuff. This gets really silly when they rush releases to get the new features and end up breaking old features, which actually decreases overall value of the software compared to releasing nothing new at all.
It's more of a marketing-first approach than user-first.
There is something I'm impatiently waiting for though: Optimization so it doesn't take 5+ seconds for Photoshop to load and be usable. Why doesn't it load within 100ms on $3,000 modern hardware? It's image editing software, not Grand Theft Auto!
That's where some energy could be put and make a real, tangible difference to everyone.
It kinda is Grand Theft Auto, though. Most of the opening time is spent locating assets and plugins to build menus (and all of those can be added or removed without launching Photoshop).
Bingo. That's sooo bad for engineering that a company does that, and probably bad generally as well. My company does this and its infuriating, like, you don't even know what's involved, why would you do this? My company also, for most of its lifetime, has relied on contracting out software development.
My current project in fact started out life offshore but the work was so slow-going and awful iterative results that they then rev'd up a real software team to complete it. Initially they wanted us to complete the project without scraping the offshore code base, which was in baaaaad shape. It took another consultant, hired for a different reason, rather than listening to their in-house leads (of which I was not one, I was a junior at the time), that they needed to scrap that code.
When the customers are telling your sales people that they are going with the competition because they have features that you don't, one should take notice, though with the caveat that the customers are not necessarily being completely transparent about their motives.
With saas products you can call bullshit on these situations. The second time you are presented with a demand to produce feature X by date Z you can take a look at the results of the previous time that you were told that feature A needed to be done by day B and show exactly how many customers used that feature on the due date and exactly how many new customers signed up at that time
This is fairly controversial. Is there any example of a startup that actually made it by employing this strategy?
One of the truisms I've heard and have always followed is you need to release something you're embarrassed about, because that's the quickest way of getting user feedback, and understand if a user actually _wants_ that feature, and if it's actually worth spending time improving that feature.
It's easy to waste valuable capital paying attention to details that the user does not really care about.
EDIT: I've noticed that most of the software you posted here is very well established, most > 10 years. I'd be surprised if any of them follow "agile" by the books.
Not the OP, but I believe he and you are talking about two different stages in the life of a company. He's describing mature products and organizations (as is the blog author), and you're talking about a company that is attempting to complete their first offering.
> Is there any example of a startup that actually made it by employing this strategy?
Is there any example of a startup that actually made it by releasing features that were broken or poorly thought out?
Is there any example of a startup that actually failed because they released features a week or a month after an internal deadline?
Do we have enough insight into the internal strategy of enough companies to make any claims about this at all?
Your argument is basically looking at existing startup culture, but realize that most startups that use a fail fast strategy do exactly that: fail. I'm not saying that's causal: I think success is hard and there's a myriad of reasons why startups fail. But I don't think we can look at the fraction of startups that have succeeded and point to this one element of their strategy and say, "This was a necessary component of their success."
I'm not looking at the whole industry because I don't think there's enough representative data there. I'm looking at my own experience as a user and noticing, "Hey, I actually don't even know what features are planned for any of the software I use, yet I'm still using it. So maybe future features don't have anything to do with why I use software. And maybe other users are similar."
Let me ask you: can you name 5 features that you're looking forward to in the software you use? If those features take a year longer than expected to materialize, do you think you'd switch to a competitor? That's rhetorical: I am sure some HN people can answer those in the affirmative, but I'm also sure that's not the norm.
> One of the truisms I've heard and have always followed is you need to release something you're embarrassed about, because that's the quickest way of getting user feedback, and understand if a user actually _wants_ that feature, and if it's actually worth spending time improving that feature.
Sure, but then you don't know if the user doesn't want the feature because it's not useful, or because it's badly implemented since you didn't spend time to get it right. You're collecting data faster, but you're also confounding the data so that you don't know what it means.
> It's easy to waste valuable capital paying attention to details that the user does not really care about.
Agreed. One of the details I'm saying the user does not really care about is whether your feature is released today or three months from now.
> EDIT: I've noticed that most of the software you posted here is very well established, most > 10 years. I'd be surprised if any of them follow "agile" by the books.
...which is a pretty damning statement about '"agile" by the books'.
I'll say what I've said before many times: the entirety of agile is contained on this page: https://agilemanifesto.org/ . "Agile by the books" is an attempt to make money off a successful strategy, but you can't sell six lines of text, so people write books on how they implemented agile, which if you understand agile, is fairly useless for understanding how YOU should implement agile. If you really grok those principles, then it's really clear that releasing early to get user feedback doesn't follow the principles:
Individuals and interactions over processes and tools The deadline is a process rule that you're prioritizing over literally every individual in this situation.
Working software over comprehensive documentation Releasing broken software so you can document user response doesn't follow this principle.
Customer collaboration over contract negotiation Customers should be involved long before you're releasing features.
Responding to change over following a plan The deadline is the plan. The fact that the feature isn't ready by the deadline is the change that you need to respond to.
In my last job we were sufficiently sophisticated users of AWS that we routinely had conversations with product managers to learn if specific features were on the roadmap, and if so, if there was an ETA. We had these conversations because we were debating whether we wanted to write a solution of our own, or if we wanted to wait for a generalized one to be released.
That said, the product managers generally left us with information such as "this is actively being worked on", "this is planned work in the upcoming quarter, but it could change", "this is on the roadmap without a date", and "this is not on the roadmap". No specific dates promised, but it was still good enough for our purposes.
I hope they weren't using our requests to push for specific dates, internally.
It is worth noting that ALL the agile values you spelled out are actually important. That said, the values on the right do not take precedence over the values on the left.
Processes and tools are important so long as they don't diminish individuals and interactions.
Documentation is important so long as it doesn't get in the way of building software that works.
Contract negotiations are important so long as they don't get in the way of a collaborative relationship with customers.
Following a plan is important so long as it doesn't get in the way of responding to change as a competitive advantage.
Software I use every day: Firefox, Slack, Vim, MacOS, Python, Bash, GCC, Android, StrongLifts 5x5 App, Gmail, Google Docs, Google Maps, Simple (Banking) App, VLC.
All of these (except maybe Vim?) have released some significant features in the past year. Of these features, I only knew about a few Python features that were coming before they came, and none of them were ones where I was thinking "I can't wait for this to come out! If this doesn't come out soon I'm switching languages!"
On the contrary, features take a long time after they come out for me to learn how to use them and for them to affect my decision making. In fact, my initial reactions to new features are much more likely to be a liability than to be an asset to the software company. I'm considering switching away from Simple because their expenses update doesn't really fit my needs, since as a freelancer I'm not paid on a regular schedule. And I'm definitely switching away from MacOS since their deprecations have broken some tools that are key for me. If they had taken more time, maybe someone would have noticed the problems and avoided them.
Sure, early on things are different: first-to-market advantage is real. But for most of the lifetime of a project, you aren't releasing killer features. You're releasing incremental changes that have a much higher chance of losing you users than of gaining you users (in the short run, at least). Never releasing isn't an option--death by stagnation is a thing--but releases should be done with painstaking attention to detail rather than urgency.