Writing specs can leave you with a sense of accomplishment, particularly if you’ve put a lot of thought and/or effort into it.
The thing is, thought and effort don’t mean anything until the product is actually used (whether in testing or in real-world situations). What you and the requestor thought was perfect in writing could turn out to be a white elephant, a feature that doesn’t serve its business purpose; or worse, one that is generating the wrong data.
A small case study: we pushed out a calculation based on an agreed spec with the user/requestor. On launch though, the requestor found that it wasn’t right, so we discussed again, and for this release, I let them test it out on staging. Turns out, despite agreeing a second time on the requirement, it was still wrong (or at least, it wasn’t giving them the figure they needed).
Asking a little more, again I realised if I had fully understood the background of the request, it would have helped me suggest an alternative. Turns out they needed to cover a broader set of costs in the calculation – one which had too many rare use cases to build for – meaning the better solution would have been to have a new numeric field. Of course not ideal for the user as they would have to calculate the case themselves – but when they’re just one of six countries and there are regional implications, you have to explain why certain things can’t be done.
It’s a reminder to me that good Product Management doesn’t stop at writing beautiful, functional specifications. It requires you to have a deep understanding of the user/customer, so you really solve the problem at hand. And also that even if we put all our effort and energy, we don’t always know if things will really work. At some point, a decision needs to be made to sign off on requirements and ship (ideally to user testing first) – because the longer you wait, the longer before real users actually get to test/use it. And I find some user stories need to be prioritised above others; I rather the bigger features/fixes take more of my energy than the small ones – spend your time and effort on polishing the important user stories and specs, and let real world usage weed out and answer for the rest.
Bonus thoughts from Seth Godlin here.