Key Challenges in Product Management - Part 1

In Information Technology, Product Management is a relatively new discipline unlike Project Management which has been around for more than three decades. It entails the creation of a Product that is valuable and usable through a Product Vision and Strategy. It includes idea management, road mapping, prioritizing, developing, releasing, experimenting and analyzing among others. It also spans across many functions such as design, engineering, sales, marketing, customer success and more. In this article, I cover some of the phases in the Product Development Life Cycle and the key challenges that Product Leaders face during such times.

 

1)    Identifying Suitable Backlog Items - Ideas, feature requests, functionality needs and others fly in from all directions to build up your Backlog Items. While we cannot stop the flow of it, we can ensure we receive quality inputs by steering the thoughts of individuals towards our goals and objectives. Keeping a narrow focus on the most important problem the Product is intended to solve and how the Customer will interact with it as a whole is essential. Else, we will no longer see the forest for the trees. Backlogs should have the right blend of items that enhance capability and those that improve usability. The Product Lead should review each of the suggestions against the following:

a) being a right fit to the Product Vision

b) providing a sound reason for its inclusion

c) ensuring a similar request is not already present but pending implementation

d) suggesting an alternate way of performing a task if it already exists but the Stakeholder is unaware of it

e) including a part of it if not the whole in one of the Backlog Items that is due for implementation

f) considering it in the distant future as it is not so important at the moment

Product Management is often a zero-sum game where adding X to the Product Backlog could come at the expense of Y given our finite resource availability. Hence, setting parameters to identifying the right ones is important.

After identifying suitable Backlog Items, we define the granularity of it depending on how far in the future we intend to execute it.

 

2)    Prioritizing the Product Backlog – After filtering all the ideas, features request etc. and shortlisting Backlog Items, the next challenge lies in prioritizing them. Rather than going by their gut feeling, Product Leads should consider the use of a simple Scorecard. The first step towards creating one would be to place each of these request into one of the below categories: 

a) identified as a high dollar value item to the Business

b) solves a problem for the Customer

c) improves usability

 d) is high on the Customer’s wish list

e) is needed to integrate a cutting edge technology

f) is essential to keep up and/or get ahead of your Competitors  

g) increases sales of the Product (i.e. Customer Acquisition)

h) improves Customer Engagement

i) required for Customer Retention (i.e. reduce churn)

j) improves operational efficiency (i.e. integrate with other internal systems)

k) required by the PR/ Marketing team

l) improves security of their product

In agreement with your key stakeholders, assign value points to each of the above categories and then place Backlog Items in them. A common pitfall is not identifying dependencies between Backlog Items and sequencing them in a logically fashion. Also, when these Backlog Items are split into Sprint Cycles, it is important to make each release build upon the previous one. How they are sub sequentially converted into rightly sized independent User Stories that are estimable is detailed in my article Agile Scrum Methodology on Steroids.

 

3)    Your Product Roadmap – A general misunderstanding is to think of it as a Gantt Chart which we typically use in Project Management. It is a document that states the Product Vision and outlines the high level initiatives to get there. It communicates the strategy that we would put to use to achieve key deliverables. It should neither be a bucket list of features failing to communicate value nor should it be too detailed failing to highlight strategy.

There are a couple of precautions that most Product Leads take while creating one and that is to provide estimated delivery dates for only the major milestones as there is a high chance that the road map can be overrun by bugs, new feature requests and the ever growing technical debt and hence, one should buffer in some extra time for uncertainties.

Since the Backlog Items to be delivered in the future are not accurately defined but roughly estimated, any determination of effort and costs should be done top-down rather than bottom up.

 At the very least, what key stakeholders wish to see delivered first is the core functionality of the product for the problem it is intended to solve along with any other high value items. Most importantly, they expect to see some sort of date based commitment that can be tracked.

 

4)    Capability and Usability – Cluttering the User Experience with a plethora of features and functionalities can confuse the Customer and lead to the abandonment of the Product. When a Product has a large set of capabilities, it suffers from feature bloat. With this in mind, designs need to be reviewed over and over again, a fresh perspective taken from time to time and effort placed towards removing unwanted complexities. If one still has a large set of features and functionalities that they wish to integrate, then segmentation of the Product is something one can considered.

From a usability perspective, one of the questions to be asked is whether our Product as a perfect solution correlates to a simple and effective one? Customers do not wish to put much thought into identifying the functionality of a Product and neither do they wish to perform several steps to complete a task as it slows them down. Hence, we must ensure they use the core functionality in the shortest possible time and in the simplest way. Additionally, should we have both a physical and digital product, we have to ensure a marked similarity between their interfaces. Truth be told, Customers evaluate the capability of a product during the purchase phase and focus more on usability after that.

 

5)    Assuring Quality in a Product Release - A Product Lead needs to constantly and consistently check the Quality of their Product and hence, below are a few pertinent measures s/he can gauge them against:

a) user stories are written in small consumable chunks with a well-defined acceptance criteria.

b) test driven development is undertaken where Developers and Testers work in conjunction at all times.

c) the mockup of the UX/UI Design matches its build in various forms (web, mobile, tablet etc.)

d) the functionality of all features match the front and back end requirements

e) the additions of new features and functionalities do not break existing ones

f) that the proposed feature/functionality was delivered as per the acceptance criteria

g) various performance criteria’s are met such as the page loading in the expected time with concurrent sessions running smoothly (i.e. it does not hang or crash) etc. and

h) overall, there are a bare minimum number of bugs reported.

Quality has to be built in into the Agile process where every member of the development team chips in to reduce testing overheads.

To build a valuable product, we need a first-hand understanding of what our Customers want and this can be achieved in a couple of ways:

1)      Running experiments and using analytical tool to obtain statistical data and

2)      Customer Research by interviewing and obtaining regular feedback from them

While the first helps us understand WHAT the Customer does and WHEN they do it, the second helps us ascertain WHY. In the following two points, I will throw some light on them:

 

6)    Analyzing Customer Behavior – Failure to develop a culture of experimentation where we perform various A/B tests to track Customer behavior is a mistake many still commit and this is primarily due to their lack of resources. Not only is the type of test important but also, the duration of it. There are online calculators that help determine the duration an A/B test should be run for a given volume of traffic to attain statistically significant results. At times, minor changes can help achieve significant results but what matters is whether its helps us achieve our intended goal.

A/B tests results along with analytical tools should be made available to most in the Organization so decisions can be made quantitatively. In general, the user of analytical tools to understand Customer behavior is best practice.

 

7)    Customer Feedback – After completing the Minimum Viable Product, it is in our best interest to bring the Customer into the feedback loop because if the core value of the product is flawed then nothing else matters. We need someone to validate or disapprove our ideas and assumptions. Ultimately, it is the Customer experience which determines the success of a product. 

A Customer’s feedback could surprisingly be a much simpler design but if it arrives late, then a lot of re-work could be needed to achieve what is suggested. To make things worse, when Customers question a design or feature or does not understand a functionality, teams tend to get defensive and assume the Customer is not smart enough to understand something which they feel is obvious. It must be noted that a Developer’s mindset is different from a beginner’s point of view. Speaking to Customers on an on-going basis helps a great deal to understand the challenges they face.

The above two points will help one abandon any pre-conceived Product and Customer notions. 

In Part 2, we will look at the role Agile plays in the product development life cycle, segmentation and personas, product pricing strategies and more.

About the author: 

 


0 Comments

Leave a Comment