background

As the business grows, the organization expands from one primary product in the start-up phase to multiple products. From the point of view of product technology, the shared technology department will be gradually abstracted, and then developed into technology center and business center. As product lines expand, product requirements management (with collaboration and resource scheduling behind it) becomes more and more complex. If not properly handled, collaboration difficulties and low efficiency will occur, which cannot support service development. This paper introduces the demand management practice of Youzan from single product to multiple product lines, and the product technical team from a hundred to a thousand people.

Relationship between organizational goals and product requirements backlog

A successful business organization is not necessarily one that has a lot of resources, but one that uses them in the right places. Above one dimension there are two dimensions, above the system there are systems, and only in higher dimensions can we see the whole picture of the low-dimensional system. Look at technology from product, product from business, business from industry. Product demand, from the source, carries the strategic goals of an organization and the demands of customers.

Youzan uses OKR to manage strategic goals. We often say that no silicon steps can travel thousands of miles. O is the goal thousands of miles away, which is the compass. The requirements to-do list derived from OKR is the silicon step that has taken us thousands of miles. Business organizations with products and services as carriers, no matter how ambitious the goal, is finally implemented on the requirements. Product requirements are selected based on the organization’s goals and aligned with this source, that is, with the OKR, to avoid wasted resources and opportunities.

Requirement backlog generation and update: input from multiple parties, decision made by product owner

Product requirements come from a strategic perspective. From the perspective of “people” from internal and external customers, stakeholders, specifically external users, customers, partners, etc., internal decision makers, products, operations, services, etc.

If upstream stakeholder expectations are not managed effectively, the following negative feedback can result. Decision maker: my X demand is very important, why has it been so long? Customer service: when can the thorny Y problem that the customer cares about be solved? Information asymmetry, will fall into chaos.

Requirements come from many sources, but the only owner responsible for the Product requirement to-do list is the Product owner (PO). On the input side, ensure that both internal and external stakeholders’ messages are heard. But at the decision-making stage, it can’t be a multi-party decision. Can absorb a wide range of opinions, but relying on voting or balancing to make decisions is usually due to a lack of directional knowledge and commitment). PO should fully collect appeals from all parties, but should not be led by any one party. PO should have its own Vision of products, independent thinking and judgment. A symphony is performed by a group, but not written by a group. As a product owner, he/she needs to be in charge of his/her position and reflect the product vision and realization path with the product requirements to-do list, which is an unshirkable responsibility.

A major problem and challenge for most organizations is how to integrate many disparate pieces of information. The requirements to-do list is a collection of information. Once the requirements backlog is confirmed, it can be synchronized to decision makers, operations, service roles, and so on. They care about things that can have a deterministic conclusion and feedback. Incorporate planning requirements that can have an expected time and pace; Those that are not included can also be clearly informed so that they can adjust their strategy.

Prioritization strategy for requirements

Whether it is PMP, Agile or lean, there is an assumption behind it that time, resources, human intelligence and creativity are scarce and need to be used effectively. Limited resources and unlimited demand, is a pair of contradictions, we need to combine user value, business value and cost input to do a comprehensive consideration.

There are many tools available for prioritizing requirements, such as user Story Map, Impact Map, MoSCoW, etc. There are a lot of public information available, so I won’t go into details. For example, a user story map used by likes (grey cards are lower priority requirements) :

The thing that needs to be particularly focused here, the requirements backlog, needs to have the idea of more with less, because the essence of strategy is focus. It’s easy to have a long list of requirements, but it can be challenging to focus on the most valuable requirements.

The requirements backlog itself can be updated at any time, but the requirements for the next iteration or development cycle need to be deterministic. Scrum is about time boxes, KanBan limits WIP, and finding a balance between long-term uncertainty and short-term certainty. The requirement list of the next r&d cycle (monthly planning – weekly iteration – daily station meeting) is determined in the way of fixed cycle in Praise.

It is important to note that requirements planning should be incremental and detailed, rather than pursuing long and detailed requirements planning, which can be dangerous. In the fast-changing era of VUCA, iterations are needed to balance long-term vision with detailed action plans.

A backlog of requirements for products of different sizes

To-do list of requirements for a single small-scale product

A single product, with a small team size, has a unique backlog of requirements that are prioritized from top to bottom. For example, Youzan in the early days, mainly wechat mall SaaS products:

Demand management for a single large-scale product

As more and more user scenarios are covered by product functions and the size of the team is increasing, it is difficult to manage requirements, prioritize and plan resources in a to-do list. The strategy at this time is to divide the product backlog into multiple parts based on the characteristics of the business and product domain. Be careful not to divide the to-do list by functional team (e.g., one for front end, one for back end, and one for testing).

For example, retail business and team size are getting bigger and bigger, divided into two levels:

Multiple large-scale product + business demand management

When the organization has more and more business lines and product lines, there will be more and more strong demands. It is necessary to build public business and technical support capacity to avoid repeating the wheel. Especially, these basic support capacity is the basis for establishing ecological environment outside, so the middle Taiwan business line comes into being. For example, in Youzan, from the beginning of the wechat mall SaaS business, the development of retail chains, assets, beauty industry, education, and the external provision of PaaS ability youzan cloud, etc., all need the support of Taiwan. The emergence of Taiwan, for business is a double-edged sword. On the one hand, the middle platform can provide a lot of basic support capabilities, when a new business, or the use of other business has precipitated the ability, can be quickly reusable; On the other hand, it will also cause many businesses to rely on the Central platform, which will form problems such as complex collaboration and asymmetric information. The central platform needs to make choices, which will form a bottleneck. In a good practice, each upper tier product has its own requirements backlog, and the middle tier builds its own product requirements backlog. Multiple business/product teams bring their own needs to the center, and the center ranks them based on their own building plans and the value priorities of other businesses. Prioritize and schedule the demand to-do list of Central Taiwan based on customer demands, business strategy planning and construction planning of central Taiwan.

The impact of organizational form on requirements management strategy

Many organizations adopt a functional organizational structure. For example, product and technology are divided into different teams, and technology is divided into different teams according to front-end, back-end and mobile. At the requirements level, however, you need to always keep a user perspective and not prematurely disassemble requirements from a functional perspective. If you have to make a trade-off, it’s better to keep this requirement granular than to let the fragmentation of the customer perspective drown out the technical perspective tasks of a multi-functional team (front-end, back-end, mobile, etc.). Such customer-oriented and strategic objective-oriented requirements to-do list is conducive to the evolution of the organizational form from deep well to Feature Team.

A hosting tool for the requirements backlog

A gentleman is good at faking things. To improve organizational effectiveness, we should not just talk about the way, but put our ideas into practice. The sun rises every day and we cooperate every day. Talk never mistakes company, but stop talking mistakes company. The strategy design mentioned in the previous article is basically implemented in the product performance platform to support the effective implementation of demand-related concepts at the operational level.

For example, in addition to establishing a unique product to-do list for each product line, to-do lists will also interact with each other based on the associated relationship between requirements, facilitating collaboration. For example, the requirement card will indicate the scheduling of multiple team dependent requirements. As shown in the figure below, 3/3 means that the three product lines need to cooperate to complete the requirements, and the three parties have been included in their own demand to-do list. If 2/3 is displayed, the PO is alerted to which team has not yet included the requirement on the to-do list.

Different roles such as product, technology, service operation, market and manager will have different demands from different perspectives. We configure information from different perspectives based on the same set of requirements to-do list kanban. For example, from the perspective of service operation market and other business aspects, we hope to see the launch time of various demands, so we will configure the “launch calendar” module for easy viewing.

Use electronic kanban to visualize the whole process of requirements flow. The related process nodes will have time and status records, and can freely generate various reports. Stakeholders of different roles can see the data reports of the dimensions they care about and view the throughput, cycle, and so on of the requirements backlog for decision making or adjustment and improvement.

Afterword.

Since I started to design and implement the overall demand management strategy, the overall strategy and framework have not changed much in more than two years. However, the large demand management framework can only guarantee an overall operation system, and many specific problems still need to be solved in the process. At each stage, the team addressed one or two core process hurdles and issues, but there was still room for improvement in requirements granularity, value loop, and so on. Above summary, for your reference, welcome to exchange.

Welcome to pay attention to the “Favorcoder” public account!