Productboard’s Post

"For me, this is similar to the core product prioritization problem: an infinite set of demands that each individual requestor considers to be extremely important/urgent. But for calendars, the scarce resource is time rather than development capacity." - Rich Mironov Read on for some tips on applying good product thinking to your calendar. 👇

"For me, this is similar to the core product prioritization problem: an infinite set of demands that each individual requestor considers to be extremely important/urgent. But for calendars, the scarce resource is time rather than development capacity." - Rich Mironov Read on for some tips on applying good product thinking to your calendar. 👇

Calling all Product Managers! 🗣 Struggling with your #productbacklog? Discover 15 real-world #examples to turbocharge your productivity! Dive in to this #blog now and transform your approach to #productmanagement. Read more: https://lnkd.in/d5qZB9u5

Just read Stephen Puiszis's article on evaluating product roadmaps for engineers, and let me tell you, it's about time someone laid it out like that (link to article in first comment). However, there are a few things I think he misses on. 1. He says in large companies its easy for the roadmap to get away from the vision and mission of the company. While this can be true, a well-structured roadmap, created with input from all relevant parties, can be a source of clarity and alignment rather than contention. It's crucial to involve stakeholders in the roadmap creation process (that includes engineers) to ensure everyone's expectations are aligned and to hash out any disputes. 2. The emphasis on the roadmap being a communication tool that defines resource allocations in time, money, and effort is somewhat limiting. While it's true that a roadmap outlines the allocation of resources, it's more than just a high-leverage activity for a product manager. It's a strategic document that provides direction and vision for the entire team, aligning everyone on the goals and objectives of the product. It's not just about allocating engineers, QA's, designers, etc. it's about the course for the product's future. 3. I agree with the KISS method. You shouldn't need to have a ton of technical terms on your roadmap. These items should be broken down in terms that everyone will understand. Pretend your presenting to someone outside your company, would they understand it? 4. If your using a Now, Next, Later style roadmap, not everything is going to be scoped or prioritized. The initiatives in the Now may be scoped and prioritized but as we look further into the future the less and less discovery will be done. As initiatives are delivered and we start looking to pull these items into the Now bucket, that is when we can do a deep dive into discovery can to inform us the risks and dependencies involved. 5. Flexibility is key, but don't mistake that for a lack of commitment. You need to adapt, but you also need to deliver. Constantly changing directions will just make your team dizzy and demotivated. Especially if there is a lack of delivering.

Some of the practices associated with Product Roadmapping : 1. Consider Dependencies: When planning your roadmap, take into account any dependencies between different features or tasks. Understanding these dependencies helps in creating a more realistic timeline. 2. Risk Assessment: Identify potential risks associated with your roadmap and have mitigation plans in place. This ensures that your team is prepared for unforeseen challenges. 3. Resource Planning: Understand the resources (human, financial, and technical) required for each item on the roadmap. This helps in allocating resources effectively and avoids overcommitting. 4. Balance Short-Term and Long-Term Goals: While short-term goals are crucial, it's equally important to keep long-term strategic objectives in mind. Ensure that your roadmap includes a healthy balance between immediate needs and long-term vision. 5. Feedback Loops: Establish regular feedback loops with customers, stakeholders, and the development team. This continuous feedback helps in refining the roadmap based on evolving needs and market trends. 6. Communication Plan: Develop a clear communication plan to keep all stakeholders informed about updates, changes, and progress. This includes both internal team members and external parties like customers or investors. 7. Measure and Evaluate: Define key performance indicators (KPIs) that align with your product goals. Regularly measure and evaluate the success of the features or enhancements you've implemented. 8. Scenario Planning: Anticipate different scenarios and be prepared with alternative plans. This is particularly important in fast-changing environments or industries. 9. Customer-Centric Approach: Always keep the end-user in mind. Ensure that your roadmap reflects the features and improvements that provide real value to your customers. 10. Educate Stakeholders on Roadmap Concepts: Not everyone in your organization may be familiar with the concept of product roadmapping or the associated methodologies. Take the time to educate stakeholders on the process, terms, and the rationale behind your roadmap decisions. 11. Celebrate Successes: When milestones are achieved or goals are met, celebrate the successes with your team. This fosters a positive and motivated working environment. 12. Review and Retrospective: Conduct regular reviews and retrospectives on past roadmaps and projects. Learn from successes and failures to continuously improve your product management processes. An effective product roadmapping is an iterative process that requires continuous improvement based on feedback and changing circumstances. Thanks Shravan Tickoo #productmanagement #productroadmapping #productgrowth

Unlock one of the most sought out Templates. You’ll also get 30+ others. Join the 100s of PMs already using them in their organizations.

👕 Unlock the Power of T-Shirt Sizing in Product Management! 👕 Did you know that T-shirt sizes aren't just for clothing? They are also a game-changing project estimation tool for capacity planning! 🚀 Imagine a world where your team effortlessly understands the complexity and effort involved in each project. That's exactly what T-shirt sizing brings to the table—two parts useful, one part whimsical! 🎉 Here's why your team should hop on the T-shirt sizing trend: 1️⃣ Clarity for Project Leads: Quickly gauge your team's capacity by assigning T-shirt sizes to initiatives. Extra Small to XXL represents relative effort, making capacity planning a breeze. 2️⃣ Communication for Individual Contributors: Express your bandwidth and priorities clearly with T-shirt sizes. No more complicated explanations—just point to your T-shirt size! 3️⃣ Understanding for the Whole Team: Everyone gets it! Team members can easily grasp who's doing what and when, fostering seamless collaboration. Whether you're in engineering, software development, or even content creation, T-shirt sizing is your go-to tool for efficient project management or effort estimation in Product Management. Ready to simplify project estimation? Embrace T-shirt sizing and watch your team thrive! 👕💪 P.S. - Here is a deck from one of my product case studies where I have done T-Shirt sizing estimation. #ProjectManagement #TShirtSizing #TeamCollaboration #EfficiencyInAction #productmanagement #prioritization

Estimates are great for breaking down large projects into more manageable chunks, assessing work complexity, or pinpointing dependencies. They aid with identifying sprint priorities, and they greatly help with reaching a consensus among team members. Unfortunately, they’re terrible at plotting timelines and helping you evaluate whether the product investment is worth it. And in many organizations, the same estimates in story points are eventually converted into man-days and plotted into Gantt charts. However, by doing that, they discount the complexity, risk, and uncertainty. As a result, they end with continuously postponed releases, unfounded pressure on the development teams, and a culture where product investments are not challenged. These companies fail to realize that costs and estimates are not meant to be interchangeable but complement each other. One to help you assess the project’s complexity, the other to help you set constraints for its development and help you evaluate your next project from different angles. Using Costs Triggers Viability Discussions One of the four significant product risks originally conceived by Marty Cagan at Silicon Valley Product Group is Business Viability Risk (together with Value, Usability, and Feasibility risks). According to Cagan, every product manager should assess whether their proposed solution is workable within the business constraints that include, among other things also, budget. However, in many companies, the conversations about viability only boil down to whether the new functionality fits in the organization’s release cycle and associated release dates. The situation can be even more difficult in SaaS organizations not constrained by quarterly or yearly releases and can postpone the release significantly without many ramifications. As a result, PMs are often unaware of total projected costs, or, for the worse — they ignore them. ROI discussions never take place, and the product direction and strategy are never challenged. This inevitably leads to scope creep, inefficiencies in a development organization, and under-addressed other customer needs. In the worst cases, projects are canceled with extremely high sunken costs, and people are let go. That’s why I strongly recommend assigning a dollar value, at least from a cost perspective, to each new functionality you plan to build and comparing it with other things in your pipeline. By Martin Michalik https://lnkd.in/e78WuKuS #products #productdevelopment #productmanagement

Have you ever found yourself in a meeting room facing a huge product backlog, unsure of where to start? Prioritization is the key to efficiently navigating through epics, features, user stories, and tasks, ultimately saving time, resources, and ensuring customer satisfaction. While there are numerous prioritization techniques available, one effective method is the MoSCoW Agile Prioritization Technique, which categorizes requirements into four main priorities: Must, Should, Could, and Won’t. By adopting the MoSCoW technique, stakeholders, gain clarity on priorities, facilitating better decision-making and resource allocation. To effectively prioritize, ask yourself: 1. Which feature offers the highest efficiency at the lowest cost? 2. What resources are available for implementation? 3. What are the associated risks of developing each feature? 4. Which features will significantly enhance customer satisfaction? Prioritization is the cornerstone of successful product development, enabling teams to focus on what matters most, avoid ambiguity, and deliver value efficiently. By employing techniques like MoSCoW, organizations can streamline their prioritization process and drive product success. for more details reach the story on Medium: https://lnkd.in/dBHReFrq #Agile #ProductManagement #Prioritization

❓ ❓ My Product Backlog is HUGE. How can I prioritize it? When the backlog extends indefinitely into the future, it becomes almost impossible to manage. It is hard to get a full view of it so as to properly prioritize the work items. When new requests come in, where do they go? To the bottom of the backlog, waiting indefinitely to rise to the top and to get worked on? Or somewhere in the middle of the backlog, mixed up with a dozen other things you need to do? Or simply interrupt what you are already doing, become a new priority, and then everything else already in the backlog is pushed further down? Any way you look at it, there is no clear solution to be both responsive to new requests, and to work through the old ones. A very long backlog also creates a sense of never-ending work for both the Product Owner and the rest of the Scrum Team. How to manage a long backlog? Here are a few quick tips: 1️⃣ Trim the backlog using a prioritization technique and removing the low-priority items 2️⃣ Consider a set of experiments to validate the ideas you have in the backlog 3️⃣ Define a Product Goal and focus the backlog on what's important to achieve the Product Goal, removing everything else.