You Are Doing Product Refinement Wrong And Here Is How To Improve It — Part 1

Avoid the trap of not refining roadmap elements, take advantage of the benefits and understand how you can refine them.

Imagine launching a product feature that has taken months to develop and realizing that it does not meet your users' needs: it is the right answer to the wrong question. This is a costly mistake that can often be avoided by effective product refinement.

Whether you come from an Agile workplace or not, you may have heard about Backlog Grooming, Product Refinement, Story Time, and more ways to call these sessions.  But if you don't get it right, you may be missing out on the benefits of refining your product requirements with your development team.

What Am I Doing Wrong?

Here are a few reasons why you (or someone else!) may be doing product refinement wrong:

‼️ Not involving the whole product team can be damaging because each member brings a unique perspective that can help uncover potential issues and opportunities for improvement. Also, most of the development efforts are go through multiple eyes: Design, Devs, QAs, etc. So keeping valuable information with separate team members can slowdown things and cause confusion later.

‼️ A lack of prioritization will leave behind work that really brings business value and impact on the product itself. Your product backlog can become cluttered with tasks of little value to the user. Imagine a music streaming service that ships UI improvements (not even 🐞) first, because those tasks were "refined," but loses customers in regions with poor internet connectivity, leading to bad reviews, user dissatisfaction and decline.

‼️ Ignoring technical debt is very common. But refining is a great opportunity to address this and improve the overall quality, performance, speed, robustness, updated framework, stable libraries, correct licensing, etc. of the product. It is not enough to just review new features.

‼️ Not breaking down the requirements into smaller action items can result in overly large or vague development elements that can lead to misunderstandings and delays.

‼️ Without clear acceptance criteria, it can be difficult for the team to understand when they have completed their work. Again, this will lead to misunderstandings and delays.

"Failing to break down requirements into manageable tasks and lacking clear acceptance criteria, will lead to misunderstandings and delays."

You may have identified with the lack of some of these aspects in your product team, and it's not your fault! Honestly, there is no official guide or framework on how to implement this.

If you search the internet or ask on ChatGPT, much of the information out there will tell you that this is not an official Scrum ceremony. Others will tell you that refining your work is a crucial aspect of Agile.

The predominant resources out there come from Atlassian and Scrum.org, and they recommend some sort of "guidance”. Yet seeing information like this makes me wonder, how accurate is this information and relevant to us?

Perhaps it's because this image is from 2015 and a lot could have changed in product management since then. But at first glance there are things that are not clear to me:

• There is no clear mention of the user who uses the product. ⁉️

• From this flowchart, the product manager or product owner can look like a waiter, who only takes requests from stakeholders. Where is the real research? What about the other sources? ⁉️

• At what point technical feasibility is considered? ⁉️

• Where is risk management? ⁉️

Frameworks are a great guide specially when you are new to the job. However, depending on the type of product and your industry, if you are too rigid with frameworks, chances are that the market will not make it easy for you.

Hypothetical (Real) Stakeholder Situation

Let’s follow the logic in this diagram with an example.

A stakeholder has recently become a big fan of using dark mode whenever he gets tired, so one day he came up with the idea to include dark mode in your product as well.

1. Is the why clear? → Yeah, the stakeholder wants dark mode because he believes that’s what user wants because he would like that, right? 😅

2. Is the what clear? → Sure, it is just toggling dark mode. Easy peasy. 💻

3. Contributes to the product vision? → And if not, how can you tell? Is there clarity at this point of the user needs? 👨🏼‍💼

4. Does it add value? → Value to the company, to the product, to the team or to the stakeholder? 🤔

5. Then, finally, add it to the product backlog, which means you need time to write your story requirement. 🕐

6. In the refinement, your developers tell you that this idea is not feasible. The way the code is configured is not customizable for that "specific idea", the work is done by the vendor that owns the CMS in which your product is integrated. Meaning there are two options, either try to come up with a custom solution that can affect all your customers or pay $$$ for this feature. 💥

Ouch! It has taken you two months or more to confirm all these checks just for one stakeholder's idea. Now, not only will you have to tell him it's not feasible, but at the same time two major customers abandoned your product complaining about the slowness of development to include more “attractive” features, offered by your competitors.

Doing Efficient Product Refinements Will Benefit Everyone

This is why I recommend doing backlog refinements effectively and often: 

→ Prioritizing tasks helps determine their order based on factors like value and urgency. ✅

→ Breaking down work into smaller chunks makes it more manageable. 🧩

→ Estimating effort aids in effective planning. ⏳

→ Removing obsolete items keeps our backlog focused. 🗑️

→ Identifying risks and blockers allows us to address potential issues. ⚠️

→ Improving team understanding ensures everyone is on the same page. 📚

→ Adjusting to change helps us stay aligned with project objectives. 🔄

→ Promotes a collaborative work environment. 👥

But What Should I Refine?

To answer this question, we need to understand first 👇

What Enters to a Product Backlog

Going back to the bizarre Scrum refinement flowchart above. Beyond stakeholders input, product backlogs can be nurtured and expanded from a diverse range of sources, ensuring a holistic approach to product development. For example:

• Gathering insights and requests from users identifies issues and possible improvements. 📊

• Analyzing market trends and competitors shapes product development strategies. 🔍

• Usability studies enhance product interface and interaction for users. 💡

• Technical improvements are crucial for product maintenance and scalability. 🔧

• Regulatory compliance changes necessitate timely updates to products. 📜

• Brainstorming and R&D activities fuel innovation within the product. 💭

• Internal team feedback offers invaluable insights from customer interactions. 🗣️

• Monitoring usage data highlights opportunities for product optimization. 📈

• Strategic company updates can lead to necessary product revisions or enhancements. 🌐

How would you name this image?

As you can see in the image, diverse sources ensure that the product portfolio is a living document or artifact, reflecting not only immediate needs, but also strategic direction, user preferences and market dynamics. Balancing input from all these areas helps a product team stay aligned with its users and ahead of the competition.

⭐️ Translating Requirements Into Actionable Items

1. Gathering Discoveries

   1. Start by aggregating all forms of feedback and insights, including user requests, competitor analysis, usability studies, and internal feedback.

   2. Ensure each piece of input is documented clearly within the product backlog, pointing out specific problems, opportunities, or ideas for improvement.

2. Evaluating/Analyzing

   1. A way to start is assessing each item's impact on the user experience, business goals, and product strategy to prioritize. Using frameworks like MoSCoW or ICE scoring may help.

   2. Perform a deep dive into high-priority items to understand their feasibility, potential ROI, and technical implications. This might involve more detailed market research, user personas study, or a SWOT analysis.

3. Refining Requirements

   1. Take the prioritized items and break them down into smaller, more manageable tasks, defining specific technical requirements.

   2. Ensure each smaller item is well-specified so that it's clear what success looks like. You can include specific goals, constraints, and any relevant design or technical guidelines.

4. Feedback Loops

   1. After you introduce these items in refinement meetings. Use the feedback from these sessions to adjust tasks as necessary. Ensure there is a clear channel for continuous feedback from the team throughout the development cycle.

   2. Incorporate feedback loops with end-users also, especially for features identified via usability studies or direct user requests. Prototypes or MVPs can serve for this purpose too.

   3. Post-implementation, gather feedback from all stakeholders and users to review the impact of the changes. Use this feedback to adjust future backlog priorities and review this in refinement sessions.

Wrapping Up

I’d like to close by saying that refining your product backlog isn't just a bureaucratic necessity; I’ve seen other individuals avoiding it yet it's a critical strategy for aligning product development efforts with actual user needs and business goals, and more.

Feel free to take vantage of this process and empower your teams to avoid common pitfalls and enhance their productivity and product quality, ultimately leading to a more successful and competitive product in the marketplace.

Stay tuned for the second part!

Transform your backlog into a strategic asset today 🚀

Embrace the challenge. Refine your backlog. Get the rewards.