Editor's introduction: The writing of requirements documents is one of the daily business of product managers. Then, considering the content and difficulty differences of specific businesses, how should the writing of product requirements documents be done? In this article, the author combines the Axure prototype to expound his thoughts on writing requirements documents, let's take a look.
There was a disagreement with the leader business email list about the product requirements document at work. Based on the previous work habits of rapid iteration of small teams, I think it is enough to mark the interactive prototype when delivering the development, which is convenient for me to write a description and It is convenient for developers to see and kill two birds with one stone.
But the leadership made me have to write documents, and made me have to change this "dangerous" idea from my thinking. No way, although I have been working on the product for a few years, I have sorted out the form of delivery of the product requirements document from the beginning.
1. Part 1
When discussing such seemingly very basic issues, product managers are accustomed to dismantling the problem and defining the nouns. Often, the question arises from the unreasonable question.
So first of all what exactly is the Axure prototype we are talking about. Axure is just a tool after all, and it will make different tricks in the hands of different people, so first of all I have to say that Axure prototype ≠ product prototype.
So what is a product prototype? There are two definitions below: