Business First, Solution Second
Features are exciting. I know this, because dreaming them up is always a favorite activity of mine. But isn’t there something that has to come before you sit down and come up with how a product is going to work?
Yes - the reason for the product existing in the first place.
Look at the business of the product first. I’ve made the mistake of doing it the other way ’round, and it always causes problems and convolutes the way in which the product is structured.
If there isn’t a clear reason for why it exists, and the direction it’s moving, it will be very easy to veer off-course and come up with features that don’t really mean anything. Dev time can be better spent on features that will actually satisfy the audience.
In my roadmaps, I’ll have a bucket called, “TBD / DEFINED BY MARKET”. I put this right next to my standard quarterly groupings / buckets. This is where I will stick a whole bunch of thoughts and feature ideas (that usually make sense), because they don’t yet fit into priorities. They are left there for discussion.
Only when the features are at hand should the requirements and specifications be decided. It is then that the time is well spent. They are in everyone’s sights, and can be focused on. If they are drawn-up too far in advance, and too much detail is spent on them, they will only end-up changing anyways.
I’m currently of the mind that it’s better to talk to the developer first-hand and see what they think. If the team is built right, this shouldn’t be a problem. I know — size and all that come in to play, and I’ve had to write huge requirements docs in the past. But, not that I don’t have to where I am now, I’ll have to be dragged kicking & screaming back and away from my napkins.
