4 reasons why product teams can’t avoid the “Feature Factory” trap
It is easy to understand why product teams with low autonomy, hard delivery-date pressures from stakeholders, and not-empowered product managers tend to end up in the “feature factory” anti-pattern.
Note: I’m not sure about the origins of the feature factory term, but it basically represents those product teams who operate more like a software factory, getting requests and delivering. Here is a good article to read more about it.
But I’m struggling to find out why so many product teams that have the right conditions (clear outcome-driven goals, an empowered trifecta of Product Manager / Tech Lead / Product Designer, and are encouraged to do research) end up in the same “constantly mindless deliver” model also.
To put it simply: for the last few years I’ve worked with teams were I had the opportunity to set this “good” rules for product development, only to find that some teams will continue focusing and showing what they have delivered instead of the result and value they brought to the company and the user.
4 theories of why we fall back to Feature Factory
Feed the beast
The development time is usually scarce. We want to do many more things than the ones we can do with our current team capacity.
In that context, people in charge of determining the team next tasks (a Product Manager or other sort of managers in non-product organizations) feel an immense urge to keep “feeding” the team with things to do. For that reason, we lower the expectations on how much we analyze whether a feature is really worth doing.
So we keep pushing to the teams the requests of features, for which the value is not that clear, turning us into the feature factory definition.
False security
Another possible scenario is the one in which we are certain what is the next priority. There is no need for us to spend time and effort doing discovery. Let's just build it and watch the bank account grow…
Almost everyone starts with this certainty. We are biased in so many ways to trust what we believe, that we avoid taking a deeper look at the potential real value of our idea.
But the truth is that even great companies report that 70% of their efforts in new features fail to produce the result they expected.
The problem is that even in failure, we fail to see that what we need is a “discovery phase” to avoid wasting so much time in non-valuable work. Quick experiments to validate or invalidate the “certain” ideas we carry. Once we fail, the learnings look obvious, so we determine the “certain” next priority, start building it, and repeat the model all over again.
Oh sh*t, I have to decide!
Another possible scenario is that empowered teams or Product Managers realize it is actually hard to decide! They are told to choose what is the best path to achieve a result, only to find out it is much easier to follow someone else's directive. So Product Managers go into what I call a “take orders” mode in which they ask stakeholders what they want to do next with the product.
Of course, they do the work of prioritization, resource allocation, and sometimes delivered value accounting.
But this also is the feature factory. There is no discovery of what really needs to be done for the product. But we have the peace of mind that if what we did fail to deliver results, we have someone to blame ¯\_(ツ)_/¯
The “eternal product improvement” dilemma
One of my current theories is the following: since your product timeline is “eternal” you don’t care that much about selecting the right feature to do next. You just do whatever seems to have the highest priority at this moment. Of course, you have a priority right now and it seems more important doing that than discovering if it truly must be done. When you finish it, you will discover what is next…
But what if instead of considering this eternal timeline you look at it as having just “3 versions to launch”. That is it. 3 versions and you can’t modify your product anymore. -Of course, this needs to be tied to a time constraint, ie “You have 1 month to develop each version” for instance.- I’m sure you will pay much more attention to what you actually put in each version.
In essence, this ties to a more lean approach to product development.
Conclusion
Escaping the feature factory is hard, but it may be the single most important “evolution” a product team may achieve.
Thinking back through my notes I realize you need to basically break those 4 concepts to get rid of the feature factory:
- Relax, if you don’t feed the beast in time, your developers will either do some great refactors to go faster on new features later, or they may even come up with things to do that are far better of what was on the “beast food backlog”. Just make sure you put that scarce resource in something truly worth doing.
- Embrace uncertainty and an apprentice mindset. What you need to build is not inside your brain, is out in the world and through experimentation you can “quickly” find it.
- Embrace the autonomy. No stakeholder will have all the knowledge the team can gather about the product and the customer (when doing good technological decisions and appropriate research). Taking orders is a short path to get your product killed.
- Everything you build into the product should be carefully selected, and it should only go into the product if it is really needed. Think as if you have this next launch and then your product development is over, what is the only thing you would change if you have just one more shot?
Thanks for reading! I would love to hear feedback (or claps!) and your own thoughts about escaping the feature factory.
