A couple thoughts (and thanks for the response, by the way). Great question that has helped me clarify my point.

First, as one commenter above noted … you can be very successful and still run a feature factory. You’ll notice that I didn’t mention a lack of business results in my original post. I didn’t say your company failed. I have personally worked at feature factories that were very successful financially (at least for some period of time). They didn’t let me evolve my craft, and they were easily disrupted, but somehow the lights stayed on. So … feature factories can make money.

Second, my post wasn’t targeting people that — for whatever reason — have yearly release cycles. If I was working in terms of yearly release cycles I would be forced to run a feature factory of sorts (and to find elaborate ways to validate these features prior to release). Why? The feedback loop is just too long. You simply can’t respond to customer feedback as they use the features in the real world, with their data, and in their environments. With that in mind, I wouldn’t even worry about that input into my decision making.

When I wrote this post, I was referring to B2B and B2C SaaS products where customers are billed monthly, can opt out (cancel), expect regular functionality improvements, and have the potential to seriously screw things up in terms of adding too much complexity if they don’t aggressively validate their work. I am referring to teams that ship hour, daily, weekly, or bi-weekly. I realize this isn’t the only way to deliver software, and that non-SaaS products have a different dynamic in terms of feature planning. I’m sure your product is very successful, and a good reminder that not all companies need to operate like this.

It appears, from your description, that customers wont get the update without spending money. This is fundamentally different from a SaaS model billed monthly. In many cases the “new stuff” comes at no extra charge. You are billed based on user seats, usage, etc. It is more similar to a service ecosystem.

Good call out with your comment though … different models can require a different approach.

Finally, the proof is in the pudding. Somehow you’ve found a way to correctly predict the problems that need solving, and then predict which solutions will solve those problems. You have a good batting average. I’m still wondering, though …

Would customers upgrade if you delivered half of those features? Do you test that? Would customers upgrade if you delivered an alternate set of features? Do you test that? Do customers adopt 100% of your new work? (I guess they do, otherwise they wouldn’t upgrade?) Do you aggressively usability test your new features beforehand and change course if the feedback is adverse? Do your teams have the flexibility to iterate based on customer feedback? What % of your customers upgrade? Perhaps with a yearly cycle it is impossible to answer some of these questions. But they’re worth considering.

Thanks again Sergey. Great question.