I’ve always been wary of File Manager plugins. From the beginning of my career, I’ve avoided working with clients who don’t trust me with direct server and database access. It’s a slippery slope, and using such plugins adds unnecessary risk. But recently, I broke my own rule and learned firsthand why these tools can be more trouble than they’re worth.
Here’s what happened:
I was working on a client’s website, and the SFTP access provided wasn’t working. Unfortunately, due to the time difference, my client was fast asleep when I needed to resolve the issue. Impatience got the better of me. Eager to diagnose the problem quickly, I made a decision that still makes me cringe: I installed a File Manager plugin to access the files directly.
As I was navigating through the files, I noticed some site redirection issues. The site had multiple factors at play—security plugins, custom .htaccess rules, caching plugins, and redirection plugins. Any one of these could have been the cause of the problem. Following what I believed to be a standard practice, I went straight to the wp-content folder using the File Manager plugin and renamed the plugins folder to plugins-bk to temporarily disable all plugins.
What happened next?
Of course, I had forgotten I was using a plugin to manage the files. By renaming the plugins folder, I effectively deactivated the File Manager plugin, which meant I lost access to the site’s backend, and the entire site went down. Everything came to a halt, and I immediately realized my mistake.
Moral of the Story: A Development Mindset
The lesson here wasn’t just about the technical mistake I made—it was a reminder to stay patient, trust proven methods, and avoid shortcuts when dealing with something as critical as a client’s website. As developers and product managers, we often face challenges where our instincts might push us to rush toward a quick fix. But in this case, my impatience led to unnecessary downtime and extra work.
Mistakes happen, but in the development mindset, the focus should be on continuous improvement. As Steve Jobs said, “Stay hungry, stay foolish.” Keep learning, keep experimenting, but also remember: don’t repeat the same mistake twice. I won’t be rushing into File Manager plugins anytime soon. The next time I encounter an access issue, I’ll wait for the client to fix SFTP access or explore more reliable options instead of taking shortcuts.
Another valuable reminder from this experience is best summed up by Albert Einstein, who said, “Anyone who has never made a mistake has never tried anything new.” The key is not just making mistakes, but learning from them, adapting, and improving.
In the end, development is not just about writing code or managing files—it’s about how you handle the unexpected and keep growing through each challenge you face.
When people talk about entrepreneurship today, it’s often framed as the pursuit of billion-dollar valuations, IPOs, and unicorn startups. But true entrepreneurship has never been about that. At its core, entrepreneurship is about solving problems, adding value, and improving people’s lives. Some of the world’s most successful companies—Google, Amazon, Apple, Microsoft, Spotify, Netflix, and Facebook—were not built on the premise of making billions. They were founded on ideas and visions to solve real-world problems.
These companies and their founders started with one mission: create something meaningful. They weren’t chasing a billion dollars—they were chasing a solution.
Google: A Search Engine, Not an Ad Revenue Generator
When Larry Page and Sergey Brin launched Google in 1998, they didn’t set out to create a money-making machine based on advertisements. The original goal was simple: to build a search engine that helped people find relevant information easily. The internet was growing rapidly, but users had no efficient way to find what they needed. Google solved this problem by creating a fast, reliable search engine focused on delivering the best results based on relevance, not profitability.
As Google evolved, it integrated advertisements, but customer satisfaction remained at its core. Their motto, “Focus on the user and all else will follow,” demonstrates their belief that solving user problems is more important than immediate financial gain. Google’s investments, like those in YouTube and Android, further showcased their long-term vision, focusing on creating an ecosystem where users had seamless access to information, videos, and mobile platforms.
Amazon: Making Books Accessible, Not Profits on Transactions
Similarly, Jeff Bezos didn’t launch Amazon to make money from each transaction. In its early days, Amazon was a humble online bookstore aiming to make it easier for people to find and purchase books without trekking from shop to shop. It was a customer-first approach. Bezos was obsessed with solving the issue of accessibility, not the dollar margin on each sale.
As Amazon grew beyond books into an everything-store, the fundamental principle stayed the same: customer obsession. Bezos once said, “We’re not competitor-obsessed, we’re customer-obsessed.” It was always about making products accessible and improving the shopping experience.
Amazon’s expansion into cloud computing (AWS), which now powers businesses like Netflix and Spotify, wasn’t a cash grab—it was another way of solving a new problem: providing scalable infrastructure for startups and enterprises. The interconnected nature of these businesses is a testament to how Amazon’s customer-first strategy created platforms that benefit countless other companies.
Apple: A Computer for the Rest of Us
When Steve Jobs and Steve Wozniak founded Apple in 1976, they weren’t dreaming of market dominance or financial success. They were driven by the idea of building computers for the rest of us—machines that were affordable and easy to use. Back then, computers were seen as tools for businesses or tech enthusiasts. Apple changed that by creating user-friendly, beautifully designed computers that could sit on anyone’s desk.
Jobs often emphasized, “Stay hungry, stay foolish,” a reminder that entrepreneurship is about chasing bold ideas rather than profits. Apple’s success wasn’t just about innovative technology—it was about a commitment to design, usability, and creating tools that would change the way people interacted with technology.
The launch of products like the iPhone, iPad, and Mac redefined industries, and their continuous investments in music (iTunes) and streaming (Apple Music) connected them with companies like Spotify, changing the way people consumed media globally.
Microsoft: Empowering People, Not Just Businesses
Bill Gates and Paul Allen founded Microsoft to empower people by making computers accessible to everyone, not just businesses or technologists. Their mission was to create software that simplified computing for the masses, starting with the development of Windows, a revolutionary operating system.
For Gates, success was about learning from customers and improving the product. “Your most unhappy customers are your greatest source of learning,” he famously said. Microsoft’s contribution to personal computing wasn’t about creating a billion-dollar company; it was about building software that made computers user-friendly and approachable.
Microsoft’s strategic investment in companies like LinkedIn and its focus on enterprise solutions and cloud services through Azure have solidified its role in empowering both individuals and businesses, often creating synergies with companies like Facebook and Amazon AWS.
Spotify: Music for Everyone, Not Just Profits
When Daniel Ek co-founded Spotify, the music industry was in turmoil, rife with illegal downloads and fragmented revenue streams for artists. Ek wasn’t trying to build a billion-dollar streaming empire; he was trying to solve a very real problem: make music accessible while ensuring that artists got paid.
Spotify’s mission has always been about creating value for both listeners and creators. As Ek put it, “Our job is to make the best of our time on this planet.” Spotify redefined the music industry by changing how music was distributed and consumed, introducing freemium and subscription models that allowed users access to millions of songs while ensuring artists were compensated.
Spotify now relies on infrastructure like Amazon AWS to handle its massive user base, showcasing how these companies interconnect to bring services to life.
Netflix: Entertainment Redefined
Reed Hastings founded Netflix not to dominate the entertainment industry but to solve a simple problem—people hated paying late fees for DVD rentals. Netflix revolutionized movie rentals by offering a subscription model that let people rent movies without worrying about returning them on time.
When Hastings transitioned Netflix into a streaming platform, he redefined how people consumed content. It wasn’t about profit margins; it was about improving the user experience. Netflix now delivers billions of hours of content to subscribers worldwide, all while leveraging cloud services like Amazon AWS to power its platform.
Hastings understood that true success comes from focusing on the customer experience, which is why Netflix invested in original content and cutting-edge technology to stream across the globe.
Facebook: Refusing to Sell for Short-Term Gains
When Mark Zuckerberg turned down a $1 billion offer from Yahoo to buy Facebook in its early days, many thought he was making a mistake. Several of Facebook’s top executives even left, convinced that Zuckerberg was getting it wrong. But Zuckerberg wasn’t focused on a quick sale; he was playing the long game.
Facebook was never built for quick profit—it was about helping people connect with each other in ways that were previously unimaginable. Zuckerberg believed in Facebook’s potential to transform communication, which is why he refused to sell early on. His decision paid off, and today, Facebook is one of the world’s most valuable companies.
Zuckerberg’s long-term vision mirrors that of other visionary entrepreneurs like Jobs and Bezos. His acquisitions of Instagram and WhatsApp further interconnected Facebook with the broader tech ecosystem, much like how Google and Amazon have expanded into various industries.
The Infinite Game: Focus on the Journey, Not the Endgame
All of these entrepreneurs—Page, Brin, Bezos, Jobs, Gates, Ek, Hastings, and Zuckerberg—were playing what Simon Sinek calls the infinite game. They didn’t chase short-term wins or profits. They were focused on solving problems and improving lives. As Sinek put it, “The first criterion to being a leader is you have to want to be one.” These leaders didn’t give up when things got tough—they pushed forward, driven by their visions.
This mindset is what allowed these companies to interconnect and invest in each other’s success, creating a web of partnerships and innovations that reshaped industries.
Conclusion: Chasing Purpose, Not Profit
They got it all wrong. Entrepreneurship was never about billion-dollar valuations. It has always been about solving real problems, adding value, and improving people’s lives. The success stories of Google, Amazon, Apple, Spotify, Netflix, Microsoft, and Facebook are proof that when you focus on creating solutions, financial success often follows.
Entrepreneurship is about the journey, not the destination. These entrepreneurs showed that solving real problems and playing the infinite game leaves a far greater legacy than chasing a quick payday.
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.
Visiting Lahore is always a delightful experience, but my recent trip was especially meaningful as I had the privilege of attending the Skills Gala, an event that brought together a vibrant mix of talent from various sectors. The Skills Gala, held on the 24th and 25th, was a melting pot of ideas and opportunities, designed to bridge the gap between government, industry, academia, and the development sector. It was a true celebration of learning, innovation, and collaboration.
Engaging in a Panel Discussion
One of the most rewarding parts of my visit to Lahore was participating in a dynamic panel discussion titled “Automating Success: WordPress, AI, and Your Business.” The panel featured a diverse group of remarkable individuals: Muhammad Adnan, Mian Shahzad Raza, Muhammad Kashif, myself (Tahir), and Khawaja Fahad Shakeel. Each of us brought a unique perspective to the discussion, sharing the importance of adapting to technological advancements and the impact of these tools on the job market.
Our conversation emphasized the significance of continuous learning and skills development. We explored how WordPress ecosystem offer vast opportunities for professionals in artificial intelligence, digital marketing, web development, quality assurance and content management. Additionally, the discussion around Artificial Intelligence highlighted its transformative power in creating new job roles and the importance of staying updated with these advancements.
Acknowledging the Organizers
I must give a special shoutout to Ayesha Zaman, whose hard work and dedication made the Skills Gala such a success. Her vision for the event was clear: to create an environment that inspired participants and provided them with valuable insights and opportunities. The efforts or core team, sponsors, speakers and volunteers ensured that the event ran smoothly and delivered on its promise of creating opportunities for learning and collaboration.
A Message to the Youth
I have been part of many events and my message to youth has been always clear: invest in your skills, strive for quality, and share your knowledge with others. These are the pillars of personal and professional success. The Skills Gala was a powerful reminder that with the right skills and mindset, the possibilities for growth and achievement are endless.
In the world of agile development, scrum have become the go-to framework. Teams often find themselves in the rhythm of daily standups, focused on what was done yesterday, what’s happening today, and what’s planned for tomorrow. Retrospectives highlight what went well and what needs improvement, but the follow-through often ends when the next sprint begins. While this cycle is effective for task management and tracking short-term progress, it’s easy to fall into a trap—a sprint mindset that overlooks the bigger picture.
What’s often missing is the bigger picture—a long-term vision that goes beyond the immediate sprint.
Project Management and Product Development: A Marathon, Not a Sprint
Project delivery is not a sprint; it’s a marathon. Even more so, product development is an infinite game. Unlike projects with defined scopes and end dates, product development thrives on continuous improvement, adaptability, and long-term vision. To truly excel, teams—and especially leadership—must shift from a sprint mentality to a marathon mindset. Let’s explore why this shift is critical.
The Sprint Mindset: Short-Term Gains, Long-Term Losses?
Sprints are highly effective for breaking down complex tasks into manageable chunks, ensuring accountability, and providing clear milestones. However, a sprint-driven mindset can create tunnel vision, where teams are hyper-focused on immediate goals, often at the expense of long-term strategy.
In environments where the sprint mentality dominates, questions like “What did we do yesterday?” and “What are we doing today?” take precedence, while crucial questions like “Where are we headed?” and “How does this align with our long-term vision?” are neglected. This narrow focus can hinder growth and innovation, leading to short-term wins but long-term losses.
While the sprint mindset drives efficiency, it can sometimes hinder creativity and strategic thinking. If development team want to burry something, it will be living in backlog for eternity.
The Marathon Mindset: Playing the Long Game
The marathon mindset is about embracing a broader perspective. Successful project delivery and product development require a sustained, long-term vision. A marathoner doesn’t just focus on the next mile; they consider the entire course, pacing themselves to reach the finish line. Similarly, successful teams balance short-term tasks with long-term strategy.
Product development is even more complex—it’s an infinite game where the goal is not to “win” but to keep playing, evolving, and delivering continuous value. A team that operates with a marathon mindset is better equipped to:
Adapt to Change: The landscape of technology and market needs is constantly shifting. Teams with a long-term perspective are more likely to embrace change as an opportunity rather than a disruption.
Sustain Innovation: True innovation rarely happens within the confines of a two-week sprint. It requires time, experimentation, and, most importantly, a mindset that values continuous improvement over quick wins.
Align with Vision: Leadership plays a critical role here. Leaders who understand the importance of a marathon mindset can guide their teams to stay aligned with the overarching product vision, making each sprint a stepping stone toward long-term success.
As Simon Sinek discussed in The Infinite Game: “The responsibility of leadership is to ensure that the organization is prepared for the next challenge, not just the next quarter.”
The Leadership Factor: Guiding the Infinite Marathon
For a project or product to succeed, it’s essential that leadership adopts and promotes a marathon mindset. This mindset must trickle down through every layer of the organization. Leaders should encourage their teams to look beyond the next sprint and think about how today’s work contributes to tomorrow’s value. This could mean prioritizing long-term technical debt reduction over quick feature releases, or allowing time for creative brainstorming sessions that might not yield immediate results.
Leadership with a marathon mentality also fosters resilience. The road to a successful product is filled with setbacks, pivots, and challenges. Teams need to be conditioned not just for speed, but for endurance.
Conclusion: Sprints Within a Marathon
The key takeaway is not to abandon sprints but to understand that they are merely tools within a broader, more complex strategy. Product development is an infinite game that requires more than just a series of well-executed sprints. It demands a mindset shift—a recognition that the journey is long, and success lies in sustained, long-term thinking.
The most successful projects and products emerge when leadership and teams think like marathoners: steady, resilient, and always keeping an eye on the horizon.
Having spent a decade in the IT industry, I’ve learned the importance of professionalism and reliability in client communication. Over the years, I’ve never used excuses like “the internet is down,” “the road was blocked,” “I didn’t have electricity,” or “I got a fever.” My clients know they can expect consistent quality and unwavering commitment from me.
1. Setting Realistic Expectations
I believe in setting realistic expectations with my clients. I don’t commit to delivering something within an hour or a day unless I’m confident I can meet that deadline. My delivery timelines are always based on my availability and, crucially, on dependencies from the client’s side. This could be something as simple as waiting for feedback or as complex as needing a recorded video or specific content from them.
I always start by building a basic version of the project and then pause to gather feedback. This iterative approach ensures that the final product aligns closely with the client’s vision and needs, while also managing their expectations effectively.
2. Building Trust and Reliability
The clients I’ve worked with over the years trust me enough to wait for my response rather than immediately seeking help from another resource. This trust allows me to maintain a healthy work-life balance—I can sleep at night knowing that my clients are not expecting immediate responses at all hours. However, when a meeting is scheduled during what would typically be my sleeping hours, I make sure I’m prepared and ready to participate, even if it means adjusting my routine temporarily.
I strive to maintain a professional demeanor, never letting clients know if I’m facing any personal challenges or difficult situations unless it directly affects our work together. This approach has helped me build strong, long-lasting relationships with my clients based on mutual respect and understanding.
I’ve worked with some highly skilled developers who are quick to promise delivery in the shortest possible time—sometimes even within minutes. They often avoid saying something isn’t feasible or acknowledging that a task could realistically take longer, even if it’s just a couple of hours because they’re tied up with other commitments. This habit of overcommitting leads to missed deadlines and ultimately damages the client’s trust, which is key to a successful working relationship.
Conclusion
In the IT industry, reliability, clear communication, and trust are the pillars of a successful client relationship. By setting realistic expectations, delivering quality work, and building trust through consistent performance, I’ve been able to create a reputation that clients value and rely on. This has allowed me to maintain both professional excellence and personal well-being, proving that it’s possible to excel in the industry without compromising on either.
Some time ago, I watched the series Teen Wolf, and it struck a chord with me as I’ve spent a considerable amount of time in leadership roles, building teams around ideas, enabling people, and supporting communities. This experience has taught me valuable lessons about team dynamics, particularly the interplay between different types of leaders and followers.
I often watch videos on leadership and draw inspiration from the genius minds of various fields like Steve Jobs, Neil deGrasse Tyson, and Simon Sinek. Their insights have shaped my understanding of effective leadership. Recently, a particular thought clicked in my mind: a squad of betas will never welcome an alpha. This concept resonates deeply within organizational structures and team dynamics.
When companies hire new individuals, there is often resistance from existing team members. This resistance doesn’t necessarily stem from the newcomer’s lack of preparation or suitability but from the inherent challenge that betas face in keeping pace with an alpha. As Simon Sinek wisely puts it, “Leadership is not about being in charge. It is about taking care of those in your charge.” This suggests that an alpha’s arrival can disrupt the status quo, challenging the betas to elevate their game or risk falling behind.
In Teen Wolf, Scott McCall’s journey from a regular high school student to an alpha werewolf is a perfect example. Initially, Scott struggles with his new role, facing resistance from others who question his leadership. However, over time, he proves his worth through his actions and the way he cares for his pack, ultimately earning their respect and loyalty. This mirrors the real-world scenario where an effective leader must demonstrate their capabilities and earn the trust of their team.
Similarly, a squad of alphas will never settle for anything less than an alpha. They wouldn’t want to bear unnecessary delays due to a beta in the team. Steve Jobs once said, “It doesn’t make sense to hire smart people and then tell them what to do; we hire smart people so they can tell us what to do.” This reflects the idea that alphas seek peers who match their drive and capability, fostering an environment where high achievers can thrive without being held back.
To be a part of a team of alphas, one needs to shadow an alpha and, when the time comes, prove that they are an alpha. This involves learning from the best, understanding the nuances of leadership, and stepping up when the opportunity arises. Neil deGrasse Tyson, an advocate for continuous learning, says, “No one is dumb who is curious. The people who don’t ask questions remain clueless throughout their lives.” This curiosity and willingness to learn from an alpha are crucial steps in transitioning from a beta to an alpha.
In a development team, both alphas and betas play important roles. Alphas drive innovation and push boundaries, while betas provide stability and support. Effective teams recognize and balance these dynamics, leveraging the strengths of each member to achieve collective success.
In conclusion, the dynamics of leadership and team composition are complex but essential for organizational growth. Drawing lessons from Teen Wolf and the wisdom of great leaders, it becomes clear that both alphas and betas have their place. By fostering an environment of mutual respect and continuous learning, teams can navigate these dynamics successfully and achieve great things together.
