I’ve worked on far too many projects that were treated as if the feature launch were the end of the project. Hooray, the feature is live and now we can get onto the next thing on our list. It’s the way it was done for a long time and truthfully it’s the way a lot of companies still build products today.
Just like many things, the first step towards fixing a problem is admitting you have a problem.
Over the next few days I’m going to be writing a series on usability testing, the what, when and how of it all, but as I was planning out those posts it got me to thinking about this issue that I know is still plaguing companies. Teams are agile and scrumming and running sprints, all towards this illusion of being done. But when do you really know that you’re done?
The definition I use for done is when the customer is happy and the most important metric I’ve been tracking towards has been hit. Those two things tell me I’m done, not a feature release date. I like to think of the feature release date as a baton handoff in a relay race. If all has gone well this is the second such handoff. The first such handoff should happen after testing and experimenting during the design phase as I shift over to the development phase with the engineering team. That is not to say that all teams shouldn’t be involved during all phases of the process, in fact UX, design and engineering should be communicating all along the way, rather it’s just the phase of the project you’re in.
After the release of a feature you should be checking your data to make sure that it’s in line with the hypothesis you made prior to launch and allocating proper resources in order to make changes necessary in order to move the needle towards your goal. The resources used during this step should be greatly diminished from the major push which was just completed, but the problem is that many companies allocate no more time on the completed feature. That is why there is no true learning and features that are not contributing the way they should to the overall product.
It could take you months to drive the numbers in the way you need them to go, but keep making small tweaks and changes and follow the data. Once you feel like the feature is performing as expected and adding the value you originally intended, then it is time to move it over to maintenance mode.
Maintenance mode is a point at which further investment into improving your numbers will be a waste of resources, delivering diminishing returns, so at this point you set a goal (maintenance goal) in order to verify that the feature is staying the course and not dropping, but with little support.
Would you like to know more on how to have these conversations and begin to create a culture of learning? Let me know in the comments below.