Considerations for Creating Product Requirements

A new colleague of mine was asking what needs to be done with one of the features assigned to him. He had already completed a few features and it dawned on me that as he is new to product management we have never discussed how to come up with product requirements as part of product management process.

As creating product requirements is a crucial step in the product management responsibilities I thought that others will benefit if I will down the gist of our discussion.

Understand the Idea / Problem

Clearly articulate what is it that you aim to solve. This could be a customer pain point, a market opportunity, or an internal business need. The sourcing of these should be as wide spread as possible - customers, sales, development, QA, etc. The wider feedback coverage for ideas the better outcome. The main responsibility of the product managers is to prioritise these ideas quickly for further investigation. Not all ideas are equal and product managers don’t always have bandwidth to investigate everything so it’s important to prioritise and communicate the prioritisation to the idea creators clearly that their ideas have not been ignored but they may have been cancelled / put on hold due to other higher priorities.

Conduct the initial prioritisation based on urgency and impact. Urgency is is determined by how fast does this need to be acted upon. Addressing client escalations, problems, closing open opportunities as wins always has a greater urgency compared to expanding to new market areas. That is why we also look at the impact. Opening a whole new revenue stream has greater impact then closing a single open opportunity.

Note that there are also a wide spectrum of topics that defy the before mentioned prioritisation logic - usability improvements (unless you consider those as churn avoidance), new functionality which is more market insight/technology forecast driven (we as PLM know this is where market will head so having this now will give us competitive advantage but it’s not something we can put a price on).

You should allocate sufficient BW for these “run-of-the-mill” ideas, to avoid building technical debt un-intentionally.

Conduct Market Research

if appropriate

It’s not always needed to do market research at feature level, but it helps to keep up to date market analysis data set so you can easily quantify new ideas. Also having access to existing client data with detailed analysis what they have bought, what they use it for helps prioritise internal improvement ideas for efficiency and user friendliness for example.

Gather insights into your market, buying behaviours, market trends, use cases, revenue for the before mentioned.

Read more

Conduct Competitive Analysis

if appropriate

Analyze your competitors' products and offerings to identify strengths, weaknesses, and potential opportunities. The goal here is to find what is your unique angle to the market i.e. your USP or key differentiator. Also it serves as a reality check of is this a market that you want to go after, would you get a better ROI going after some other market or is this something you have to address to ensure that your entire business will remain viable from competitive threats.

Define the Solution

Outline the core functionality and features that will be need to address the identified idea. This 30 000ft view is required for the next step so that you are able to hold meaningful discussions with the various stakeholders about prices, revenues, costs. You should adopt as simplistic approaches to this as possible as the initial discussions in my experience will in variably force you to adapt your approach. So move fast and iterate is best guidance here.

Build the Business Case

if new Product or Major feature

Collaborate with stakeholders to gather needed revenues and costs. This is the right time to solicit input from development about the development cost, operations about the delivery cost and capability, sales about the price points and revenue potentials.

This should be well documented and aligned with all stakeholders as this forms the commitment from everybody to take this product/feature/functionality forward and should be reflected in respective OKRs and KPIs and thus tracked and rewarded against.

Read more

Create User Stories

If it fits into you way of working

Personally I have never understood the value of user stories, but they seem to be all the vogue. My perception of this is useful when the product management responsibilities are divided between multiple roles.

• User-Centric Approach: Write user stories from the perspective of the end-users, describing their needs and desired outcomes.
• Prioritise User Stories: Rank user stories based on their importance and impact on the product's overall value.

The goal of these is to simply the writing of the actual concrete requirements. For example - User A will want to be able to start the simulation process easily. This could translate into a product requirement of

1. Product A must support a button for starting the process
2. Before mentioned button must be be green
3. Before mentioned button must be labeled Start process

Remember that (at least in my opinion) requirements are the way for the product management clearly document what what they expect the product to do and thus translate effortlessly to User Acceptance Tests:

1. Is there a button on the product? Yes/No
2. Is the button green? Yes/No
3. Has the button been labeled Start process? Yes/No

Develop Requirements

Functional Requirements: Specify the exact behaviors and functions the product must perform. It is also important to specify what behaviour and functions you do NOT want the product to have.

Non-Functional Requirements: document the quality attributes such as performance, security, usability, and scalability.

Technical Requirements: Detail the technical specifications, such as hardware, software, and infrastructure requirements.

Read more about requirements writing here

Re-prioritise Ideas

During the idea to requirements phase you have learnt much about the cost of development, market opportunity, customer open opportunity status and close date, so it is worth having regular re-prioritisation effort done before moving your requirements in to development backlog to avoid working on stale ideas.

Iterate and Refine

Many of the steps here are not steps at all but more of a parallel interconnected streams where a change in one has ripple effects across everything. So ensure that you have build a robust framework that allows you to adjust any of the plethora of parameters (salary per resource type, win ratio, average price, feature development duration, GTM motion cost, etc etc) by having a formula driven approach where assumptions and key drivers are clearly captured and highlighted where they are used.