In today’s fast-paced world of business and technology, it’s easy to fall into the trap of believing that certifications alone define your capabilities as a project or product manager. Over the years, I’ve completed certifications like the Google Project Management via Coursera and earned my CSPO (Certified Scrum Product Owner) via Scrum Alliance. I’ve also taken few micro-certifications. While these courses taught me valuable knowledge about tools, frameworks, and methodologies, the truth is, project and product management goes far beyond certifications.
These programs helped me understand the core elements and gave me exposure to important practices in the industry. However, I truly mastered these skills only by getting my hands dirty, leading teams, and solving real-world challenges. I’ve realized that project and product management can’t be entirely taught in a classroom—it’s about leadership, handling tough situations, and making decisions when everything’s on the line.
Leadership Over Certifications
Being a project or product manager is more about leadership than technical expertise. Leadership is a skill that isn’t granted by a certificate; it’s developed through experience. Some people excel in technical skills but struggle with leadership, while others naturally have the ability to inspire, organize, and lead without formal training.
Simon Sinek, a leadership expert, illustrates this well with his example from the Marine Corps. He explains that potential officers undergo six weeks of intense training where they can quit at any time. This training is designed to weed out those who don’t want to be leaders. As Sinek puts it, “The first criterion to being a leader is you have to want to be one.” Leadership is tough—it can be thankless, lonely, and incredibly challenging. But in project and product management, it’s what makes the difference between success and failure.
One thing I’ve learned from my experiences is that no certification can prepare you for the real-world challenges you face in the field. For instance, I once led a project demonstration where everything seemed perfect—until the solution failed due to an unexpected angle of sunlight affecting the camera. This was something we hadn’t encountered before, and no textbook or course could have prepared me for the heat of that moment, both literally and figuratively. I had to accept the failure gracefully and quickly think on my feet, acknowledging the problem while managing the client’s expectations, all while battling my own internal guilt.
Balancing Personal and Professional Commitments
Being a project manager often requires balancing personal and professional responsibilities—another aspect no certification can fully prepare you for. I remember a time when my employer used me as an example of dedication to others because I traveled across the country for a work commitment the day after my wedding. This might seem extreme to many, but I had made a commitment well before my marriage date was set. It was my responsibility to manage both my personal and professional commitments, and I did so by discussing it with my family and gaining their support rather than walking away from the commitment.
Leadership in project and product management often means making these tough calls—balancing your time, keeping your promises, and staying accountable, no matter how challenging the circumstances.
Practical Experience vs. Theoretical Knowledge
It’s easy to say things like, “know your customer” or “interview your users,” but putting these principles into practice is much more difficult. During one project, I found myself standing next to an attendance device at a hospital, observing how random person interact with the device and how staff used it to clock in and out. On the surface, this might sound simple, but the discomfort of standing there as a stranger, taking mental notes on behavior, is not something a certification teaches you. It’s the hands-on learning and the real-time observations that help you understand your customer in ways a classroom cannot. A funny aspect, a guest used this device to many times on different days to comb hair.
Another time, I launched a solution for a client whose business handled thousands of dollars in weekly transactions. The pressure of ensuring nothing went wrong was immense. I couldn’t sleep or eat, not because it was part of my job description, but because I knew the stakes were incredibly high. I stayed awake, monitoring every detail, even though I wasn’t being paid for those extra hours. Certifications can teach you how to plan for a launch, but only experience can prepare you for the reality of it.
Leadership in High-Stakes Situations
Leadership is about how you handle pressure, especially when things go wrong. Simon Sinek often speaks about leadership as the responsibility to help those around you rise, even when it’s hard. Leadership isn’t about delegating tasks or following a checklist—it’s about stepping up when the stakes are high and taking responsibility for the outcome.
No certification prepared me for the time when I was in front of a room of clients, sweating both from the physical heat and the internal pressure, when a solution failed due to a reason no one could have foreseen. Leadership, not certification, is what allowed me to remain calm, accept the failure, and offer a plan for improvement.
Handling Unique Challenges
Every project brings its own set of unique challenges, and learning by doing is the only way to normalize those experiences. Certifications are useful for providing a foundation, but it’s the real-world situations that truly shape you as a manager. Whether it’s troubleshooting technical failures on the fly, balancing personal and professional commitments, or standing by a solution you launched while facing the risks, the true essence of project and product management lies in how you navigate uncertainty and lead in moments of crisis.
Conclusion: Experience Over Certification
In the end, while certifications like the Google Project Management Course or CSPO have given me valuable tools, the reality is that project and product management is about leadership, not certificates. It’s about having the ability to make tough decisions, take responsibility, and guide a team through unexpected challenges. Certifications provide a strong foundation, but leadership is something you develop through practice, persistence, and navigating real-world challenges. Leadership is a skill anyone can learn, but it’s only mastered through experience. As a project or product manager, your real growth happens when you’re in the field, handling situations no certification could have ever predicted.
In today’s fast-paced technology landscape, Technical Product Managers (TPMs) are essential for the success of modern product launches and continuous improvements. TPMs uniquely blend technical expertise with strategic business acumen, allowing them to bridge the gap between development teams and business stakeholders. Unlike traditional product managers, TPMs dive deeper into the technical side, working closely with engineers while keeping an eye on the product’s market fit and customer satisfaction.
As someone with experience in full-stack web development and AI/machine learning engineering, I’ve seen firsthand how crucial the TPM role is in delivering successful, scalable products. In startups especially, where resources are limited, the ability to wear multiple hats—including solution architect, project manager, and developer—becomes critical. This comprehensive skill set makes Technical Product Managers a driving force behind well-executed product launches and ongoing product success.
The Role of a Technical Product Manager in Product Development
In any successful product launch, the Product Manager is responsible for ensuring that the right product is built—one that aligns with customer needs, market demands, and business goals. Their role is to define the vision, prioritize features, and make sure the product addresses the right problems. However, the Technical Lead and the Development Team are responsible for building it right. This means they focus on the technical execution, ensuring the product is developed with scalability, performance, and maintainability in mind.
The Technical Product Manager bridges these two areas, ensuring that the product being built not only meets the business objectives but is also technically sound, guiding both the Product Manager and the technical team to stay aligned on both the “what” and the “how” of product development.
Product Manager (PM)
PMs focus on defining the product vision, understanding customer needs, and aligning the roadmap with business objectives. Their primary goal is to ensure the product meets the market’s demands.
Delivery Manager
Delivery Managers oversee the execution of the product, ensuring timelines, resources, and budgets are on track. They work closely with the engineering team to deliver on the defined goals.
Technical Product Manager (TPM)
A TPM does more than manage the product; they dive deep into the technical side, understanding the architecture, technology stack, and development hurdles. They ensure the product is feasible, scalable, and aligned with both business goals and technical realities.
Where Technical Product Managers Thrive
TPMs are particularly valuable in certain environments and projects where their skill set stands out:
Highly Technical Products
Products involving APIs, machine learning, cloud services, or complex backend architectures benefit immensely from TPMs. They can translate technical constraints to business leaders while guiding developers in building the right solution.
Startups
In startups, where teams are lean, TPMs play multiple roles. I’ve often taken on responsibilities like designing solution architectures, engaging developers, and ensuring the product’s technical alignment with business needs. Startups need this versatility to stay competitive and efficient.
Cross-functional Teams
When multiple teams—like frontend developers, backend engineers, and machine learning specialists—work together, a TPM bridges the gaps, ensuring smooth communication and integration across departments.
My Experience Bridging Technical Teams
There have been many adventures but I would like to share one piece from my past where we built a facial recognition-based attendance solution, involving both a web team skilled in APIs and a machine learning team focused on training AI models. The teams had little overlap in expertise, which led to challenges in integrating their work into a cohesive product.
With my technical knowledge and leadership skills, I acted as the bridge between these teams. I worked with the web team to design an API that could seamlessly handle data flow from the front end, while coordinating with the machine learning team to ensure their models were integrated efficiently. This collaboration resulted in a scalable, real-time solution that effectively processed facial recognition data for attendance tracking. My technical understanding allowed me to foresee bottlenecks and prevent them before they became major issues.
The Role of a Technical Product Manager in Product Success
A successful product launch requires coordination, technical insight, and stakeholder management—all key strengths of a Technical Product Manager (TPM). TPMs play a critical role in bridging the gap between development teams and business leaders, managing complex technical details, and ensuring that everyone is aligned toward the same goal.
Wearing Multiple Hats: During product launches, TPMs often juggle multiple responsibilities, including solution architecture, project management, and technical leadership. For example, while launching a scalable AI-powered platform, I had to design the backend infrastructure, manage timelines, and oversee the development team—all while ensuring that the technical decisions were aligned with the launch’s business objectives and budget constraints.
Solution Design: In the high-pressure phase of product launch, TPMs take a lead role in designing systems that are both scalable and reliable. I’ve had to design backend architectures that could handle a sudden influx of users post-launch, ensuring that the infrastructure was robust enough to maintain performance under growing traffic without disruptions.
Developer Engagement: TPMs play a key role in keeping developers aligned with the product’s vision and technical requirements. I’ve worked closely with development teams to ensure they understand both the technical challenges and the broader business context. This prevents common issues like technical debt and keeps the project on track, ensuring a successful launch.
Stakeholder Management: One of the most critical roles of a TPM during a product launch is managing expectations and communication with stakeholders. Whether it’s business leaders, marketing teams, or external clients, keeping everyone informed and aligned is essential. I’ve managed stakeholders by providing regular updates, explaining technical decisions in business terms, and ensuring that launch goals remain clear to all parties. This not only ensures smoother decision-making but also reduces last-minute changes that can jeopardize a launch.
Key Skills and Qualities of a Technical Product Manager
Technical Product Managers bring a unique blend of skills that make them critical for product success. From my experience, here are the key qualities that make TPMs stand out:
Technical Expertise: A TPM needs in-depth knowledge of the technology stack, including APIs, cloud infrastructure, and AI/ML workflows. This allows them to validate technical solutions and troubleshoot issues alongside developers.
Strategic Vision: TPMs must always consider how technical decisions align with business goals. They need to ensure that the product is not only functional but also profitable and scalable.
Problem-solving and Bottleneck Prevention: One of my primary responsibilities is identifying and eliminating bottlenecks early. Whether it’s optimizing a machine learning pipeline or ensuring that APIs are scalable, TPMs must proactively address challenges before they hinder progress.
Collaboration and Communication: A TPM serves as the bridge between technical teams and non-technical stakeholders. My role as a liaison between web and machine learning teams on various projects has taught me that clear communication and collaboration are key to success.
Empathy and Leadership: A TPM must balance user needs with developer constraints. I make sure to approach problems from both perspectives, ensuring that the final product meets customer expectations while supporting developers with clear direction and technical insights.
Agility and Adaptability: In fast-paced environments, TPMs must be able to pivot quickly, adjusting to new challenges or changes in market demand. My experience in startups has honed my ability to remain agile, ensuring that projects stay on course even when priorities shift.
Conclusion: Building the Right Solution the Right Way
The role of a Technical Product Manager is critical to ensuring product success, especially in highly technical fields and startup environments. TPMs not only focus on building the right solution for customers but also ensure that it’s being built the right way. My experiences in AI, full-stack web development, and startups have shown that TPMs are indispensable in managing technical complexity, aligning development teams, and driving successful product launches.
By bridging the gap between technical teams and business stakeholders, TPMs provide the leadership needed to ensure a product’s success, both at launch and through continuous improvement. With the right skills and mindset, a Technical Product Manager can be the key to delivering products that scale, innovate, and meet the market’s demands.
Building a product from scratch is an exciting journey—one that offers the opportunity to create something innovative, solve real-world problems, and, hopefully, make a lasting impact in the market. However, the process of building a product from the ground up also comes with its own set of challenges, risks, and pitfalls. For startups, getting it right from the start can make all the difference between success and failure.
As someone who has navigated this terrain and learned through trial and error, I understand both the excitement and the pressure of starting fresh. In this guide, I’ll share personal experiences and insights gained over the years, as well as a step-by-step approach to building a successful product from scratch.
Challenges of Joining Existing Projects vs. Building from Scratch
When you’re part of a startup, building from scratch is a whole different game compared to working on existing products. I’ve had experiences working in both environments—joining established projects where decisions were already made and starting from a blank canvas. Each has its pros and cons.
In established projects, there’s often a structured foundation, and it’s easier to blend into an existing workflow. However, sometimes you inherit baggage—legacy systems, clunky code, or team dynamics that may be resistant to change. I recall one project where, as a frontend developer, I was told we wouldn’t use Bootstrap because the senior team believed it was bloated with unnecessary features. Instead, we aimed to achieve responsiveness and cross-browser compatibility with minimal custom CSS. Fast forward one year: the CSS file became larger than the entire Bootstrap library! It was clear we could have saved time and effort by leveraging existing frameworks.
On the other hand, building a product from scratch offers flexibility and the freedom to define the project’s DNA. You get to make decisions that shape the future of the product. But it also requires foresight, careful planning, and an openness to learning from mistakes. It’s easy to get sidetracked by “ShaShka” features (as we called them)—fancy, non-essential bells and whistles that can derail focus from core functionality. I experienced this firsthand while leading a team tasked with building a proof of concept under a tight deadline. We got bogged down with non-core features and ended up sacrificing essential components. Ultimately, the project didn’t win the contract, and the team was disillusioned.
Building a product is a marathon, not a sprint. It’s crucial to adopt the right mindset and prepare for an ongoing, iterative process.
A Step-by-Step Guide to Building a Product from Scratch
To guide startups on this journey, let’s break down the process into actionable steps that can help you avoid common mistakes, deliver on time, and build a product that stands out.
1. Start with a Strong Vision
Everything begins with a clear vision. What problem are you solving? Who is your target audience? Why is your product important? Your vision should be simple but compelling, providing a North Star for your team and stakeholders to follow.
The vision isn’t just a “nice to have”; it’s essential for guiding every decision that comes later. It keeps you focused on the core objectives and ensures that you don’t get distracted by features or trends that don’t align with your ultimate goals. Make sure that everyone involved—whether it’s developers, designers, or business leaders—understands and buys into this vision. Here are some abstract-level tools to help:
Product Vision Board: A visual tool to communicate long-term goals and strategy.
North Star Metric: A single key metric that represents your product’s core value to users.
Personas: Fictional profiles representing target users, ensuring the product addresses their specific needs.
Lean Canvas: A one-page framework that outlines key elements like customer segments, problems, and solutions.
KPIs: Metrics to track progress and ensure alignment with business goals.
2. Validate Your Idea
Before you commit resources to development, validate your product idea. This is a critical step that many startups skip in their eagerness to start building. Validation means testing your idea with real users, potential customers, or experts in the industry.
You can start small: create surveys, conduct interviews, or build a basic prototype (MVP) to gather feedback. Early validation helps you identify whether your product solves a real problem and whether there’s a market for it. This process can save you time and money by identifying issues before you’re too deep into development.
Here are some effective methods to validate your product idea:
Minimal Viable Product (MVP): An MVP is the simplest version of your product that includes only the core features. It allows you to test the waters with real users and gather feedback before committing to a full build. By launching an MVP, you can see how your target audience reacts and make data-driven decisions on how to proceed.
Surveys and Interviews: Conducting surveys and interviews with potential customers is a quick way to validate demand. Ask targeted questions to understand user pain points, preferences, and whether your product addresses their needs. This approach gives you direct insights into what your audience wants.
Mockups and Prototypes: Creating visual mockups or interactive prototypes can help bring your idea to life without extensive development. Tools like Figma or Adobe XD allow you to showcase a clickable version of your product, giving users something tangible to react to. Feedback from mockups can guide design and functionality decisions early in the process.
Landing Pages: A simple landing page describing your product, paired with a call to action (e.g., email signups or pre-orders), can gauge interest. It’s a quick way to validate whether people are excited about your product before you invest in development.
Please note, as a goodwill gesture, many people will say your idea is good. But as a startup, it’s your job to assess whether these people are willing to make payments. After all, what’s the use of a great idea that nobody wants to buy?
Using these validation methods helps avoid building a product nobody wants. It ensures your time and resources are invested wisely, focusing on solutions that resonate with real user needs.
3. Build a Minimal Viable Product (MVP)
When building from scratch, it’s tempting to create the perfect product right away. However, that’s a recipe for over-commitment and delays. Instead, start with a Minimal Viable Product (MVP)—a version of the product that includes only the core features necessary to address the primary pain point.
The idea behind an MVP is to get something functional into users’ hands quickly. By doing this, you can start gathering real-world feedback that will shape the product’s future iterations. In my experience, working on an MVP also helps the team stay focused on essential features, preventing scope creep (like those unnecessary “ShaShka” features).
4. Prioritize Features
Once you’ve validated your product idea, the next crucial step is to determine which features to develop first. Not all features are created equal—some will have a much larger impact on your product’s success, while others may be nice-to-haves that can wait for later iterations. Effective feature prioritization helps keep your team focused, ensures efficient use of resources, and aligns your product with business goals. Here are some popular methods for prioritizing features:
Here are some common methods to help:
MoSCoW Method: Categorizes features into Must Have, Should Have, Could Have, and Won’t Have to simplify decision-making. I have shared some more insights here
Now, Next, Later: Organizes features based on timing—what to work on now, next, and later—ideal for agile teams.
RICE Framework: Prioritizes features based on Reach, Impact, Confidence, and Effort using the formula: RICE Score=(Reach×Impact×Confidence)/Effort This helps determine the highest-value features by balancing potential impact against the effort required.
Weighted Scoring: Assigns weight to different factors (e.g., customer engagement, revenue potential, technical complexity) and scores features based on these factors. The total weighted score determines the priority, allowing for a more objective, data-driven approach to feature prioritization.
These frameworks help ensure that teams focus on high-value features aligned with both customer needs and business goals.
5. Assemble a Strong, Balanced Team
A product is only as strong as the team behind it. When building a product from scratch, the team composition can make or break the project. You need a balance of technical and creative minds, alongside people who understand the business and market.
In my early career, I was often just part of the development team, while senior members made the core decisions. Now, as a product manager, I’ve learned that strong leadership isn’t just about telling people what to do—it’s about assembling the right people, empowering them, and creating a culture of open communication. Choose people who are flexible, passionate, and willing to wear multiple hats in the early stages.
Every team benefits from having alpha players—those high-performing individuals who bring a strong combination of skill, drive, and leadership. However, a product can’t thrive on alpha players alone; you need a well-rounded team with diverse strengths. To ensure balance, the Skill-Will Matrix is a valuable tool for assessing team members based on two dimensions:
Skill: Their ability to perform tasks effectively.
Will: Their motivation and drive to excel.
The Skill-Will Matrix divides team members into four quadrants:
High Skill, High Will: These are your natural leaders and alpha players, capable of delivering high-quality work with minimal guidance.
High Skill, Low Will: Skilled team members who may lack motivation. You’ll need to re-engage them through new challenges or meaningful projects.
Low Skill, High Will: Motivated individuals eager to learn. With the right guidance and training, they can grow into valuable contributors.
Low Skill, Low Will: These members may need extra attention to assess whether they can contribute effectively or if other roles suit them better.
6. Stay Agile and Iterate
Building a product from scratch requires flexibility and the ability to adapt to changing circumstances, customer feedback, and new insights. Adopting an Agile mindset from the start ensures that your team can iterate quickly, make adjustments based on real-time data, and stay aligned with business goals. The core principle of Agile is continuous improvement, delivering value in small increments, and being responsive to feedback.
Regardless of the Agile framework you choose—whether it’s Kanban, Scrum, or another—incorporating key ceremonies can significantly streamline development and keep your team aligned:
Daily Standup: A brief, daily check-in where team members share progress, challenges, and next steps to ensure transparency and alignment.
Retrospective: A regular reflection on what went well and areas for improvement, promoting continuous growth and process refinement.
Align with Roadmap: Frequent reviews to ensure current tasks align with the overall product vision and long-term objectives.
Limit Work in Progress (WIP): Restrict the number of tasks in progress to enhance focus and reduce inefficiency.
Backlog Grooming: Regularly prioritize and refine the backlog to ensure the team is always working on the most valuable tasks.
Sprint Planning: Set clear, achievable goals for each sprint, keeping the team focused on delivering impactful features.
7. Engage Stakeholders Early and Often
Communication with stakeholders—whether they’re investors, customers, or internal team members—is key to the success of any product. Startups sometimes make the mistake of involving stakeholders too late in the process, which can result in misaligned expectations.
When we built a proof of concept under a tight deadline, we lost focus by trying to please too many stakeholders at once. This taught me the importance of clear, continuous communication and expectation management. Engage stakeholders early, and make sure they’re part of the decision-making process throughout.
A stakeholder communication plan ensures that the right people receive the right updates at the right time. This plan includes identifying stakeholders, determining communication frequency, and choosing appropriate methods like emails, meetings, or reports.
Interest vs. Influence Matrix
The Interest vs. Influence Matrix categorizes stakeholders based on how much they care about and impact the project:
High Interest, High Influence: These are your primary stakeholders, such as key decision-makers and executives. They require frequent, detailed communication through meetings, progress reports, and real-time updates. Keep them closely involved in major decisions.
High Interest, Low Influence: These stakeholders care about the project but may not have decision-making power. Use regular updates via email or presentations to keep them informed, ensuring they feel included in the process.
Low Interest, High Influence: Stakeholders with influence but low day-to-day involvement (e.g., senior leaders). Provide periodic, high-level updates to keep them in the loop without overwhelming them with details.
Low Interest, Low Influence: These stakeholders don’t require frequent updates. Minimal communication like status emails or quarterly reports may suffice, ensuring they’re aware of the project but not deeply involved.
Tailor your communication mode—meetings, emails, or dashboards—to fit each group’s needs, ensuring everyone stays aligned throughout the project.
8. Prepare for Scaling
As your product grows, so will its demands. To handle increased traffic, users, and data, it’s essential to build your technical infrastructure with scalability in mind from the outset. Failing to plan for growth can lead to performance bottlenecks, higher costs, and operational headaches down the road. Here’s how to prepare for scaling effectively:
Scalable Architecture: Design a flexible, scalable architecture that can handle growth without requiring complete overhauls.
Database Selection: Choose a database that can scale horizontally (adding more servers) or vertically (upgrading server capacity) as data grows.
Development Frameworks: Select development frameworks with proven scalability and strong community support. Having a robust community behind the tools you use ensures you can access resources, updates, and troubleshooting support when scaling challenges arise.
Monitoring and Performance Tools: Integrate tools for monitoring system performance, load balancing, and error detection.
By building scalability into your product from the beginning, you can avoid technical bottlenecks, reduce costs, and ensure your product continues to perform smoothly as demand increases.
Conclusion: Focus on the Infinite Game
Building a product from scratch is a complex but rewarding journey, especially for startups. Success comes from more than just technical skills—it requires clear vision, effective validation, thoughtful feature prioritization, and assembling a strong, balanced team. Staying agile and engaging stakeholders early ensures your product evolves in alignment with both market needs and business goals.
Scalability is another critical factor to consider from the beginning, as your product will grow, and so will its demands. By planning for this growth—whether through scalable architecture, robust tools, or efficient frameworks—you’ll prevent bottlenecks and ensure smooth operations down the road.
Ultimately, the key to success is staying adaptable, learning from mistakes, and focusing on delivering real value. With the right mindset, tools, and team, your product will be well-positioned to thrive and make a lasting impact in the market.
As a Product Manager, one of the most challenging tasks you’ll face is prioritizing features for your product. When I first stepped into a leadership role, I found myself juggling multiple products, each with its own extensive to-do list. The challenge of deciding what needed immediate attention and what could wait was overwhelming. To make matters worse, whenever I asked stakeholders to prioritize, everything seemed to be of the highest priority.
This scenario is all too familiar to many Product/Project Managers. The pressure to deliver everything at once can be intense, especially when every stakeholder believes their request is critical. That’s where the MoSCoW prioritization technique comes in—a simple yet powerful framework that can help you focus on what truly matters.
What is the MoSCoW Prioritization Technique?
The MoSCoW prioritization technique is a method used to categorize product features or requirements into four distinct buckets: Must Have, Should Have, Could Have, and Won’t Have. The name “MoSCoW” is derived from the first letters of these four categories:
Must Have: These are non-negotiable features or requirements that are essential for the product’s success. Without these, the product would fail to meet its core objectives.
Should Have: These features are important but not critical. While the product can function without them, they add significant value and should be included if possible.
Could Have: These are desirable features that would be nice to have but are not essential. They can be included if time and resources allow but are not a priority.
Won’t Have: These are features or requirements that will not be included in the current product cycle. This doesn’t mean they will never be implemented, but they are not a focus for now.
The Power of MoSCoW in Prioritization
When I first encountered the MoSCoW technique, I was at a point where the large volume of tasks was causing paralysis by analysis. I needed a way to streamline my decision-making process, reduce the noise, and focus on what truly mattered. One fine day, I sat down with my team and all the items in our backlog. Based on past experiences, we sorted everything into the relevant MoSCoW buckets. It was not the best but at-least it was a starting point to be discussed with stakeholders.
When I presented the prioritized list to our stakeholders, the number of items we needed to discuss dropped dramatically—from 50-60 items to just 5-10. By focusing on the most critical features (Must Haves), we were able to have more meaningful discussions and make faster decisions. Yes, we had to move few items here and there from one bucket to another based on more knowledge and it is perfectly fine. We make decisions on empirical data.
Overcoming Stakeholder Resistance
One of the biggest challenges with MoSCoW is managing stakeholder expectations, particularly when it comes to the Won’t Have category. Convincing a stakeholder to agree that something they consider important won’t be done in the current cycle can be difficult. After all, no one wants to hear that their request is being sidelined.
However, the MoSCoW framework provided me with a structure to manage these conversations effectively. Here’s how I approached it:
Clarify the Timeline: I explained to stakeholders that “Won’t Have” means we won’t be doing it this quarter or the next. It’s not a hard “no” but rather a “not right now.” This helped to reduce the emotional resistance to putting items in this bucket.
Set Realistic Expectations: I assured stakeholders that if we successfully delivered the Must Have and Should Have items, we would revisit the Won’t Have list. This created a sense of fairness and transparency, ensuring that all features would get their due consideration over time.
Focus on Impact: I emphasized the importance of focusing on features that would have the greatest impact on customers and revenue. By aligning the discussion with broader business goals, it was easier to gain consensus on what truly needed to be prioritized.
This approach not only helped us streamline our workload but also provided a more collaborative and focused environment. By aligning everyone around the most critical priorities, we were able to deliver better products more efficiently.
Applying MoSCoW to Your Product Management Process
If you’re struggling with prioritization, I highly recommend giving the MoSCoW technique a try. Start by gathering your team and stakeholders and listing out all the features, tasks, and requirements. Then, begin categorizing them into Must Have, Should Have, Could Have, and Won’t Have. Here are a few tips to keep in mind:
Be Honest: Don’t shy away from tough decisions. If something is truly a Won’t Have, don’t be afraid to label it as such.
Communicate Clearly: Make sure everyone understands what each category means and why a particular item was placed there.
Review Regularly: Priorities can change, so revisit your MoSCoW list regularly to ensure it still aligns with your goals.
Tools for MoSCoW Prioritization
When it comes to MoSCoW prioritization, there’s no strict rule about the tools you must use. The key is to find a system that allows you to effectively track, organize, and communicate your priorities. Whether you prefer traditional methods or digital platforms, here’s a guide to the tools you can use to implement MoSCoW in your product management process.
Traditional Tools: Whiteboard and Sticky Notes If you’re in a room with your team and stakeholders, a simple whiteboard, a pen, and a few sticky notes can be incredibly effective. This tactile approach allows everyone to visualize priorities, move items around, and engage directly with the process. It’s straightforward, collaborative, and perfect for in-person meetings where quick adjustments and brainstorming sessions are needed.
Digital Spreadsheets: Google Sheets or Microsoft Excel For those working in an online environment or preferring a digital format, spreadsheets offer a versatile solution. Google Sheets and Microsoft Excel are excellent for listing features, categorizing them into the MoSCoW buckets, and sharing them with your team. These tools are particularly useful for remote teams, allowing everyone to access and update the document in real-time. Depending on your organizational needs, you can choose either platform, as both offer robust functionality for tracking and sorting your priorities.
JIRA with Confluence If your organization uses JIRA for project management, integrating MoSCoW prioritization into your existing workflow is seamless. JIRA allows you to list features, assign them to the relevant MoSCoW categories, and track progress. When combined with Confluence, you can create detailed documentation that explains the reasoning behind each priority, making it easier for stakeholders to understand and agree on the decisions.
MIRO: A Visually Engaging Platform For a more visually appealing and interactive experience, MIRO is my personal favorite. This online collaborative tool is ideal for teams that thrive on creativity and visual thinking. MIRO offers built-in templates specifically designed for MoSCoW prioritization, making it easy to start the process. You can invite stakeholders to participate in brainstorming sessions, vote on priorities, and collaborate in real-time. The platform’s engaging interface keeps everyone involved, and the visual representation of priorities helps in making clear, collective decisions.
Choosing the Right Tool for Your Team
Ultimately, the best tool for MoSCoW prioritization is the one that aligns with your team’s needs and working style. Whether you prefer the simplicity of sticky notes, the flexibility of spreadsheets, the integration of JIRA, or the visual appeal of MIRO, the key is to ensure that the tool you choose facilitates clear communication and effective decision-making. The goal is to focus on what truly matters and deliver the most impactful features for your product.
Conclusion: Focus on What Matters Most
The MoSCoW prioritization technique is more than just a framework; it’s a mindset. It forces you to focus on what truly matters and make tough decisions about what can wait. In my experience, applying MoSCoW has not only improved our product development process but has also helped manage stakeholder expectations and fostered a more focused and collaborative team environment.
Remember, in product management, focus is everything. By deciding what not to do, you empower your team to concentrate on what will have the greatest impact. As John Carmack wisely said,
Focus is a matter of deciding what things you’re not going to do.
