I’ve shipped a few Chrome extensions before. All of them were client work: someone hands you a spec, you build to the spec, you hand it over, and whether the thing is actually pleasant to use every day becomes somebody else’s problem.
FeedSanitizer was different. I built it because my own feeds had become unusable.
The problem I actually had
Open LinkedIn on any given morning and count what’s genuinely for you. A recruiter’s engagement bait poll. Four “I’m humbled to announce” posts. A promoted post for a course. Two posts from groups I never joined, surfaced because the algorithm decided I might like them. Somewhere in there, maybe two posts I actually wanted to read.
X is the same shape with different noise: crypto giveaways, airdrops, “retweet to win,” an entire sidebar of trending topics I have never once found useful. Facebook shows me posts from pages I don’t follow and can’t seem to stop suggesting them.
The platforms all ship a “not interested” button. I’ve clicked it hundreds of times. It doesn’t do much, and even when it does, you’re training a recommendation model, not setting a rule.
What I wanted was a rule. Crypto: gone. Giveaway: gone. This one specific person who posts eleven times a day: gone. And when something I actually care about shows up, put a box around it so I don’t scroll past it.
So I built that.
The constraint that shaped everything: it stays on the device
Before I wrote a line of code, I wrote a rules file for the project, and the first rule was that no feed data leaves the browser. Ever.
This wasn’t a marketing decision. It was a “would I install this” decision. A feed filter sees everything you read. If I’m going to build something that watches my entire LinkedIn timeline, that thing runs locally or it doesn’t run.
That single constraint made a lot of other decisions easy. The extension asks the browser for exactly one permission: the ability to store your rules locally. It also needs access to the handful of sites it actually works on, and nothing else. No tracking permission, no analytics, no backend server. Your rules live only on your own machine.
There is no server, so there is nothing to breach and nothing for me to be tempted by later.
It also kept the whole thing small. The entire extension is a few thousand lines of straightforward code, no build pipeline, no framework, nothing you’d need a team to maintain. A narrow, well understood scope is worth protecting; I’ve seen what happens when a shortcut goes wrong in a website I once broke with one click.
Architecture: one engine, three adapters
Every platform renders its feed differently, but the question you’re asking about a post is identical everywhere: given this text and this author, do I hide it, highlight it, or leave it alone?
So I split it exactly there. One part of the extension is the decision maker: it takes a post’s text, its author, and which platform it came from, and decides whether to hide it, highlight it, or leave it alone. It has no idea what a LinkedIn post looks like on screen, and it doesn’t need to.
The other part is a small set of platform adapters, one each for LinkedIn, X, and Facebook. Each adapter’s only job is to answer four simple questions for its platform: where are the posts on the page, what’s the text, who wrote it, and what makes this particular post identifiable.
Adding a new platform later would mean writing one new adapter. The decision-making logic never changes. That separation has held up through every feature I’ve added since, and it’s the single design decision I’d repeat on any project like this.
Spam adapts, so matching had to
A while after launch I hit a post that should have matched one of my rules and didn’t. The post said something like: Get Yours Now, but rendered in a strange, heavy bold font.
That isn’t actually bold text. It’s a different set of lookalike characters that render as bold or italic letters but aren’t the plain letters they appear to be. Spammers run their copy through “fancy text” generators to get fake formatting past platforms that don’t allow it, and as a side effect, the same trick slips straight past any ordinary keyword filter. Simply converting everything to lowercase does nothing to catch it.
The fix turned out to be a single, well established text-cleanup step: a standard normalization that converts these lookalike characters back to their plain letter equivalents before any rule is checked. Ordinary text passes through completely unaffected. One small addition, and a whole category of spam evasion stopped working.
The heuristics I’m not proud of but which work
Not everything has a clean signal to match on. A few of the module hiders, the toggles that strip promoted posts, unfollowed pages, and un-joined groups, rely on smaller, more fragile cues rather than anything solid. I documented each one honestly rather than pretending it was a clean solution: sometimes the answer is simply that there’s no stable hook, here’s the tradeoff, here’s the note for future me.
I also carved out one deliberate exception: hiding is disabled on Facebook search results, since it would end up hiding the exact page you searched for. Highlighting still runs there, since it doesn’t remove anything.
The feature I deleted
Version 1.0 shipped with a toolbar badge counting filtered posts. It looked like a metric. It was actually meaningless: it summed hidden and highlighted posts into one number, two opposite actions, and with infinite scroll it only ever went up, with no denominator. “You’ve filtered 847 posts” out of what. There’s no answer.
I removed it in 1.1. Building for yourself makes this easy in a way client work never does: nobody had to be convinced, I just noticed I’d never once looked at the number and deleted the feature. Carrying a feature nobody uses is its own quiet form of technical debt, the kind I’ve written about before.
What building for myself changed
The real difference wasn’t technical. It was that I felt every rough edge myself, because I was scrolling my own feed with my own extension running every day. Nobody had to convince me something was worth fixing. I noticed it, and I fixed it.
Client extensions ship and you find out how they went months later, filtered through someone else’s summary. This one, I use every morning. Staying close enough to the code to build something like this is part of why I still think staying technical is worth defending, even from a product seat.
FeedSanitizer lives at feedsanitizer.com, and you can install it free from the Chrome Web Store, for X, LinkedIn, and Facebook. Everything runs on your device. It asks for one permission.
If your feed has stopped being useful, you don’t have to accept that. You can just write a rule.
Founders love to build. If you are a technical founder, your instinct is to write code. If you are a sales-driven founder, your instinct is to sell the vision. But jumping straight into building or selling without validating the underlying need is the fastest route to startup failure.
According to historical data from CB Insights, which analyzed 431 VC-backed companies that shut down since 2023, 43% cited poor product-market fit as their cause of death, making it the single most common reason startups fail, ahead of running out of money. They spent months, or years, building a flawless solution for a problem that nobody actually cared about.
This is where Product Discovery comes in. The problem is, most of the literature is written for product managers, not for the founders who are actually making the first calls. For founders, product discovery is the systematic process of mitigating risk before you commit your limited time and capital.
This article is for you: the founder, the domain expert, the entrepreneur with a real problem to solve, who just wants to know where to start.
What Product Discovery Actually Is
Most founders do not fail because they were careless. They fail because they were too certain. The 43% figure is not describing founders who were unsophisticated. It is describing what happens when smart, motivated people build products from inside their own mental model of a problem.
There is a particular trap that Marty Cagan, founder of Inspired and the Silicon Valley Product Group, identified early in his work: the difference between output and outcome. Output is what you ship. Outcome is whether it changes anything for your user.
Founders optimizing for output build features. Founders optimizing for outcomes ask whether users are actually better off.
Product discovery is the structured practice of answering that question before you build, not after. Discovery is not a research phase you do once at the start of a project. It is a repeating loop of questions, experiments, and calibrated bets.
Cagan identifies four risks every product must survive before it deserves to be built:
Value risk: Will users choose to use this? Will customers pay for it? (Does it solve a painful enough problem?)
Usability risk: Can users figure out how to use it? (Is the friction too high?)
Feasibility risk: Can your team actually build it with the time, skills, and resources available?
Business viability risk: Does this solution work across all dimensions of your business. (Does it fit our sales channels, legal constraints, and financial model?)
product discovery
Most founders naturally focus on feasibility (“Can we build it?”) and completely ignore value (“Will anyone care?”). Discovery is the practice of stress-testing value risk first, because that is where the structural failure pattern lives.
Framework 1. Jobs to Be Done (JTBD): Start with the Right Question
Harvard Business School professor Clayton Christensen popularized the Jobs-to-be-Done (JTBD) theory, which is essential reading for any founder.
Core idea: People do not buy products for their features. They “hire” products to accomplish a specific goal in a specific situation.
During discovery, your goal is to uncover the underlying “job.” When founders skip discovery, they build a better drill bit (more features, faster UI). When founders embrace discovery, they might realize the customer actually just wants to hang a picture and perhaps damage-free adhesive strips are a vastly superior product.
Run this exercise before you write a single line of code or brief a single designer:
Identify the situation your user is in when the problem appears.
Name the job they are trying to complete.
List what they currently use to get that job done (even if it is a spreadsheet, a call to a friend, or nothing at all).
Identify the friction in their current approach.
If you cannot answer step three clearly, you do not yet understand your market.
For founders, the practical question is not “what does my product do?” but: “what progress is my user trying to make, and what is getting in the way?”
Use Case: AI Meeting Summarization Tool
Problem: Remote teams waste time after video calls trying to remember what was decided.
First Instinct: Build an AI that records and transcribes meetings.
Job To Be Done: Accountability. Who committed to what, by when, so follow-up does not fall through the gaps.
Better Solution: A lightweight action-item extraction tool that pushes commitments directly into Slack and Jira.ectly into slack and JIRA
It reduces the complexity, gives better positioning and deliver faster time to value.
Framework 2. The Opportunity Solution Tree (OST): Map Before You Build
Teresa Torres, Continuous Discovery Habits (2021). Introduced as a framework in 2016. It takes a vague, forgettable business outcome (e.g., “Increase revenue”) and maps it down through specific customer opportunities (pain points/desires), down to specific solutions, and finally into highly specific, testable experiments.
Core idea: An OST is a visual tool that maps the path from a business outcome through customer opportunities to testable solutions. It keeps teams from jumping to solutions before understanding the opportunity space.
Torres defines the structure as four connected layers:
Layer
What It Represents
Outcome
The measurable business or product goal you are trying to move
Opportunities
Unmet needs, pain points, and desires surfaced through customer interviews
Solutions
Potential ways to address a specific opportunity
Assumption Tests
The fastest experiment you can run to validate whether a solution will work
The insight that makes OST useful for non-product founders is this: most teams skip directly from “outcome” to “solution.” They know what they want to achieve (more revenue, more retention), and they already have an idea of what to build. The OST forces you to spend time in the opportunity space first.
Pick one business outcome. Talk to five users and identify three to five friction points they experience. Do not jump to solutions yet. Just map the opportunities.
Use Case: B2B SaaS tool for small construction businesses
Outcome: Increase paid subscriptions.
First Instinct: Build a scheduling calendar because scheduling looked like the operational gap.
Opportunities Mapped: Contractors losing jobs by underselling, over-promising, or quoting too slowly against larger firms.
Better Solution: A quote-prep tool that helps a contractor produce a professional, accurate quote in under 20 minutes.
Now it has the potential to convert at four times the rate of the original scheduling concept.
Framework 3. Assumption Mapping: Find What Has to Be True, Then Break It
Every startup pitch deck is full of hockey-stick growth graphs and bold claims. But underneath those claims lies a fragile foundation of unstated assumptions. Industry expert David J. Bland, co-author of Testing Business Ideas, champions a technique called Assumption Mapping to prevent founders from building on a house of cards.
Core idea: Every solution you are considering rests on a stack of hidden assumptions. Most founders treat these assumptions as facts. Assumption mapping makes them visible so you can test the riskiest ones before committing engineering time.
The process has three steps:
Write down your solution idea in one sentence.
List every assumption that would need to be true for it to work.
Rank each assumption on two axes:
How much the entire idea depends on it being true.
How confident you are that it is true, and
The assumptions that land in the bottom-right quadrant, low confidence and high dependency, are your most dangerous bets. Those get tested first.
The important distinction from a generic checklist: assumption mapping is not a pass/fail gate. It is a prioritization tool. It tells you which assumptions to test this week, and in what order.
Most founders who skip this step discover which assumptions were wrong at launch. By then, the cost of being wrong has compounded significantly.
Use Case: Marketplace for vetted local service providers
Problem: Homeowners cannot trust the quality of freelance service providers found online.
First Instinct: Build a curated marketplace with real-time background verification as the core trust signal.
Riskiest Assumptions: Users will pay a platform fee for curation; real-time background checks can be integrated within three months with a two-person engineering team.
What Testing Revealed: The first assumption held through a concierge MVP. The second failed: the required API integrations were outside the team’s capacity in the planned window.
Better Solution: Launch with manual vetting and a community review layer. Disclose the gap honestly. Add automated verification in a later sprint once the trust model is proven.
Shipped on time with a credible product rather than delaying six months for a feature whose assumption had already been flagged as high risk.
The Confirmation Bias Trap: Why Smart Founders Still Get This Wrong
There is a specific failure mode worth naming directly, because it affects founders who are doing “the right things” on the surface.
They run user interviews. They collect survey data. They talk to customers regularly. But they are not doing discovery: they are doing confirmation. They are gathering evidence to support a conclusion they have already reached.
Confirmation bias in product research looks like this:
Interviewing only users who have already expressed interest in your idea
Stopping research the moment you find a positive signal
Ignoring friction or hesitation in user responses as “edge cases”
Interpreting “I would use that” as equivalent to “I will pay for that”
Discovery is not about collecting positive feedback. It is about finding out where your mental model is wrong before your roadmap locks it in.
A Practical Discovery Sprint for First-Time Founders
If you have never done formal product discovery, the following is a compressed sequence you can complete in two weeks without hiring a researcher or buying enterprise tools.
Week 1: Problem clarity
Write down your current hypothesis in one sentence: “I believe [user type] struggle with [problem] when [situation], and they need [solution].“
Identify 10 people who match your target user profile. Not friends who support your idea: actual potential users.
Run 30-minute interviews with at least five of them. Do not pitch. Ask about their current experience with the problem space. Listen for where they have tried to solve it before and why those solutions fell short.
After each interview, note the verbatim language they used to describe their frustration. Pay attention to emotional intensity, not just frequency.
Week 2: Opportunity mapping and assumption testing
Build a basic OST with the opportunities you heard. Group similar pain points.
Identify the one opportunity that is both the most painful and the most common.
Write down the three biggest assumptions your solution would need to be true to work.
Design the smallest possible test for your riskiest assumption. This could be a landing page, a paper prototype, a manual concierge process, or a five-minute usability session over a video call.
Run the test. Document the result. Adjust your hypothesis accordingly.
This is not a perfect research process. It is a structured way of being wrong faster and cheaper than a full development cycle.
What Continuous Discovery Looks Like in Practice
The most important shift in thinking is moving from “discovery as a phase” to “discovery as a rhythm.”
Teresa Torres describes this as a weekly habit: starting with a clear, measurable outcome, running short customer interviews on a recurring basis, mapping new insights into your opportunity space, selecting one opportunity to focus on, and running small assumption tests before committing resources.
The operational benefit of this for founders is significant. When discovery is continuous, your roadmap is never based on assumptions that are more than a few weeks old. You are not rediscovering your users every six months at a planning retreat. You have a live map of what is true about your market right now.
For early-stage founders without a dedicated product team, this can look as simple as one 30-minute customer call per week, with notes organized into a shared document that maps insights against your current OST.
The cost of discovery habit is low. The cost of not having it is a 43% structural failure rate.
Closing Thoughts
Product discovery does not require a title, a budget, or a specialized team. It requires a commitment to being wrong in public before you are wrong in production. Product discovery is ultimately an admission of humility. It is the founder acknowledging that while they have a strong vision, they do not yet know exactly how the market wants that vision delivered.
discovery before delivery product guide
Here is where to start:
Write your hypothesis statement in one sentence.
Identify five people who are not your friends but who match your target user.
Ask them about their problem, not about your solution.
Listen for the language they use, not the language you wish they would use.
Build your first OST branch from what you hear.
The founders who build products people actually use are not the ones with the best ideas. They are the ones who stayed curious long enough to find out where their first idea was wrong.
Which of your “Leap of Faith” assumptions are you most afraid to test today?
Most founders in crisis do the same thing: they guess.
Retention is low, so they assume the product needs more features. They ship for three months. Nothing moves. So they pivot to marketing, hire an agency, run ads, rewrite the homepage. Still nothing. Now they’re six months behind, the runway is shorter, and the board is asking questions they can’t answer.
The problem was never a lack of effort. It was a lack of diagnosis. Before you open Jira to restructure the backlog or double your performance marketing spend, you have to answer a high-stakes question: Does your startup have a product problem or a marketing problem?
A product problem and a marketing problem can look identical from the outside, low signups, flat growth, high churn. But they have completely different causes, and treating one with the cure for the other doesn’t just fail to help. It actively makes things worse.
Why This Distinction Matters More Than You Think
According to CB Insights‘ updated 2024 analysis of 431 failed startups, 43% failed due to poor product-market fit. Only 14% cited poor marketing as a primary cause. Running out of cash affected 70% of failures.
Here’s what that means in plain terms: most founders who think they have a marketing problem actually have a product problem. And the ones who think they have a product problem are sometimes spending engineering cycles on the wrong diagnosis, when the real issue is that the right people are simply not finding them.
Misreading the signal costs money. It costs time. At early stage, it can cost the company.
The Core Distinction: What Are You Actually Measuring?
Before running any diagnostic, it helps to clarify what each problem actually means.
Product Problem: The product is not creating enough value for the people who use it. They try it, they don’t experience the promised outcome, and they leave. It doesn’t matter how many people you get through the door: they won’t stay, they won’t pay, and they won’t tell others.
Marketing Problem: The product creates real value for the people who use it, but not enough of the right people are finding it. The pipeline is broken, the message is wrong, or you’re targeting the wrong segment entirely.
To accurately isolate where your delivery engine is breaking down, you must separate user acquisition from user retention.
what happens after the first meaningful interaction with your product?
what are you actually measuring
Diagnostic Tests
Test 1: The “Leaky Bucket” Retention Curve Test
Pull your cohort retention data. Look at what percentage of users who signed up in any given month are still active 30, 60, and 90 days later. Then look at the shape of the curve.
If the curve drops steeply and never flattens, you have a product problem. Users are leaving before they find value, which means the value either isn’t there, isn’t reachable, or isn’t clear.
If the curve flattens at a non-zero baseline, meaning a subset of users stick around indefinitely, you likely have a marketing problem. Your product works for someone. The question is whether you’re reaching enough of those people.
if your paid users churn at similar rates to your free users, the product problem is real. If free users churn and paid users stick, you have a people problem: you’re getting the wrong users in the door.
This is one of the clearest product-market fit signals available. When retention stabilizes and improves without aggressive intervention, it means the underlying problem your product solves is persistent and painful enough that users return on their own. A curve that never flattens is telling you the opposite.
Test 2: The Source-of-Truth Test
You need to know why users left. The problem is that most founders never ask at the right moment.
On one product I worked on, we added a single survey form directly on the deactivation screen. Not an email sent three days later. Not a follow-up call. Right there, before the user clicked the final confirm button. The design was intentional: one question, a short list of options, and a Submit button. No long form.
The result was that users actually answered it. When people are at the exit point, they are already decided and they are often willing to say why, as long as you make it easy. A five-option list takes three seconds to complete. A blank text box gets abandoned.
The options we gave were simple and honest:
It was too hard to use
It was missing a feature I needed
I found something else that works better for me
It was not what I expected when I signed up
It was too expensive for the value I got
Those five options map directly to two buckets.
Product bucket: too hard to use, missing a feature, not enough value for the price. These point to a gap between what the product delivers and what the user needed it to do.
Marketing bucket: found something else, not what I expected. These point to a gap between who the product is for and who is actually being reached.
The marketing bucket answers are about fit between the person and the product at the moment of acquisition: they got there through a wrong message, a wrong channel, or wrong targeting. The product bucket answers are about value delivery after acquisition.
If 70% or more of your responses fall into the product bucket: rebuild before you recruit.
If 70% or more fall into the marketing bucket: your product works, you are just talking to the wrong people in the wrong way.
Test 3: The Word-of-Mouth Test
This is the test most founders forget to run, and it’s one of the most reliable.
Organic word of mouth, meaning referrals that happen through private channels like WhatsApp messages, Slack groups, or direct peer recommendations, is the clearest signal that a product has crossed a value threshold. According to research on organic growth, product retention directly drives new organic user acquisition. The longer and more consistently someone engages with your product, the more they talk about it.
Instead of relying on opinions, assumptions, or internal discussions, look at the data:
Are users referring others without being incentivized to do so?
You can also measure this directly. In one product, we added a simple survey consisting of a single question and a scale. It gave us a lightweight way to track customer satisfaction and sentiment over time. The feedback from real users proved far more valuable than running internal workshops and debating assumptions in meeting rooms. Customers will often tell you exactly how they feel if you make it easy for them.
If you have zero organic referrals after 6+ months and 500+ signups, that is not a marketing problem. People do not stay quiet about products that genuinely help them. They tell someone. The absence of that behavior points to a product that isn’t creating the kind of value that gets talked about.
If you do have organic referrals, even a small trickle, but your overall growth is flat, that’s a marketing problem. You have proof of value. You need distribution.
Test 4: The Sean Ellis Test
Rahul Vohra at Superhuman popularized this for the mainstream. Sean Ellis originally developed it. The question is simple:
“How would you feel if you could no longer use this product?”
very disappointed,
somewhat disappointed,
not disappointed.
If fewer than 40% say “very disappointed,” you have a product problem: specifically, the product is not yet indispensable enough to the people using it. The insight Vohra added to Ellis’s framework: rather than rebuilding features, narrow the segment. Find the users who would say “very disappointed” and understand everything about them. That is your real market.
If 40% or more say “very disappointed” but growth is still stalled: marketing problem. The product has product-market fit, but it’s not reaching the right people at scale.
The Honest Mistake Most Founders Make
In 2025, building became cheaper and faster than ever. This created a new failure mode: founders iterate on the product in response to signals that are actually marketing signals, and they add marketing spend in response to signals that are actually product signals.
The incentive structure makes this worse. Engineers want to build. Marketers want budgets. Both have a professional interest in presenting the problem as solvable through their particular lens.
This is where an independent perspective, someone with no stake in either the product backlog or the media spend, becomes the highest-leverage thing you can invest in. Not to tell you what to build or what to say. But to read the signals you already have and tell you which problem you actually have.
As Sean Ellis’s growth pyramid framework makes clear: sustainable growth only comes after you have unlocked organic. And organic only comes after the product is genuinely worth talking about. You cannot skip this step with ad spend.
A Quick Decision Framework
Use this as a starting point. It’s not a final answer; it’s a map.
Strong signals of a product problem:
☐ Retention curve drops steeply with no flattening, across all user cohorts ☐ Paid users churn at similar rates to free users ☐ Exit interviews cite confusion, lack of value, or unmet expectations ☐ Zero organic referrals after 6+ months ☐ Users engage once and disappear, regardless of channel or campaign ☐ Sean Ellis score below 40% “very disappointed” among active users
Strong signals of a marketing problem:
☐ Retention curve flattens: some users genuinely stick ☐ Paid users stay; free users churn, which points to the wrong audience at the top of funnel ☐ Exit interviews cite “not the right fit,” “signed up thinking it did X,” or “found something else” ☐ You have organic referrals but can’t replicate them at scale ☐ Your best customers came from a narrow, specific channel, and you haven’t doubled down on it ☐ Sean Ellis score above 40%, but only for a small, specific segment
What To Do Next
Once you have identified the bottleneck, use this product management framework to realign your team’s time, budget, and attention on the problem that is actually limiting growth.
If the Signals Point to a Marketing Problem
Stop building features the market has not asked for. Start narrowing your focus.
Find the smallest viable segment where your retention curve is already healthy and users consistently receive value. Then rebuild your growth strategy around those users.
Focus on:
Clarifying the value proposition in plain language
Identifying the channels where your best customers already spend time
Refining your targeting to reach more people who resemble your retained users
Testing messaging based on customer outcomes rather than product features
Investing in distribution before investing in additional functionality
The goal is not to attract more traffic. The goal is to attract more of the right traffic.
If the Signals Point to a Product Problem
Growth will not fix a product that users do not want to keep using.
Before building new functionality, focus on understanding where users struggle and why they leave.
Prioritize:
User interviews with both active and churned customers
Onboarding analysis and drop-off investigation
In-app surveys and contextual feedback collection
UX simplification and friction reduction
Reliability, performance, and technical debt improvements
Many teams respond to weak retention by shipping more features. In reality, the fastest path to growth is often making the existing experience easier, faster, and more reliable.
Run a “Bus Factor” Audit on Your Value Proposition
Product and marketing should be able to describe the primary customer outcome using the same language. A useful exercise is to ask both teams independently:
“What can bring an Aha moment to our customer?”
If the answers differ significantly, users are likely experiencing a gap between what is promised and what is delivered.
Focus on:
A single primary customer outcome
Consistent messaging across marketing and onboarding
A clear path to value during the first user session
Success metrics that both teams share
The closer the promise and experience become, the easier growth becomes.
Establish Automated Guardrails for User Feedback
Stop guessing what is broken. Implement continuous user research methodologies. Do not wait for quarterly reviews or anecdotal feedback. Use micro-feedback triggers to capture customer signals.
Examples include:
Post-onboarding satisfaction surveys
Feedback prompts after key actions
Churn and cancellation surveys
Customer interviews every month
Support ticket trend analysis
A simple one-question survey can often reveal more about customer sentiment than hours of internal debate.
If You Still Cannot Tell
Sometimes the signals are mixed.
Retention may be acceptable but inconsistent. Referrals may exist but not at meaningful scale. Different customer segments may behave in completely different ways.
This is not a failure of observation. It usually means one of three things:
Both product and marketing need improvement
The product solves a real problem, but only for a narrow audience
The wrong customer segment is being targeted
These situations are difficult to diagnose from inside the business because teams naturally become attached to their assumptions.
An experienced external perspective can often identify patterns, blind spots, and opportunities much faster than the team can on its own.
The important thing is to follow evidence rather than opinions. Growth problems become easier to solve when you stop asking who is right and start asking what the data is telling you.
📈 Closing Thoughts
if your product relies on aggressive, non-stop ad spend to survive because your natural retention is zero, you do not have a business—you have an expensive marketing campaign.
The data you need is often easier to access than you think, but only if you are measuring it.
Tools like GA4, Usermaven, Mixpanel, Amplitude, and PostHog can help you track retention, activation, user journeys, referrals, and churn. Combined with customer interviews, support tickets, NPS surveys, and Sean Ellis surveys, they provide enough evidence to determine whether you have a product problem, a marketing problem, or a positioning problem.
Most startups do not suffer from a lack of data. They suffer from a lack of synthesis. The signals are scattered across dashboards and conversations, waiting for someone to connect them into a coherent story.
Read those signals correctly, and you’ll know exactly where to focus your next three months of effort. Misread them, and you’ll spend the next quarter solving the wrong problem, only to wonder why nothing moved.
Tahir Shahzad is a Product Manager, Product Owner, and technology consultant with over a decade of experience helping startups and organizations build products people actually use. If you’re a founder who’s unsure whether your problem is in the product or the pipeline, book a free discovery call to get a diagnosis before you spend another month building or marketing in the wrong direction.
Sometimes I wish I had a Prism of Priorities in my hands.
Not a metaphor, but a real tool. Something I could hold up to every incoming request, every feature idea, every “quick win,” and instantly see its true color; its real weight, its actual impact.
In my mind, it works like light passing through glass. A single request enters as a bright, confident beam, full of urgency and conviction. Then it refracts into a spectrum, revealing what it is truly made of; user value, business impact, technical cost, timing, and sometimes, pure bias.
The Illusion of Clarity
we do not live in a products centric storyland and in reality it might not be as helpful as it sounds.
Because the honest picture of every request would likely create more chaos than clarity. Imagine showing every stakeholder that their “high priority” request breaks into faint, scattered colors when measured against real user needs. Or discovering that multiple “critical” initiatives are simply competing opinions with no grounding in evidence.
As Ben Horowitz said:
“The hard thing about hard things is that there is no formula for dealing with them.”
Prioritization is one of those hard things. There is no perfect framework that removes ambiguity. Only better ways to navigate it.
Products Are Built on Perspectives
Products are not built in isolation. They are shaped by people, and people come with perspectives, incentives, and biases. Every wishlist carries a story;
a sales target to hit,
a customer complaint to resolve,
a feature a competitor just launched,
or simply a belief in what “should” work.
This is where many products quietly drift. According to Marty Cagan, the primary responsibility of a product manager on an empowred product tem is to manage two of the four critical products risks: Value and Viability.
The tension lies in that balance. Value is often assumed. Viability is often negotiated. And both can be distorted by internal bias if left unchecked.
The Role of Corporate Diplomacy
This is where corporate diplomacy becomes an essential skill. Not politics for the sake of survival, but structured communication for clarity. It is about guiding conversations in a way that uncovers what truly matters:
What problem are we solving?
For whom?
Why now?
It is about keeping stakeholders engaged while gradually shifting the conversation from opinions to evidence.
You listen carefully.
You translate requests into hypotheses.
You validate them through data, user behavior, and experiments.
Data does not remove bias entirely, but it anchors decisions in something more stable than intuition alone.
You Don’t Need a Prism
We may never get that perfect Prism of Priorities. But perhaps we do not need one.
Because the real craft of product management is not about revealing a single “true color” of every request. It is about navigating the spectrum; understanding where each input fits, filtering what matters, and continuously aligning the product with the problems it is meant to solve.
Or as Steve Jobs famously said:
“Deciding what not to do is as important as deciding what to do.”
Final Thought
A Prism of Priorities would make things easier, but it would also remove the judgment, context, and nuance that define strong product thinking. The real value lies in how we interpret, challenge, and align; not just what we see.
Sitting in the space where clarity is incomplete requires a different kind of discipline; translating urgency into understanding, and opinions into direction. It comes down to choosing what truly moves the product forward, even when the signal is faint and the noise is loud.
If these ideas resonate, or if you see prioritization differently in your own work, there is always value in exchanging perspectives and learning from real experiences across teams and products.
We were in a routine discussion when my boss asked a seemingly straightforward question:
How do we encourage cross-functional teams to adopt AI in their workflows; reduce bottlenecks; experiment faster; and improve productivity?
On the surface, this sounds like a tooling problem. Introduce AI tools, train teams, and expect outcomes. But the question took me somewhere else.
The Story I Shared
In a village, a new barber arrived. He was skilled, efficient, and consistent. Word spread quickly. His shop became busy; customers kept increasing day by day.
In the same village, three struggling boys noticed this. They did a rough calculation; number of customers multiplied by price per haircut. To them, it looked like easy money.
They approached the barber and asked:
“What tools do you use?”
He showed them a comb, scissors, and a machine. That was enough for them.
They pooled money, bought the same tools, and opened their own shop.
For a brief moment, things looked promising. Curious customers walked in. There was attention, even excitement. But the boys didn’t have the skill, the discipline, or the understanding of the craft. Haircuts were poorly done. Experiences were ruined. Within days, the village knew. No one returned.
the illuion of tools
The tools were right. The outcome was not.
The Parallel With AI Adoption
This is exactly what is happening with AI today. Teams see others using tools like ChatGPT, Claude or many others and assume:
“This is the formula.” So they invest on the tools:
Content teams generate copy
Developers use AI for code
Product teams use it for documentation
But without clarity and structure, the results are inconsistent or even damaging.
Just like the boys with the barber tools.
The First Batch Illusion
The boys did get customers initially because new things attract curiosity. Every product, feature, or workflow change gets a first batch:
Early adopters
Curious users
Internal champions
This phase often creates a false sense of success.
From my experience across product and agile environments, failures around AI adoption don’t come from lack of tools. They come from:
No Skill Development: Teams use AI outputs without understanding context, accuracy, or limitations.
No Workflow Integration: AI is added as a layer, not embedded into decision-making or delivery systems.
No Validation Loop: Outputs are not tested with real users or real scenarios.
No Ownership: No one is responsible for quality when AI is involved.
The result is not acceleration; it is amplified inconsistency.
What the Barber Got Right
The barber’s success was not because of tools. It was because of:
Repeated practice, skill built over time
Understanding of customer expectations
Consistency in delivery
Clear ownership of outcomes
Tools were just enablers.
A Better Way to Introduce AI in Teams
Whether it is a barber shop in a village or a modern AI-powered product, the principle remains the same:
Initial attention comes from curiosity. Sustainable growth comes from capability.
If the goal is to reduce bottlenecks and increase productivity, the approach needs to shift:
1. Start with Problems, Not Tools
Identify where teams are actually stuck:
Slow documentation
Repetitive tasks
Decision delays
Then map AI use cases.
2. Build Skill, Not Just Access
Train teams on:
Prompting
Validation
Context awareness
3. Create Feedback Loops
Every AI-assisted output should be reviewed, tested, and improved.
4. Define Ownership
Someone must own the outcome, even if AI assisted in producing it.
Closing Thought
The gap between tool adoption and actual impact is now visible in real numbers.
According to McKinsey’s State of AI 2025 report, AI adoption has broadened significantly, with 88% of organizations reporting that they use AI in at least one business function. Yet only a small fraction report meaningful impact on the bottom line.
Through 2025/2026, roughly 80% of AI projects are expected to fail to deliver on their projected value. Gartner, RAND Corporation.
The 70% Rule: In successful AI implementations, only 10% of the value comes from the algorithm, 20% from technology/data, and 70% from redesigning how work gets done. Boston Consulting Group (BCG)
What this means in practical terms:
You may see a 20–40% speed improvement in isolated tasks using AI
But you may also introduce quality drops, rework, and decision noise if systems are weak
Over time, this can reduce user trust and retention, which directly impacts growth
Teams that pair AI with structured thinking, validation loops, and accountability can see significant gains in speed, cost efficiency, and experimentation.
Teams that don’t will simply move faster in the wrong direction. The tools are not the differentiator. The system behind them is.
I hated it. I was in a difficult conversation with leadership, explaining why we couldn’t ship. The reason? One key person was absent. As a Technical Product Manager, I was new to the setup and hadn’t built this team myself, but I refuse to abandon ownership just because I’m the new person. I was learning from the dynamics of the team and organizational culture.
I realized our delivery was dependent, not designed. If your software delivery engine stops because someone took a sick day, you aren’t running an Agile team; you’re running a bottleneck.
Fixing the Delivery Engine Piece by Piece
I knew I couldn’t fix everything overnight, so I treated the system like a product and started iterating. I focused on shifting from individual dependency to cross-functional ownership.
Created Backups & Shared Context: We stopped letting critical workflows live only in people’s heads.
Rotated Responsibilities: I ensured knowledge wasn’t locked with one person by rotating tasks during Scrum sprints.
Introduced DevOps & Automation: We implemented CI/CD and uptime monitoring to remove manual deployment risks and “surprises”.
Distributed Ownership: I gave the team ownership of upcoming deliveries, empowering them to make strategic decisions rather than just executing tasks.
Within a year, the transformation was clear: the products I led no longer depended on a single point of failure.
Useful Findings for Product Leaders
Through this process of Digital Transformation, I discovered three hard truths about modern product delivery:
The “Bus Factor”:
The bus factor is a risk management metric representing the minimum number of team members who, if suddenly unavailable (e.g., hit by a bus), would cause a project to fail due to lack of critical knowledge. A low bus factor (e.g., 1) indicates high risk, while a higher number indicates a resilient team with shared knowledge.
Agile is About Resilience
Agile is often misunderstood as a set of ceremonies or frameworks like Scrum or Kanban. In reality, Agile is a resilience system. It is the ability of a team to adapt when priorities shift, people change, or uncertainty increases. A truly Agile team does not depend on perfect plans; it is designed to absorb change and continue delivering value.
Documentation is Delivery
When knowledge lives only in people’s heads, it creates hidden dependencies. This leads to delays, confusion, and risk when key individuals are unavailable. This is a form of technical debt that is harder to detect than bad code. Documentation is not overhead. It is what makes delivery repeatable and reliable.
The “Resilient Delivery” Framework
To reduce these issues in your own organization, I suggest moving away from “hero culture” and toward a system-based framework:
hero culture
Pillar 1: Knowledge Liquidity: Use tools like Kanban to visualize not just tasks, but who knows how to do them. If only one name appears on a certain type of ticket, you have a knowledge silo.
Pillar 2: Automated Guardrails: Shift from manual processes to AI-driven automation and CI/CD. Let the machine handle the “how” so the humans can focus on the “why”.
Pillar 3: Strategic Redundancy: Startups don’t have abundance of resources. That requires adaptability essential. Cross-train your team, share context, and enable people to step into adjacent roles when needed.
Closing Thoughts
Look at your setup today: where does everything slow down when one person steps away?. If you are an aspiring Product Manager in or a founder navigating Digital Transformation, don’t wait for a crisis to fix your system. Build for resilience, not just for speed.
By prioritizing shared context and automated guardrails, you ensure that your “product” continues to deliver value even when life happens.
How are you currently handling single points of failure in your delivery process?
For years, product teams relied on dashboards, filters, and exports just to answer basic questions like:
What changed in user behavior this week?
Which feature actually drove retention?
Where are users dropping off?
But the workflow has always been heavy: Dashboards → Export data → Sheets → Integration tools & Custom Formulas → Back to decisions.
Slow, fragmented, and heavily dependent on human effort to connect the dots.
traditional agentic ai analytics
Even with advanced analytics tools, the reality hasn’t changed much. Teams still spend more time finding insights than actually acting on them.
Now a different model is emerging.
With Agentic AI in product analytics, tools like Usermaven can directly interpret your product data and give contextual summaries without needing extra steps or integrations. Instead of navigating dashboards, you can simply ask and get insights in natural language.
Instead of building workflows around data, insights are becoming part of the workflow itself.
This shifts the conversation from: “Where do I find the data?” to “What is the data trying to tell me?”
This changes the role of analytics from reporting → to reasoning.
A few questions worth discussing:
What tools do you use to understand user behavior?
Do you export data to LLMs or other tools for analysis?
Do you trust AI-generated insights for product decisions?
If your analytics tool gives you simple summaries automatically, would you still need other tools?
There are moments in every product lifecycle when something underneath needs to change.
Sometimes it is small; upgrading a CRM API from V2 to V3 without touching endpoints or user experience. Sometimes it is messy; a core library gets deprecated, and suddenly your pipelines, integrations, and assumptions need to be rebuilt. Sometimes it is big; rebranding, domain changes, or platform migrations that can impact trust and discoverability.
Most users should never notice any of this. That is the job.
In today’s AI-driven ecosystem, where models, tools, and libraries evolve almost daily, these transitions are no longer occasional. They are continuous. AI Product Managers are not just building features; they are constantly managing change under the surface.
I have been through all of these transitions, and one principle stays consistent:
If users notice the transition, something was not handled well; unless you intentionally made it visible as an upgrade.
A Practical Checklist for Managing Product Transitions
With AI systems:
Dependencies change faster
Models become obsolete quickly
Vendor lock-in risks increase
Experimentation becomes continuous
This means transition management is no longer a side task. It is a core competency.
1. Transition Classification
Start by understanding what kind of change you are dealing with:
Silent Upgrade; API versioning, infra improvements
Always have a rollback plan. If you cannot roll back, you are taking unnecessary risk.
6. Observability and Monitoring
Transitions do not end at deployment.
Track:
System performance
Error rates
User behavior changes
Drop-offs in key funnels
Set clear success metrics before release.
7. Communication Strategy
Decide what to hide and what to highlight:
Keep infrastructure changes invisible
Announce improvements that add user value
Frame transitions as benefits, not disruptions
Silence is a strategy; so is storytelling.
Final Thoughts
Every product evolves; APIs change, dependencies break, platforms shift. In the AI era, this pace is no longer manageable with reactive thinking.
Users do not care what you upgraded, replaced, or migrated. They care if something breaks, slows down, or feels different without reason.
That is the standard.
Strong Product Managers treat transitions as first-class work; not background tasks. They plan them, de-risk them, align people around them, and execute with precision. Because every unnoticed transition builds trust. And every visible failure breaks it.
In a world of constant change, stability becomes your real product.
It has been a long journey in the IT industry—moving from development into leadership roles. One thing remained constant: never standing still. Continuous learning, experimenting, and staying aligned with evolving technology shaped the way I approach products and teams today.
This journey led me to be recognized as a Technical Product Manager, sometimes referred to as a T-Shaped Product Manager. That said, this title does not imply knowing everything. It reflects a balance—depth in one area, with awareness across many.
What T-Shaped Really Means
A T-shaped profile combines broad understanding across disciplines (the horizontal bar) with deep expertise in one area (the vertical bar).
For a Technical Product Manager:
The depth lies in technology
The breadth spans business, user experience, delivery, and stakeholder alignment
This balance enables better decision-making, clearer communication, and more realistic product outcomes.
The Reality of Going Beyond Roles
Throughout my career, I have often gone beyond what was expected. Not to take over someone else’s role, but to ensure the product succeeds.
At the same time, I have been careful not to step into ownership that belongs to others.
This is where things get complicated.
Even when roles are clearly defined, boundaries are not always obvious in practice. Questions naturally arise:
Where does a Technical Product Manager stop and a Solution Architect begin?
How does a Product Manager differ from a Marketing or Growth Manager?
These overlaps are not just theoretical—they create real tension within teams.
When Ambiguity Turns Into Conflict
Role ambiguity often leads to friction in cross-functional teams.
Not because people are wrong—but because:
It challenges ownership
It disrupts comfort zones
It creates a sense of being questioned
In some cases, this tension becomes visible through reactions like:
“Do you want to join the development team?”
Statements like this are rarely about the actual discussion. They reflect discomfort when boundaries feel unclear.
If not handled carefully, such situations can lead to unhealthy team dynamics—where instead of focusing on building great products, individuals begin protecting their space.
And a team with internal conflict will rarely deliver its best work.
Defining the Roles (From Experience)
Product Manager
Owns the vision, problem space, and outcomes
Focuses on users, business goals, and prioritization
Technical Product Manager
Bridges business and technology
Understands systems, constraints, and trade-offs
Challenges decisions constructively while staying outcome-focused
Development Lead / Solution Architect
Owns the technical design and implementation approach
Ensures scalability, performance, and maintainability
How I Approach the T-Shaped Role
Being a T-shaped Technical Product Manager is not about control—it is about clarity and alignment.
From my experience, a few principles help maintain that balance:
1. Go Deep, But Not Too Far
Understanding technical details is important. Owning them is not.
The goal is to:
Ask better questions
Understand trade-offs
Avoid unrealistic expectations
Not to replace engineering decisions.
2. Stay Outcome-Focused
Discussions should always connect back to:
User impact
Business value
Long-term product direction
This keeps conversations grounded and reduces personal friction.
3. Respect Ownership
Every role exists for a reason.
Crossing boundaries occasionally is natural. Staying there is where problems begin.
4. Handle Challenges Carefully
Challenging ideas is necessary. Challenging people is not.
The difference lies in:
How questions are framed
The intent behind them
The respect shown in conversations
Where to Draw the Line
From experience, the line becomes clearer with intent.
Step in when:
Product outcomes are at risk
Trade-offs are unclear
Technical decisions impact user experience
Step back when:
The discussion is purely implementation-focused
The team is aligned on direction
Input starts becoming prescriptive
Final Thought
The T-shaped Technical Product Manager operates in a space that naturally overlaps with others. That overlap is not a problem—it is a necessity in modern product teams.
The real challenge is managing it with awareness.
It is not about knowing everything. It is not about controlling decisions.
It is about connecting perspectives without creating conflict.
And when done right, it turns a group of individuals into a team that builds with clarity, not competition.
As a business owner navigating the complexities of digital payments, my experience with PayPal left me with valuable lessons and, admittedly, a few frustrations. While PayPal is a market leader in payment gateways with a significant user base, our journey highlighted critical challenges when dealing with chargebacks and fraud prevention. This post isn’t about placing blame, but rather sharing our experience to help others facing similar issues.
The Scenario: Launching a B2C Platform for Digital Goods
We launched a B2C platform for digital goods, where customers could purchase and instantly receive their products via email. Due to the nature of digital goods—instantaneous delivery without a return or refund option—we implemented rigorous security measures to minimize risks. These included:
Strict transaction rules: Monitoring the number of transactions, purchase limits, and suspicious patterns like repeated CVV attempts.
Email verification: Blocking temporary emails and requiring 2FA (Two-Factor Authentication) for account access.
3D Secure compliance: For card payments, we adhered to industry standards to ensure secure transactions.
Our cautious approach did cost us some potential sales, but it helped us safeguard against fraudulent transactions and reduce chargeback risks.
Fraudulent Behavior Patterns
E-commerce payment gateways often expose businesses to patterns of fraudulent behavior, including:
Mass Attempts: Hundreds of purchase attempts originating from the same IP address within a short timeframe, typically an indicator of automated or malicious activity.
Incremental Fraud: Fraudsters systematically testing multiple card numbers, expiration dates, or CVVs in an attempt to find a working combination and exploit the system.
Chargeback Abuse: Customers intentionally filing disputes or claiming “unauthorized transactions” after receiving goods or services, exploiting lenient refund policies.
Account Takeovers: Fraudsters gaining unauthorized access to legitimate user accounts to make purchases, often bypassing basic security checks.
Such activities not only strain security measures but also highlight the critical need for robust fraud prevention protocols to protect both businesses and customers.
The Challenge: Using PayPal for Payments
Given PayPal’s market presence, we integrated it as one of our payment gateways. The customer journey was simple: users would select PayPal at checkout, redirect to the PayPal platform to log in and authorize the payment, and return to our system with the transaction details. On paper, it looked like a seamless and secure process.
However, chargebacks labeled as “Unauthorized Transactions” began to surface, and they were a game-changer.
The Problem with Chargebacks
Chargebacks are an unavoidable part of e-commerce, but they often pose significant challenges, particularly when it comes to handling “Unauthorized Transactions.” Our experience highlighted several recurring issues:
Email Discrepancies: Some customers registered on our platform with one email and used a different email for their payment gateway account (e.g., PayPal). While this is technically valid, it created confusion and complications when chargebacks were filed, making it difficult to verify user identities.
User Authorization Uncertainty: Even after implementing robust security measures like 2FA (Two-Factor Authentication) for both our platform and payment gateway-associated emails, customers continued to flag transactions as “Unauthorized.” This raised questions about who truly had access to and control over these accounts, leaving businesses in a vulnerable position during disputes.
Family or Shared Accounts: Payment accounts shared among family members or used for group purchases often led to disputes when one party claimed not to have authorized the transaction, even though the purchase was made using legitimate account credentials.
Delayed Chargebacks: Customers sometimes initiated chargebacks weeks or months after the purchase, long after the digital goods had been delivered. This created a scenario where businesses had limited ability to dispute the claims, especially for non-returnable digital products.
Lack of Evidence Weighting: Evidence submitted to dispute a chargeback—such as delivery confirmations or user authentication logs—seemed to carry less weight in decisions, leaving businesses with little recourse.
These issues underscore the complexity of managing chargebacks and the importance of both customer education and proactive fraud prevention measures to reduce disputes and protect the business.
Our Solution: Removing PayPal
After losing a significant amount to chargebacks and exhausting every possible option to improve transaction security, we made the difficult decision to remove PayPal as a payment gateway. This was not a decision we took lightly, as we fully recognize the value and widespread adoption of PayPal in the e-commerce world. It is one of the most trusted and convenient payment platforms for customers, offering seamless transactions and a familiar user experience.
However, for a digital goods platform like ours—where fraud prevention is critical and chargebacks pose unique challenges—we found it increasingly difficult to balance security and usability with PayPal. Our business model requires us to ensure the legitimacy of every transaction because digital goods, once delivered, cannot be returned or refunded. Despite our best efforts, including robust fraud prevention measures, the chargeback process with PayPal created vulnerabilities that we couldn’t effectively mitigate.
Why We Couldn’t Make PayPal Work
Limited Verification Options: Unlike card payment gateways that utilize mechanisms like 3D Secure, PayPal’s system offered limited verification capabilities for customers purchasing digital goods. This made it harder to authenticate the legitimacy of transactions.
Chargeback Risks: For digital goods, chargebacks labeled as “Unauthorized Transactions” often left us with little recourse, as digital products cannot be physically returned. Despite providing evidence of delivery and authentication, disputes often ended in favor of the customer.
Fraudulent Behavior: PayPal’s user-friendly interface, while beneficial for customers, made it easier for fraudsters to exploit the platform. Patterns of incremental fraud, shared accounts, and delayed chargebacks created significant financial risks.
Mismatch with Our Security Standards: Our platform relied on strict security protocols, such as 2FA, email validation, and IP monitoring. Integrating PayPal, with its less stringent user verification, created inconsistencies that exposed us to unnecessary vulnerabilities.
Lessons Learned
While PayPal remains an excellent choice for many businesses, particularly those dealing with physical goods or services that allow returns, it proved to be a poor fit for our specific needs. For digital goods platforms, where fraud prevention and irreversible transactions are critical, these challenges made PayPal an unsustainable solution.
This decision has allowed us to focus on alternative payment gateways that better align with our security requirements, offering advanced fraud detection, tighter user verification, and more robust chargeback dispute mechanisms.
A Word of Advice to Other Businesses
If your business model involves digital goods or services, consider the following before integrating PayPal or similar platforms:
Assess Your Fraud Risks: Evaluate the risk of chargebacks and unauthorized transactions in your industry.
Explore Additional Verification Layers: Look for payment gateways offering tools like 3D Secure, enhanced fraud detection, and multi-factor authentication.
Communicate Clear Policies: Set clear refund and chargeback policies to minimize misunderstandings and disputes.
Removing PayPal was a tough but necessary decision for our business. While we appreciate its role as a leading payment gateway, we had to prioritize the security and sustainability of our platform. This experience has taught us valuable lessons that we hope will help others navigate similar challenges in the ever-evolving e-commerce landscape.
Still Seeking Solutions
While we’ve moved away from PayPal, the challenges we faced have not discouraged us from seeking better solutions to balance security, user convenience, and fraud prevention in our payment processes. Removing PayPal was a strategic decision based on our specific needs as a digital goods platform, but the broader issue of managing fraud and chargebacks remains a significant focus.
Advocating for Better Chargeback Mechanisms
As we navigate these challenges, it’s evident that the industry as a whole needs better mechanisms to address chargebacks, particularly for digital goods. We believe:
Payment gateways should provide more context-specific options for merchants dealing with non-returnable items.
Evidence provided by merchants, such as delivery confirmations or customer authentication logs, should carry greater weight in chargeback disputes.
Collaboration between merchants, payment providers, and customers needs to improve to prevent misuse of chargeback systems.
A Commitment to Continuous Improvement
Despite the hurdles, we remain committed to finding solutions that protect our platform and customers. The e-commerce landscape is constantly evolving, and staying ahead requires a mix of innovation, collaboration, and adaptation. We are optimistic that with continued effort, we’ll achieve a secure and efficient payment ecosystem that aligns with our business needs and customer expectations.
For now, we continue to test and implement measures that not only reduce fraud but also enhance the trust and transparency of our platform. This is an ongoing journey, and we’re determined to turn these challenges into opportunities for growth and improvement.
Disclaimer: This post reflects my personal experience and is intended to share insights with other professionals. It does not represent PayPal’s official practices or policies.
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.
Book a free 30-minute product review. You'll leave with a clear read on what's blocking delivery and what to tackle first, whether or not we end up working together.
Some storage is needed to make the site and its tools work. Anything beyond that, such as knowing which referral brought you here, is entirely your choice and the site works fine without it.
Privacy notice
