Defining Problems, Building Requirements
After research, the next step in the 9II9 product lifecycle is Define. Defining the problem is a critical part of the role of a Product Manager, but unless the solution can be defined as a set of unambiguous requirements, the Product Manager is just another person with ideas. Knowing what to build and why you should be building it is one of the core aspects of product management.
Product Managers should write just enough documentation to enable knowledge transfer between business stakeholders, development teams, and end-users. Most requirements originate from a user need and evolve to become specific features on a roadmap.
The initial input into a new requirement can be a user need or market problem. A common problem or need that is experienced by a large number of users can be elevated and defined as a potential product feature.
As an example, a Product Manager may interview existing paying subscribers to an online news portal and discover a pattern of users complaining about being blocked from accessing content on the website due to lack of payment. Upon probing further, it is discovered that users must submit payments offline every three months, and they simply forget to pay the quarterly subscription fee. This problem is then encapsulated in a single Product Feature, which is recurring billing. The next level of detail is specifying the feature as a Software Requirement, such as give users the ability to pay for subscriptions online, so that their access to content on a news website does not get interrupted unexpectedly. That requirement ultimately gets prioritized and assigned to a development sprint and is packaged and released to users in a software build.
In a media organization, approaches to capturing and documenting requirements can vary greatly. Some organizations can spend months developing and releasing documents while others are able to operate more like a tech company, opting for user stories over narrative documents. A hybrid approach is the most effective, where the product brief is a simple, one or two-page document that sets the vision and strategy for the product, combined with an Agile user stories template.
The level of documentation that is required when defining requirements for a new product depends largely on whether an organization has in-house or outsourced design & development resources. Internal teams are able to have continuous conversations and explorations that result in notes added to user stories. If the Product Manager is working with an outsourced vendor, being as prescriptive as possible is useful in order to manage the risks and eliminate ambiguity.
This is especially useful when dealing with outsourced development agencies. Although there are many digital agencies around the world who genuinely want to do their best work for the clients they are contracted to serve, but sometimes what’s best for the vendor doesn’t necessarily align with what’s best for a media organization’s budget and priorities. Defining and prioritizing features, and managing the execution and scope of those features is a process that should be actively managed, regardless of whether the execution is done by internal or outsourced resources.
Product Managers need to be in tune with the development cycles and be able to jump in and make a call to dial down the scope of a specific feature that may be eating into valuable development time that could be best utilized elsewhere.
Validating Product Requirements
Product requirements can be validated in several ways. The most important validation is through internal stakeholder reviews of the requirements. These meetings serve as part of the Product Manager’s continuous role of championing and communicating the vision and strategy for the product.
In these reviews, you are bringing together content, engineering, and design teams as a group or as one-on-one sessions to go through the problems and approaches to the solution. The Product Manager needs to be able to speak to stakeholders in their own language.