Explore four signs that product development was pushed into a feature rush mode, also known as a feature factory. It comes with significant setbacks that you, as a founder, need to be aware of. Knowing these signs will allow you to counteract the negative effects to maintain good team morale and the quality of the sprints’ output.
The history of the most important products shows us that being first at something usually books you a winning spot. The best example here is Netflix, which not only started the video streaming industry but continues to dominate it to this day. However, with the current heavily saturated market, having a more refined product is far better than simply being ahead of the competition. Moreover, the rush to be innovative and first to market can cause the founders to focus on quantity over the quality of new releases, potentially (accidentally) squandering great ideas.
Why worry?
Let’s open with one clarification: Feature frenzy and producing lots of quality updates are not the same thing. The frenzied approach implies that something important was lost along the way: A deeper purpose and focus on the market and user needs. Instead, the team is implementing tons of half-baked additions to the product that often make it confusing and harder to use. That being said, no one chooses to change their development team into a feature factory. It’s a gradual process where too many targets and opportunities are tackled simultaneously, and everything becomes urgent. Once the frenzy begins, the team is in such a rush and focused on developing the poor quality updates that no one notices the counter-productive situation or simply doesn’t dare to speak up.
Thus, while it would be great if the founder were not surrounded by “yes people,” very often, it’s up to you to notice that things took a turn for the worse, and a course correction is required. Why?
As eluded in the intro, while being first to market is important, it’s also important to provide quality that will convince the users of the new solution. Imagine if the first iPhone had a battery that held the charge only for an hour (but it works and it’s the first smartphone!) or had a plastic screen that would scratch so easily, that it would look terrible within a few days of use. Simply put, the users won’t adopt a new solution if the quality is not high, even if the problem and target market are correctly identified.
4 signs that you are rushing your product
So, with all that being said, how should the founder recognize that the product entered the feature frenzy state?
The features you release fail
The outcomes of all the product initiatives you and your team are working on are always a bit of an unknown. You won’t know the real impact of that code until users get the opportunity to use it. As there is risk involved, it’s only natural that some initiatives will fail while some will be successful. However, one of the side effects of the feature rush is that you will see many more failures than successes. Without proper preparation and time to “cook,” bad ideas will come out bad, and good ideas might be wasted as one or several minor details gotten wrong will spoil the overall impression. This situation might go unnoticed as the feature rush might not be visible in the commercial figures. The accounting might report great growth while new features will fail time and time again. As long as the “money checks out,” that might not even be a problem. However, bad times will eventually come, and a broken product development process won’t help rectify the eventual issue. Thus, it is up to the founder or other person taking the Product Manager/Owner role to notice the streak of failures and consider a feature rush diagnosis.
The basics are being neglected
A team working in a feature frenzy may lose sight of the original problem they were trying to solve and the unique value they were trying to deliver. This can mean that the new updates to the product either don’t fit or maybe straight up ignore the current vision and strategy for the product. Most likely, in a feature factory situation, the vision and strategy will be there somewhere, but everyone will treat it as non-existent, simply chasing the next “biggest priority on the agenda on an ongoing basis. There is an additional sign that a founder can notice that the frenzy stage is real: the backlog prioritization process becomes more and more opinion and not data-driven. If the team and founder do not bother checking whether the next idea to implement fits the chosen product direction, most likely, the data justifying its creation is also not there, making a scientific approach to choosing the next task impossible. Of course, there can be products that have a very basic vision, ad-hock strategy, and backlog dictated by the biggest client’s needs. While it seems drastic, it is rather sensible. Prioritizing the roadmap based on clients’ chances of contract extension, given their size, helped many early products grow into mature enterprises that are not dependent on a few contracts to survive. This situation doesn’t necessarily translate into a feature factory as long as the “client-driven-development” approach is transparent to the team. The problem appears if the product has a committed roadmap AND tries to please every potentially upset client at the same time.
However, poor prioritization processes while ignoring the core product guiding principles are not the only signs of working in a feature frenzy mode.
Updates are not iterated on
Quality takes time and user feedback. Designs will evolve with time and with more refinement sessions. The messaging and flows might change during the discovery phase, and once released, different variations and follow-up changes should be implemented. That is, if there is time and focus. In the feature frenzy stage, everything is created at a break-neck speed, and the roadmap is full of planned updates without considering the need to react to future feedback. Though we need to stress, it can be beneficial during the pre-release stage. It’s a valid strategy to rush initial development and polish the potential future diamond based on user feedback after release. However, if your team has no follow-up work time booked and three other features are waiting to be implemented, you might be in the feature frenzy.
This also creates a paradox, where the feedback and release data are usually collected and analyzed; however, without development follow-up, it’s time wasted. This waste may then grow on the new release as a whole, as a good idea might not be given time to breathe and win over the users. This space needs to be present if the team wants to place the new update organically within the context of the whole product, make sure it’s easy to use, have polished copy and transitions, and other small details that simply need time to come off as polished. The packed roadmap will also come with another sign of being in a feature factory:
The team is tired, stressed and everything is late
Putting update after update after update comes with the necessity of streamlining the process and working very hard around the clock to keep up with requirements. This process called “crunch” not only forces your team into overtime, but it also kills productivity, creativity, and the will to speak up with one’s ideas. Creating quality software is as much an engineering challenge as it is art. People who are overworked and constantly on edge don’t show a lot of creativity and, thus, produce worse software.
Of course, it’s not about developers playing ping-pong most of the day in the office. One can work hard with dedication while having the space to work in peace and be able to communicate any red flags.
Additionally, as any new development comes with hours of meetings dedicated to this initiative, thus you might notice that your calendar is packed and your team spends more time on calls rather than having focus time to code. Of course, this can be the case even outside a feature factory scenario, but if you need to book lunch in your calendar to have any opportunity to eat something during the day, perhaps it’s a good idea to reflect on how you conduct your development.
I might be in a feature frenzy - what now?
Fixing any problem starts with admitting there is one. It would be beneficial to come to your team and call out the current situation and discuss the potential way forward. We can propose two solutions:
- Go back to the basics and re-examine and re-prioritize the backlog: If you realize you have decided to pursue too many initiatives, come back to your vision, strategy, and goals. Take the time to examine your backlog and decide what the real biggest opportunities are and focus on those. Of course, couple that with making sure there is always focus in the team (i.e., one sprint goal), and they take time to brainstorm the best approach. Finally, make sure user feedback is heard and acted upon! However, do realize that feature frenzy tendencies might be a part of your, the founder’s, character, and the team’s culture. Thus, slowing down and giving more focus to top priorities might have to come in steps. However, there is another situation that needs to be considered:
- Accept the situation and give it realistic end conditions: Your product and market might be in a situation where the break-neck race to provide most features is the way to have a successful product for the time being. However, keeping up a feature frenzy is not sustainable. People will quit, users will leave a bloated product, or a poor technical backbone will cause the product to collapse. Thus, it gives the team an achievable target, which will mark the end of the rush and transition into a more sustainable mode of work, where the team is allowed to come back, examine, and improve past work. This goal might be a fixed list of features, winning a specific client, launching something within a specific region or time, or simply achieving profitability. However, if you set a goal like this and present it to the team, make sure to closely follow and report its progress, as well as make additional efforts to improve the chances of reaching that milestone.
Closing words
As you can see, while the definition of feature rush does come with some negative baggage, sometimes it is a viable tool to win your market. The key here is to make it a decision, not allow the development to slowly morph into a feature factory. We hope that the four signs of this happening will help you avoid accidentally slipping into this potentially unfavorable setup. This can be hard, and you might need help. We are here to assist you and support you in finding the right balance between quality and quantity of the number of releases so that you can showcase another successful product in your portfolio.
