I knew 100% that a recent Recruiter platform change had to be made and also that it would likely ruffle some feathers. It changed the way recruiters submit candidates to the platform, which is a core function of the software. Whenever you change a core function, it’s bound to cause some issues.
What’s interesting though is that I did not predict the central theme of user’s complaints with the new system. Without getting into things specifically, they did not resent the new process per se, but rather needed a very common use case addressed in a much more elegant way.
Software spec meets the real world.
It’s hard to predict this kind of real-world feedback and design it into the project. Users hearing about a change will often ignore it until it happens. Users discussing the change beforehand often can’t communicate how they will actually use the software.
The lesson learned could involve a highly resource-intensive, slow process of product development: focus groups, months of user testing and acceptance, etc. But it’s not a real-world answer to startup development. Some more quick Zoom sessions and discussions with users – absolutely.
But I think the real takeaway is to plan a post-launch push as an expected reality. Plan to quickly respond to feedback and issues, and iterate around the concept that was pushed, while maintaining its core function.
Meaning, instead of planning for: code pushed, done; plan for code pushed, code.