Why I don’t write long specifications.
From Waterfall to Agile
In the dark ages we all worked in waterfall. We planned everything months ahead of time. We had to write very detailed requirements in advance, review them and plan accordingly. It resulted in slow reaction to changes and many obsolete requirements.
With the move to agile and the preference of working software over comprehensive documentation (see the agile manifesto) there is less demand for such long specifications. However, I still find that many product managers write much more than necessary (and I still hear the term PRD too many times).
I would like to explain why I think it is not just a waste of valuable time, but also why it often actually results in a lesser product.
Your Time is Valuable
There is no question that you need to write requirements that are clear for both developers and QA. But do you really need to write them so long?
Are you making sure to write more about the problem and the customer need and how you want to measure success and less on the solution itself?
Do you really need get into every error case instead of trusting the development team to handle it?
Every minute you spend in perfecting the details of a solution for a problem you already know you need to solve, is a time you don’t spend trying to find the next one. It is a time not spent on the bigger picture, on strategy or on talking with customers.
Spend as less as you can on writing the requirements. Write them as short as you think your peer developers and QA would need to understand them. I would even argue that if you know who is going to work on implementing them, adapt them to how well you think they specifically can work with “holes”.
More about this in Make yourself “Redundant” and Your Role is not to Write Requirements.
Smart Creatives
In How Google Works Eric Schmidt and Jonathan Rosenberg termed “Smart Creatives” as employees of the information age who are focused on solving problems. Hopefully you are working with such people (if your development team is outsourced what I write below might not be relevant and you might need actually to write longer and more detailed requirements).
For this type of developers, if you are writing too much details and closing all loop holes, you are actually depriving them of their creativity. Developers want to think. They don’t want just to get orders and implement them. By writing too much details, you are actually getting less motivated developers (and don’t have me start talking about the fact that most of them are anyway not reading what you write).
And you are losing something else. You are losing more perspectives on the same problem and maybe some innovative ideas that you did not think of. This is true also for working with UX experts. Leave them enough space to maneuver and express their creativity and thinking.
You may argue that this can be done in the discovery phase, in which you can involve everybody, and then write the findings. The truth is that while you should definitely involve developers in the discovery phase and get their input, they would usually not be engaged as well as when they actually work on the problem. Leave some loose ends. They will surprise you.
Escalation of Commitments
Another issue with investing too much in the definition phase is that you may get too attached to the solution. It makes it harder to give up on things when you find that it is the wrong solution or that the scope you had in mind is too big and you need to do some cuts (see also Always think MVP).
This behavior is called escalation of commitment. It is a human behavior pattern in which an individual or group facing increasingly negative outcomes from some decision, action, or investment nevertheless continues the same behavior rather than alter course.
Summary
Writing specifications and requirements should be a minimal task. You should write as less as you can on the solution and as much as you can on the problem. Keep only the things that you need in order to make sure the solution is answering the need and do not have contradictions. Do not write the details that you think your development team can understand by themselves and may even find better outcomes.
Everybody wins. You get more time for strategy or just to work less hard and the development team gets more motivated and invested in solving the problem and coming with new ideas.
Less is better than more