post

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Guest Post

Creating metrics that matter

A case study: Launching a product process in a project-based company

B2B product management

Artificial Intelligence (AI) & Machine Learning (ML)

Building Product Teams

Business Strategy

Data Driven Product Management

Digital Transformation

Diversity and Inclusion

Minimum Viable Product

OKRs

Prioritisation

Product Design

Product Research

Product Development Process

Product Ethics

Product Discovery

Product Leadership

Product Management Career

Product Strategy

Stakeholder Management

🌎 <a href="https://www.mindtheproduct.com/world-product-day/" style="color:#FFFFFF;text-decoration:underline;">Happy World Product Day!</a> Be sure to celebrate product, yourself, and your peers today! 🎉

How much are product managers getting paid in 2024?

Leading product ops at Delivery Hero with Koen Dubelaar

Connecting fans to creators at Spotify (Dariusz Dziuk, Product Lead, Spotify)

“You’re not as competent as you think” 5 lessons from Ken Chin on navigating a product career (CPO, Spark Networks)

Everything wrong with the product management job market. And how to fix it

Data-driven Product Manager with an entrepreneurial background and a bias for action. Team player with a passion for collaborative design, ideation, and good user experience. Consistent track record of driving user and revenue growth through experimentation.

Bartosz Mozyrko

One of the most important responsibilities of a product manager is planning the order of features that the dev team should work on.
This need to prioritise comes from a very basic constraint &#8211; a lack of resource. In a fast-moving business environment &#8211; and especially in a start-up &#8211; product changes should deliver the most value at each point in time.
<a href="http://foldingburritos.com/product-prioritization-techniques/">There are many ways to approach feature prioritisation</a>, but one that has worked well for me is the Grounded Theory (GT) approach. I first came across GT when I worked as researcher for a UX consultancy. It’s a bottom-up approach which I’ve found useful in a variety of projects, and I have endorsed it as plain common sense ever since.
Hopefully, this simple way of structuring data into information will help you to make better decisions about what to work on and to defend those decisions to others.
<h2>What is Grounded Theory?</h2>
Grounded Theory is a qualitative research approach that was originally developed by two sociologists, <a href="https://www.amazon.com/Discovery-Grounded-Theory-Strategies-Qualitative/dp/0202302601">Glaser and Strauss, in the 1960s</a>.
The purpose of Grounded Theory is to generate theory from empirical material. For example, if an apple hits my head 20 times, I generate a theory on gravity. Patterns and categories emerge out of the data rather than being imposed before data collection (I suspect that gravity exists, so I look for case studies supporting that belief). The theory needs to be grounded in observation, hence the term.
In a way, the Grounded Theory method resembles what many researchers do when they retrospectively formulate new hypotheses to fit data.
<h2>All is data</h2>
“All is data” is a fundamental property of GT. It means that everything that comes the researcher&#8217;s way when studying a certain area is data. With regard to product management, the data can arrive in both structured and unstructured ways.
Structured:
<ul>
<li>Questions from users who responded to your automated emails</li>
<li>Tickets from customer support team (revealed pain points)</li>
<li>CRM software (notes, deals, email history)</li>
<li>Customer advisory board (virtually or in person)</li>
</ul>
Unstructured:
<ul>
<li>Feedback from prospective customers during sales demos</li>
<li>Information from your sales team (reasons for lost deals)</li>
<li>Informal talks with customers (i.e. during conferences)</li>
<li>Direct feedback from users (i.e during WebEx sessions)</li>
</ul>
The goal is to collect user feedback from as many touch points as possible. The more data points you collect, the better the understanding you will have of your target group’s needs and pains. And as the size of feedback pool increases, the more reliable the execution of future ideas will be.
<h2>Quantity first</h2>
When building products, we are driven by two thought processes: divergence and convergence.
Divergence focuses on exploring possibilities to create a new understanding of a problem space. It is very much what most people think about when they consider creativity.
Divergence is about creating choices, no matter how good or bad they are. This phase can be tedious as it involves drafting categories or concepts from all the data sources we can get our hands on. In product management, this means that you&#8217;ve created a list of things to work on, but without assigned priorities.
When you have collected a big pile of categories, the next stage is to slim down the list into a smaller set of ideas that can be taken forward for further development. This stage is convergence and requires an objective evaluation of your choices. It’s about evaluating ideas with a given set of criteria, deciding what the “right” choices are (and executing those choices later on). Convergence is about making decisions.
Although there are many prioritisation criteria that can be applied at this stage (value, cost, etc.), the GT approach uses a basic metric: feedback count. It&#8217;s a no-brainer, really.
<h2>How does this help in feature prioritisation?</h2>
GT is geared towards getting input from the outside world. Product managers can use this qualitative approach to create a list of features, fixes and enhancements that relate to what users want &#8211; the more the merrier. Each new request expands the list.
When you feel your list is saturated, you should set default priorities for each request by assigning how many times it has been reported. It’s the quantitative side of the process that determines how many users would benefit from introducing each product improvement. This part can be automated by a simple SUM function in an Excel document. Each repeated request will stack up, adding weight to its priority.
Here’s an example:
<a href="https://www.mindtheproduct.com/wp-content/uploads/2016/09/Product-feature-prioritization-example-spreadsheet.png"><img loading="lazy" decoding="async" class="alignnone wp-image-9227" src="https://www.mindtheproduct.com/wp-content/uploads/2016/09/Product-feature-prioritization-example-spreadsheet-1024x421.png" alt="product-feature-prioritization-example-spreadsheet" width="600" height="247" srcset="https://www.mindtheproduct.com/wp-content/uploads/2016/09/Product-feature-prioritization-example-spreadsheet-1024x421.png 1024w, https://www.mindtheproduct.com/wp-content/uploads/2016/09/Product-feature-prioritization-example-spreadsheet-300x123.png 300w, https://www.mindtheproduct.com/wp-content/uploads/2016/09/Product-feature-prioritization-example-spreadsheet-768x316.png 768w, https://www.mindtheproduct.com/wp-content/uploads/2016/09/Product-feature-prioritization-example-spreadsheet.png 1058w" sizes="(max-width: 600px) 100vw, 600px" /></a>
In this example, the divergence stage is reflected by the features &#8211; the columns, and the convergence stage &#8211; feedback count.
<a href="https://docs.google.com/spreadsheets/d/1Mkqm4NIjrwP-UhjdNih0e9gQKLd6WwnMcFVz_-PPzEc/edit?usp=sharing">Feel free to duplicate the spreadsheet for your own use</a>.
Once the list is completed it’s a good idea to discuss it with your team. I strongly recommend the inclusion of more criteria before making final decisions, like cost of implementation (effort) or return of investment (impact). Your feature prioritisation should also follow and be narrowed down by your overall product strategy (i.e. target group).
The Grounded Theory approach is a set of simple guidelines for structuring feedback (external and internal) which should result in helping you to set product feature priorities. It’s important to bear in mind that it does not go against any existing methodologies, rather it aims to support them in your decision-making processes. For instance, lean start-up advocates believe that customer feedback is integral to product development and ensures that the producer does not invest time in designing features or services that consumers do not want.
GT approach helps synthesise which (new) features are aligned with people’s needs and pains, making it easy to communicate how many of them will benefit from each improvement. It can be also useful when estimating return on investment (ROI) from product changes. For instance, if your sales team reports 10 lost enterprise deals each month due to the absence of a feature, you can help them by introducing this feature. Before that, you can project the ROI based on the cost of implementation and improved sales conversion metric.
At the early stages of a start-up, you probably will be able to collect feedback only from people who haven’t had an opportunity to touch your product, as it may not yet exist. Working with an existing client base is different because you can assign more “weight” to the feedback and trust it more. Quality of feedback is very important.
There are no hard rules on when you should stop collecting the data. It usually boils down to the timelines and benefit-cost ratios. From my experience, collecting feedback from at least 15 clients (direct talks) provides enough data to feel confident on the decisions you make. You need a bigger sample when talking with people who didn’t pay for your product: users.
Ideally, you never stop collecting data, as each data point can provide new product feature ideas or support existing ones.
<h2>All in all</h2>
Managing a product roadmap or coming up with feature priorities is not an easy task.
As a product manager you need to make things happen. In order for a product to be shipped there are hundreds of things to get done.
I know that for some readers this may appear to be a formalised version of their &#8220;common sense&#8221; approach, but I have always found this simple framework to be very helpful as it can provide more clarity about the need to introduce product changes.
It would be great if you could share it with any friends and colleagues whom you think might also appreciate it.
What’s your favourite approach or mix?
Please let me know in the comments below.
P.S. The article covers very basic information on Grounded Theory, but if you are interested in further exploring the topic in regards to product management, I recommend that you to read:
<ul>
<li><a href="https://www.doria.fi/bitstream/handle/10024/90809/isbn9789522654045.pdf">Overcoming the complexity of software product management</a></li>
</ul>
<ul>
<li><a href="http://kczxsp.hnu.edu.cn/upload/20141016160342563.pdf">Using a grounded theory approach for exploring software product management challenges</a></li>
</ul>
&nbsp;
 
&nbsp;
&nbsp;

core/freeform

How to lead data-centric product teams: Jon Mora (Chief AI Officer, Zefr)

How to be a better data-driven product manager

User insights for product decisions by Cris Valerio

Data scaling for startups by Crystal Widjaja

Make Better Product Decisions by Using Quantitative and Qualitative Data, by Brian Tran

Using Grounded Theory to prioritise product features

Bartosz Mozyrko

Read more

Comments