Develop the Right products for your Portfolio

As we have said in previous articles, having the right mix of products in your portfolio is important. The most important factor to assess the health of your products is the value they provide to the users and how effectively they solve a problem. The value that customers perceive is different from what we think as Product managers in a corporation. This article is about analyzing this important phase which is product requirements, marketing requirements.

MRD and PRD

When we are about to solve a problem and build a product we start by forming the market requirements document (MRD). Then we are in the problem phase. What we speak about there is the Market needs and Market requirements and our goal is to identify, document, and communicate market problems, and customer needs. When we speak about the solution space though, we have an engineering focus and we are speaking about product feature and product requirement document (PRD), and items for the backlog. What we need to specify is what is necessary for product to deliver benefit to the user. Not “how to” implementation details.

Gather robust requirements

This is all about your customers. What are their needs, their unique story, and what problems they have in their life? These are the personas – which is a representation of a group of customers with common behaviors. What is the customer journey – the key customer touchpoints with your company, brand, product. What is the problem scenarios – context of the problem they face or the needs they have? What are the market needs – what outcome is the customer trying to achieve?

What exactly Personas are

When we do market research we gather data. But this process doesn’t have a human face, that’s why we use personas. Personas are the composite profiles of actual personas in the segment, distinguished by their goals. These people can have different roles as user, buyer, influencer. We should know their background, attitudes, behavior, including buyer behavior and insights.

A persona can be anybody that is possible to use your products, even inside your company. If you are a Product Manager in B2B space your persona can the Marketing director. It is the user that directly interacts with your product. It can be the financial decision-maker or buyers, or the technical decision-makers, like C-level executives, IT staff, engineers, or Influencers like Press, analysts, internal staff. Personas are needed to define requirements and create marketing messages.

Below is a simple Persona:

Meet Tom

Role: Tom is a Business Analyst in the Financial Industry.

Goals: Tom wants to find a more effective way to create financial reports.

Attitudes: Tom has been attending for the last 2 months programming classes to learn how to program. He wishes to find some automated solution to create these reports.

Background: Tom has graduated from California University department of accounting

Behavior: Tom is usually stressed more than usual when he doesn’t finish his job on time because these reports take time.

A thing to remember is that this persona will define the design of your final product. That’s why the persona should be very detailed to avoid examples like the below:

A grandma and a millennial both need mobile phones nowadays, but an Apple iPhone will be more difficult for the grandma to use it. She will need a simple mobile phone with big buttons. It can be an Apple brand but just a different design from the well-known devices.

Customer journey

Gathering requirements from these personas can be challenging sometimes. To make them articulate better what they need you can use the customer journey tool. How they interact with your product, brand, or  Just illustrate how your persona is interacting with your products.  In this way, you can find holes in your interaction with your customers.

There are certain questions that you can ask your users. The key here is to not ask what the user will do but how he interacts with the product. What are the key touchpoints of interaction? What is the level of importance? What are their thoughts and feelings at those points? What are the goals of each touchpoint? What questions are the customers answering? What is the length of interaction?

Below you will see Tom’s customer journey after started using the reports software that our company selled to him:

If you start from the point of your customer’s feeling, and emotions then it is better.

Problem scenario at User Journey:

This is a frictions point at some point in the persona journey. This describes how and when the problem occurs and the user’s overall goal during that point. What is the primary goal, what is the background, frequency, trigger, description?

A lot of people mix use cases with problem scenarios. Use case is different than the problem scenario. Use case mixes problem and solution spaces. Usually, it is called a problem statement, but a good elaboration of the problem goes beyond a just statement of the problem. You tell the whole story behind it. In this way you let the developers understand what is the real problem.

Until now we have analyzed the who and why of market needs because we analyze the market. Now if we go to how and what we speak about the solution space. Now we start speaking about the product requirements. In Agile we don’t have a certain format and we use user stories for that.

PRD document or product description

The management requires from the product manager a plan on how to start building the product. This is the PRD document and here are the details that you should include in this document:

Context

Capture engineering response to market needs

Needed for positioning, 4P’s, and messaging

Scopes the release

Milestones esp. beta and launch

Assists in defining roadmap

Product Description Doc

Features

Functional

Security

Usability

Internationalization-support

Documentation

Distribution, packaging

Legal, regulatory, and compliance

Miscellaneous

Compatibility

Performance

Operational

Architectural vision

High level scope

Resources

Tools

Expected release date and milestones

How requirements should look like

“Product MUST be able to perform (function)

And the PM is responsible to prioritize into a roadmap

Then we prioritize the statements into priorities (high, medium, and low) (make some excel file..)

Prioritizing the product requirements

Well, you have gathered all the requirements, you think that you know by heart your customer needs and now what? Do you think you can start building? No, because we don’t have unlimited resources and the most important – time.  This is why you are an effective Product Manager, to manage the limited resources. In prioritizing you should start from an MVP thinking – what is this that it can maximize the value delivered to the customer? Maximize profit to the company? Beat the competition? Support strategy?

Usually you can use tools like the prioritization Matrix below:

Prioritize according to the value

The below diagram shows how you can prioritize according to value and cost for development. According to the quadrants below, place each feature in one of the quadrants according to customer value and engineering cost/risk

With this graph, you can easily find the low hanging fruits –  what customers value, or what your company finds more profitable to build for now.

Kano Model

Because everything in requirements prioritization is being done to provide value to your customers, is good to visually see the value that you add to your product with each requirement. Kano model does exactly that, you add features to an x and y-axis and say which of them are delighters, they add to performance or are must-haves. An example is a mobile phone. A must-have is the ability to call.  For performance, we can add the stronger CPU and as a delighter, we can add the edged screen as it is a feature that Samsung wowed their customers a couple of years ago with the Samsung edge series.

As a PM is your responsibility to follow the trends about the delighter features, because now they might not be that important but soon your product can be disrupted without them!

Leave a Comment

Your email address will not be published. Required fields are marked *