Feature creep is something I’ve dealt with firsthand in my family business, BlueTraker, where we design Vessel Monitoring Systems(VMS) hardware for sustainable fisheries management. Five years ago, we set out to expand our core product by developing a sensor to tag fishing gear, enabling governments to track when and where equipment was used. What followed was a classic example of feature creep derailing a project.
We developed a prototype for the Croatian Ministry of Agriculture, aiming to create a sensor that acted as a “license plate” for fishing gear. It would measure essential metrics like gear entry/exit times, soak time, depth, and temperature. However, instead of sticking to these core requirements, my team and I began adding extra features—sensors for light intensity, salinity, and phosphate levels—thinking they would appeal to scientists and oceanographers.
What we failed to consider was that the government didn’t need these features. They wanted a simple, cost-effective tool to monitor fishing fleets, not a complex device for crowd-sourcing oceanographic data. The prototype was too expensive and far removed from their needs. As a result, when it came time to roll out the sensor to the entire fleet, the Ministry refused to purchase more units.
In retrospect, this ties directly to John Gourville’s insights in Eager Sellers and Stony Buyers. We were the eager sellers, excited about innovation, while the government was the “stony buyer,” resisting because our product didn’t meet their needs and was too costly. Gourville’s “9x Effect” describes this mismatch perfectly: sellers overvalue their innovations while consumers stick to the status quo.
This experience taught me the importance of managing feature creep. As product managers, it’s easy to get carried away with new ideas, but we must stay grounded in what the customer actually needs. Eventually, we stripped the sensor back to its core functions—monitoring soak time, depth, and temperature—reducing costs and delivering a product aligned with government expectations, though it took an additional six months.
To avoid feature creep, I’ve learned to stay focused on the product’s core value proposition: what problem are we solving for the customer? If a feature doesn’t enhance this, it’s probably unnecessary. Regularly checking in with customers throughout development also keeps the focus on real needs, not just innovation for its own sake.
Additionally, using frameworks like the MoSCoW method helps prioritize features, ensuring only the most critical ones make the cut. Lastly, simplifying the MVP (Minimum Viable Product) allows for user feedback and iteration based on actual needs, not assumptions.
Our story at BlueTraker is a reminder of how easily feature creep can disrupt product development. The lessons I’ve learned continue to guide my approach, ensuring that innovation serves the customer, not just the excitement of building more.
