Operational "Demand Template"

All along, product personnel and operators seem to be dead rivals. Products always feel that the operation of how to think of a is a, no logic, disorderly mention of demand, volatile; operations also feel that the product is always not to force, do not understand the pressure of the KPI, do not help to achieve such a simple function ...

In fact, recently I encountered such a problem, so, with the operation of the discussion, developed a "demand template" to help everyone swords. I think one of the big sources of conflict is that the demand for operations is often the "solution" (or more professional, we call the product function)--to change the structure of the page, to add a few buttons God horse, at this time, the product will be very depressed-then I do, you directly to find development. What the product wants to know is that the problem behind the solution (or more professional, we call it user requirements). Then, the product to do the user needs into the product features of the matter, this is the Product manager's core responsibilities (rather than the refinement of the function of this thing, yes, I mean to write PRD or something).

So, I give the template, to be able to say a few things clearly:

Target users: This matter, for whom to do, once the operation began to think from here, you can rule out a lot of demand;

Problem Description: Target users encounter pain point, just say "when/where, how uncomfortable" can;

Severity: a judgment of the severity of the problem, "high/medium/Low" can, the specific method of judgment, according to the user's importance (this more subjective, need to discuss the team to reach a consensus, our products are for which categories of users service, their priority ranking is what, this is the key content of product principles), The number of problems appearing, frequency and other factors (relatively objective, better to do) consider;

Existing scenario: How to solve the problem now, I would argue that a problem that deserves to be solved is usually solved by someone, so there must be some solutions, and there are no problems with existing solutions, usually not serious;

Suggested proposal: The proposed product improvement, this is actually borrows the operation the brain to help ponder, the product does not necessarily adopt;

Value Description: Improve the additional value of the program, such as: Save time, can more accurately find so-and-so ...

Cost of improvement: The cost assessment of the proposed scheme, "High/Medium/Low", the same, for reference only.

Products to get a bunch of such requirements, in terms of price/performance as the main reference factor, decide what to do next. Finally, an idealized formula

Price/performance = severity/improvement cost, problem (user requirement) determines severity, solution (product function) determines cost of improvement.