Title ideas: success, research, data, user

The Problem

  • Companies create roadmaps of features quarters in advance. Maybe with room for roadblocks but definitely not room for rewrites, refactors, or surprise features.
  • This is because what matters to many businesses is that an initial idea is justcdscdas built, success is secondary (or subconsciously desired). What matters most is features checked off the list, not metrics like 5% revenue increase or 10% user retention increase. The business hopes these will happen as a default of the product being built but they aren’t evaluated at every step. They aren’t tested.
  • We end up building software because someone wanted it built and we forget why we decided to build it in the first place.
  • Product owners are disappointed by lack of velocity, where velocity is defined as the number of features completed in a sprint.
  • We get into the cycle of thinking it’s “bad” to remove features.

The Proposed Solution

  • Test with users often. Actually collect data to give back to business.
  • Define success. Which means defining the why of a feature.
  • Every feature should have a business outcome in mind with specific metrics attached to the goals
  • Cut the project before it’s too late

“the single most important factor that will make a service successful, is the end user satisfaction” 1