Free your time to be more strategic
Requirements are overrated
In Are Requirements Overrated and Your Role is not to Write Requirements I explained why writing requirements should be a minimal task. I talked about 3 major reasons why it is good for everyone:
Your time is valuable. 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.
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. If you are writing too many details and closing all loopholes, you get less motivated developers who do not exercise their creativity and you lose their perspectives. When working with a good team you actually want to Make yourself “Redundant”.
Escalation of commitments. By writing too much, 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. Always think MVP when you are writing requirements.
In The Overlooked Trait of Good Product Specs, Gidi Vigo also adds the aspect of efficiency. It is just more efficient for everybody to write more concise requirements.
This time I want to explain why many of us are still writing very long specifications even though it is an agile anti-pattern, and how we can all start to write less.
Why writing less is hard
Mark Twain once wrote, “If I had more time I would have written a short letter”. Although most of us are working in agile and no longer write long and detailed PRDs and MRDs, when I talk to my fellow product managers, I find that many of them are still spending too much time in perfecting the solution and writing very long user stories.
Among the reasons I see, why some of us find themselves writing very detailed specifications even though they want to write short ones, are:
Habit. It is very easy to write long and detailed specifications and get sucked into the process comfortably sitting on our desk. It is much harder thinking what to write and what to omit and in parallel take yourself out of the building to meet customers.
Culture. We may work in an organization in which this is how it was done always and we just get into the beat of that organization.
Demand. In many organizations, the developers and testers ask us to write more and more details to make sure they understand everything and nothing gets wrong. Working together with them to get them used to think for themselves is sometimes a tedious process, but I can ensure you it worth every minute spent on it. We should also not forget that too many developers don’t read at all what we write, so it is better to make it short.
Ego. Many of us find it hard to let go of our ego. It is very flattering to feel that the development team needs us for every small decision. However, it would be good to remind ourselves that requirements have bugs also and you want to get people used to questioning them.
Trust. Are we trusting our developers? Leaving holes in the requirements means we trust the team to close those holes in the best way. Sometimes we write too much because of a lack of trust.
Writing focused requirements may take some time, in the beginning, more than detailed requirements. Time to make sure the problem is articulated in the best way. It may also take time to communicate things verbally. In the long run, however, this is time well spent. You will find yourself needing less time to work on requirements and having more time finding new problems to solve.
How to write less
Starting to write less is a process. You want to make sure that although you don’t write everything you still get the right solution at the end. You need to take in mind that you work with your development peers and that you cannot just one day change the way you write requirements. It is a process you need slowly to work together with them. It is a marathon. Not a sprint.
You may need to change the whole process and not just how you write the requirements. In the next sections, I will give some tips on how to move towards a focused requirements culture.
Show the way
The most important thing is to be able to create focus. As a product manager, you need to create a vision and strategy as well as a well-defined roadmap. The better we articulate where we want to go, why, and how we will know we got there, we can enable the development team to innovate without the need to write all the details. Treat your Roadmap as a Compass to make sure it leaves room for innovation.
You need to define a framework for decision making. Such a framework should contain the following things:
Product principles. The product's basic values can be defined by a set of product principles you want the product to follow (for more about product principles, see Framing Product Decisions and Product Principles = Better Products). Product principles help everyone understand not what decisions need to be made, but rather how we make decisions.
Success Criteria. The better we define how we measure the success of the product, the better we give tools to the team to check if they are on the right path.
Constraints. It is very important to define various constraints such as regulation, product values and time constraints.
Jeff Bezos said “We are stubborn on vision. We are flexible on details.”. As long as you constantly communicate where you want to go and why you get to a state in which the whole vision is burned into the team collective mind. It empowers them to make the right decisions and you are free to write less.
Prioritize and procrastinate
It is very important not just to prioritize features but also prioritize within features. Sometimes this makes a bigger impact on what we get than anything we could have written. Because good prioritization defines what we really get when things don’t proceed as expected.
Good prioritization also enables us to procrastinate part of the writing. I recommend writing requirements the latest you can so you do not create an escalation of commitment.
Writing requirements should not be the first thing you do. It should be the last thing you do after you worked out the customer challenges and problems.
Judge by merit
It is best to remember that we are working with professional people. We are not supposed to replace them. Work with your development team as partners and not as contractors. Trust them and involve them in thinking as early as possible. Work with them as a product team and not as a feature team (See Product vs Feature Teams by Marty Cagan).
When someone comes to you to solve a “hole” in the requirements instead of running and giving them the answer, work the answer together with them. Even though this time it might take more time, next time they may be able to answer things by themselves.
Focus only on critical decisions and let others make less important decisions. To do that you need to be able to judge ideas by their merit and not by who suggested them. In “How Google Works” Shana Brown says “It is the quality of the idea that matters, not who suggests it”. When someone takes a decision based on your requirement and takes the solution to places you have not imagined don’t ask yourself whether this is the same solution you would have imagined. Ask only if it is a good or bad solution.
Summary
While writing requirements seem like the sole purpose of a product manager, in reality, it should take less than 20% of our time.
When we think of what we write and what we don’t write and when we shouldn’t think only on how it affects the solution but also on how the requirements empower the team to provide the best value to our customers.
Less is More