Most development teams forget to do a key activity: measuring the success of new features. Teams need to create metrics that will validate or invalidate the assumptions behind the feature and also alternate implementations. But it starts with creating measurements!
In this episode, I discuss the importance of measuring your software, some types of measurements, and an example of measurements in action at The Home Depot. As with other episodes this week, this one builds on one of the ideas in the book Radically Collaborative Patterns for Software Makers, which you can get for free – check out the links in the episode or the link at the end of the episode.
- Don’t forget to measure things.
- You often assume someone else will be measuring.
- This means you can’t use it as feedback – only focus on project metrics (budget, schedule, QA, delivered features) for feedback – plus negative bug reports!
- Some starter metrics:
- Awareness – do people even use your new feature?
- Completion rate – buying a thing, signing up for an account, going all the way through a workflow.
- Time spend on workflow.
- Accuracy – generic, but whatever.
- Churn rate/retention; lowering operating costs; growth; doing loose-causation activities (loyalty programs, educating self on banking activities).
- Loose example: Home Depot buying washing machines (shows that you need to focus on end outcome, not just app itself).