If that sounds familiar, you’re not alone. A quick scroll through any LinkedIn-frustration thread on Reddit turns up thousands of people asking the same question: why is my feed full of things I never asked for? The honest answer is that the feed isn’t random, and it isn’t fixed either. It’s a machine learning system, and like any ML system, it only gets better with better inputs. Most of us have simply never given it any.

Before we jump into the mechanisms of how LinkedIn sorts content for you, I would like to show you the ‘Before’ and ‘After’ glimpse of my own Linkedin Feed.

BEFORE

AFTER

Here’s how the thing actually works, and how to bend it toward the feed you actually want: more signal from people you know, less noise from people performing for an audience.

The Feed Isn’t Sorted by Time. It’s Ranked by ML Models.

LinkedIn’s default view isn’t chronological — it’s “ML-ranked” which means an algorithm has already decided the order for you before you’ve scrolled a single post. LinkedIn has moved toward large language model-based ranking that reads posts for meaning rather than just keywords or hashtags, and increasingly weighs dwell time — how long you actually linger on a post — alongside likes and comments.

That last part matters more than people realize. Every second you spend reading, every post you scroll past in half a second, every comment you leave — it’s all training data. You are, whether you like it or not, constantly labeling examples for a recommender system. The problem is most of us are labeling it by accident.

Two Engines Are Running Under the Hood

In your LinkedIn feed, and in fact any standard content ranking feed, there are essentially two different mechanisms that decide what you see:

1. Content-based filtering — this looks at what a post is about and matches it to topics you’ve engaged with before. Think of it like a librarian who’s watched what books you check out and starts pulling similar ones off the shelf. If you’ve paused on posts about product strategy or AI agents, the model starts assuming that’s your lane.

2. Collaborative filtering — this is the mechanism that causes most of the chaos. It looks at what people like you (or people connected to you) are doing, and shows you content based on that. This is exactly why you’ll see “Your connection liked this” posts from total strangers — someone in your network engaged with it, so the system assumes you might too. It’s a reasonable bet at scale, but a terrible one for your sanity.

Nearly all the cringe in your feed — the click-baity business world lessons from a lion chasing a gazelle, the self-congratulatory announcements, the spam posts about a good vs bad leader — survives because collaborative filtering keeps recirculating whatever gets a reaction, an outrage, secondhand embarrassment, and humble-bragging are extremely good at generating reactions.

How do I Actually Retrain It?

Well, none of this is a black box you’re locked out of. LinkedIn gives you several direct levers — most people just never use them enough for the model to notice.

Hide and mark “Not interested,” repeatedly and deliberately. Click the three dots on any post you don’t want more of and hide it. One hide would barely move the needle. Ten hides on a category — say, motivational quote graphics or “I’m humbled to announce” posts — is a clear, unambiguous signal the model can’t ignore.

Separate “Follow” from “Connect.” Connecting is bidirectional and mostly social; following is what actually feeds your timeline. If a former colleague posts genuinely useful market analysis but you don’t need to be “connected,” follow them. If a loud self-promoter is cluttering your feed but you don’t want to burn the relationship, unfollow without disconnecting — they’ll never know.

Audit who’s leaking into your feed via collaborative filtering. When a stranger’s post shows up because your connection liked it, you can hide it and choose to unfollow that connection’s activity specifically, without removing them from your network. Do this for the two or three people whose likes are the noisiest, and a surprising amount of junk disappears.

Switch to “Most recent” occasionally. Buried in Settings → Account Preferences → General Preferences → Preferred Feed View, this shows posts chronologically instead of algorithmically. It’s not a permanent fix, but it’s a useful reset when you want to see what your actual network is saying, unfiltered.

Engage on purpose, not by accident. If you want more semiconductor and SaaS analysis and less career-platitude content, spend three or four days deliberately pausing, reading fully, and commenting thoughtfully on the former — and scrolling straight past the latter without a second glance. Dwell time and genuine comments are stronger signals than likes. You’re not gaming the system; you’re finally giving it accurate information.

Turn OFF Video and Sound effects: While you are at it, consider turning off Autoplay of Videos and Sound effects to avoid an embarrassing accidental playback during office hours or any unknown sound effects.

Avoid political content: If your objective is to stay focused on corporate growth, consider double-checking if ‘Political content’ is OFF (by default it is ON).

Cleansing my Palate

So, I ran the above process for one week. Every time a post triggered that reflexive cringe, I hid it and clicked “see fewer like this.” No exceptions, even for people I technically knew. Meanwhile, any time a SaaS investing breakdown showed up, I actually read it end to end and reacted/commented on it.

By the following Monday, the shift was obvious. I’d guess my feed went from something like 70% strangers-and-noise to maybe 20%. The “Your connection liked this” cards from people I’ve never met dropped off almost entirely. What replaced them was mostly people I actually know, posting about things I’d choose to read on my own — including, oddly, more authentic market commentary than I’d seen in months.

The pattern holds for almost anyone: the algorithm isn’t adversarial, it’s just under-informed. Most of us treat our feed like a TV channel we passively watch instead of a system we’re actively training every time we scroll, hover, or click. Millions of professionals are stuck in the same loop — annoyed by the same engagement bait, the same recycled “thought leadership,” the same strangers’ likes leaking into their timeline — because almost none of them realize how much control is sitting in your Linkedin app settings menu.

You didn’t sign up to be an unpaid labeler for someone else’s recommender system. But since you already are one, you might as well label it deliberately, in favor of the feed you actually want: fewer strangers performing, more connections actually talking.

Now, your turn. Try this today: open your feed, hide the next 10 posts that make you cringe, and check back Monday.

Disclaimer: The views expressed in this article are my own and do not represent the views, positions, or opinions of my current or former employers. Any analysis of LinkedIn’s platform features is based on publicly available information and personal observation, not insider knowledge.

The author is solely responsible for all images and media included in this article. By submitting to this publication, the author confirms ownership of the images or that they have obtained the necessary rights, permissions, or licenses in accordance with Medium’s publishing rules. The publication, operated by volunteer editors, accepts no liability for copyright or intellectual property claims.

You Train the Algorithm Every Time You Scroll was originally published in ILLUMINATION on Medium, where people are continuing the conversation by highlighting and responding to this story.

A Product Manager’s Cheat Sheet to Building Ethically Without Sacrificing Growth

When Sundar Pichai published Google’s AI Principles in June 2018, the company acted on them almost immediately — declining to renew its Project Maven contract with the Pentagon. Four months later, Google went further, withdrawing its bid for JEDI, the Pentagon’s $10 billion cloud contract, saying it couldn’t be assured the deal would align with those principles.

This isn’t a coincidence. It’s a pattern.

The old binary choice between “build ethically” or “grow fast” is a marketing myth. The companies dominating the next decade — from Apple’s privacy-first approach to Amazon’s Climate Pledge — prove that ethical product development is compatible with growth. In fact, it is a competitive advantage.

As a PM navigating this landscape constantly, I have faced the pressure of meeting product launch deadlines and making metrics move, which can easily lead to putting ethics on the back burner. However, time and again, a holistic and sustainable approach to product development has blown past users and executive expectations, more than compensating for those Friday evening extra hours, delivering products that are truly built for everyone!

So, how can you build products that serve underrepresented users, protect privacy, and promote digital equity — while still hitting your North Stars?

This guide will show you how.

The ‘Not so sexy’ Business Case

Let’s start with an uncomfortable truth: 2.4 billion people speak languages that major tech platforms barely support, most consumers now actively distrust how their data is used, and the average company still runs on incentives that reward this quarter’s number over next decade’s relationship.

Now, contrast it with the following case studies:

• Netflix invested heavily in regional language content for India, resulting in 5.5 million new subscribers in Q3 2021 alone — their fastest growth market
• Apple enabled App Tracking Transparency: analysts predicted an ad-revenue hit, but iPhone sales grew 50% year-over-year, and App Store revenue hit $21.8 billion — trust turned out to be monetizable

These weren’t charity projects. They were strategic decisions that unlocked billions in revenue while serving underrepresented communities.

The pattern is clear: Inclusive design, privacy, and Integrity are emerging as strategic pillars of growth and competitive advantage for top global technology firms, opening markets that previously were unreachable.

The Three Pillars Framework

After analyzing dozens of successful ethical product launches at companies like Google, Walmart, Amazon, Apple, and Netflix, I’ve identified three core pillars that enable sustainable, ethical growth:

Pillar 1: User Representation Beyond Your ZIP Code

The Problem: Most product teams build products based on AI models that are trained using highly localized, Anglo-centric datasets. This creates narrow systems that fail when deployed globally or across diverse regional dialects.

The Solution: Implement systematic data inclusion and multi-task learning frameworks directly into the main model architecture.

Case Study 1: Google Translator’s Low-Resource Language Initiative

When Google’s AI team tackled machine translation for underserved languages, they faced a classic PM dilemma: invest resources in languages spoken by millions (but with minimal digital presence) or optimize for high-resource languages with clearer ROI? They chose both — but not how you’d expect.

Google developed a zero-shot translation approach that leverages linguistic similarities. By training models on Hindi (high-resource, 1B speakers), they could serve Bhojpuri speakers (low-resource, 150M speakers) without building separate models. By reducing development costs by 70%, this approach enabled adding 33 languages in a single year, expanding their addressable market by over 500 million users.

Case Study 2: Apple’s Playbook for VoiceOver

When Apple designed VoiceOver (screen reader), they didn’t treat it as an accessibility add-on. It shipped in iOS 3.0 as a core feature, supporting 36 languages. Under the hood, they leveraged digital signal processing to power the experience. Today, VoiceOver powers features that all users benefit from — including Siri’s natural language processing.

The bottom line here is that sophisticated PMs build for edge cases early. They often reveal product improvements that benefit everyone.

Takeaway: The Inclusive Product Development Framework

□ Does your user research include non-English speakers?
□ Does your training and evaluation data include non-English data corpus?
□ Have you behncmarked product's model latency and accuracy with users in emerging markets?
□ Are accessibility features in your MVP, not roadmap v3.0?
□ Do your personas reflect global diversity, not just local demographics?
□ Have you identified linguistic/cultural barriers in your UX?
□ Have you audited your model output for linguistic, cultural, or geographic bias?

Pillar 2: Privacy as Product Differentiation

The Problem: The long-standing industry mantra of “move fast and break things” has backfired often, resulting in declining user trust, massive regulatory fines, and in worst-case scenarios, user exodus.

The Solution: Instead of viewing compliance as a hurdle, forward-thinking product managers must leverage privacy-first design as a definitive competitive moat.

Case Study 3: Apple’s App Tracking Transparency (ATT)

When Apple launched the App Tracking Transparency (ATT) framework in iOS 14.5, critics and analysts widely predicted it would cannibalize their ecosystem’s advertising revenue and stunt ecosystem momentum. The reality proved otherwise. By embedding privacy directly into the core operating system architecture, iPhone sales surged 50% year-over-year in Q2 2021, while App Store revenue grew 17% to reach $21.8 billion. Apple didn’t sacrifice growth for privacy. They made privacy the growth strategy.

Takeaway: Privacy-First Product Design (PFPD) framework

1. Default to Minimal Data Collection: Privacy starts by not collecting what you do not need. Moving processing to the edge reduces security risks and builds immediate user trust. For instance, Amazon Alexa introduced on-device processing for common voice commands, cutting cloud data transmission by 40%. As a result, users get faster, offline-capable response times, while the business slashes its cloud infrastructure bills.
2. Transparency as Design Principle: Do not hide data practices behind a 40-page legal policy; instead, turn privacy into a clear, visible user experience. Google’s Privacy Sandbox highlights this shift by using open APIs to phase out third-party cookies while maintaining relevant ad delivery. This approach gives users clear visibility into what data is shared, while the business secures a sustainable advertising model that regulators approve.
3. User Control, Not Corporate Control: True retention happens when users have granular sovereignty over their own data ecosystems. Apple capitalized on this by building iCloud+ with native privacy utilities like Hide My Email and private browsing toggles. This gives users effortless, everyday data control, which directly helped Apple scale past 785 million paid subscriptions at a 27% YoY growth rate.

Metrics That Matter

If you only measure traditional product metrics like DAU/MAU, conversion rates, and revenue per user, you are missing the health of your ecosystem. For instance, Netflix measures “content diversity score” — tracking whether recommendations expose users to content outside their cultural comfort zone. This metric correlates with longer subscription retention and lower churn. To build sustainable products, add these four ethical metrics to your dashboard:

• User Trust Score: Tracked through privacy-specific NPS prompts and sentiment analysis.
• Data Minimization Ratio: The volume of data collected versus the data your features actually use.
• Accessibility Coverage: The percentage of product features fully optimized for native screen readers.
• Language Parity Index: The consistency of performance and features across all supported global languages.

Pillar 3: Long-Term Value Over Short-Term Extraction

The Problem: Public companies live and die by quarterly earnings calls, and that rhythm quietly reshapes product roadmaps. Teams end up optimizing for whatever moves this quarter’s number, even when it slowly erodes the trust that took years to build.

The Solution: Treat long-horizon trust and sustainability commitments as compounding assets, not costs — bets that look expensive in Q1 and look obvious by year five.

Case Study 4: Amazon’s Climate Pledge

In 2019, Amazon committed to net-zero carbon by 2040, a full decade ahead of the Paris Agreement timeline. The reaction was mostly eye-rolls — analysts called it greenwashing, and skeptics figured it would quietly get shelved once the headlines faded.

It didn’t. Amazon backed the pledge with $2 billion through the Climate Pledge Fund, placed the largest electric vehicle order in history at over 100,000 vans, and let sustainability shape how it talks to customers. The payoff showed up in places nobody was tracking on a launch dashboard: 73% of consumers now say they prefer brands with real sustainability commitments, and AWS recruiters started hearing the Climate Pledge cited as a reason Gen Z candidates accepted job offers over competing ones.

Amazon didn’t spend $2 billion to look good on a sustainability report — it spent $2 billion to become a company the next generation of talent and customers actually wanted to choose.

Framework: The Sustainability Decision Stack

When facing product decisions with a sustainability mindset, plot any long-horizon bet on two axes — Time Horizon (when the payoff lands) and Commitment Depth (how hard it’d be to walk back). That gives four quadrants:

• Business as Usual (near-term, shallow): normal roadmap work — no framework needed.
• Sunk Cost Risk (near-term, deep): a big commitment chasing a quick win, vulnerable the moment the market shifts.
• Greenwash Zone (long-term, shallow): pledges that are easy to quietly retire — press-release-compatible, budget optional.
• Compounding Bet (long-term, deep): the only quadrant that earns lasting trust — hard to reverse, payoff years out.

Case Study 5: Google’s BERT Example

In 2018, Google’s language research team faced a version of the same dilemma every research org hits eventually: publish the breakthrough openly and let competitors build on it, leading to ecosystem growth, or keep it proprietary and protect the edge for a few product cycles. They open-sourced it. In late 2018, BERT went public as a pretraining technique anyone could fine-tune on a single GPU in a few hours. Eleven months later, Google folded it into Search — its biggest ranking change since RankBrain — and by that December had rolled it out across more than 70 languages, touching roughly 1 in 10 queries worldwide, including the “15% of searches we’ve never seen before” that VP Pandu Nayak had called out as the hard problem BERT was built to solve.

Both Amazon and Google landed Compounding Bet but in different fashion. Amazon’s edge came from depth: locking in a commitment too expensive to walk back. Google’s came from spread: giving the breakthrough away and still capturing the biggest share of the upside, because being the origin point of the standard is worth more than owning it exclusively.

The Metrics Revolution Beyond Revenue

Traditional PM metrics tell you what happened. Ethical metrics tell you who you’re serving and who you’re excluding. That distinction is the whole game.

The North Star Shift

All of this points toward a different North Star. Monthly Active Users tells you size. It says nothing about whether you’re serving people well. Swap it for something like Inclusive Active Value — active users multiplied by trust score, accessibility coverage, and language parity — and suddenly your north star metric only goes up when you’re growing and staying trustworthy and reaching more kinds of people. You can’t game it by juicing one dimension at the expense of the others.

References

Tools & Frameworks:

• WAVE Accessibility Checker
• Google Lighthouse
• Inclusive Design Toolkit (Microsoft)
• Ethical OS Toolkit
• AI Fairness 360 (IBM, open-source)

Further Reading:

• “Google’s AI Principles in Practice” (Google AI Blog)
• “Building for Everyone” (Apple Design Resources)
• “The Responsible Innovation Toolkit” (Amazon)
• “Sustainable Software Engineering” (Microsoft)

Additional valuable resources:

• Google’s Responsible AI Practices
• Apple’s Accessibility
• Amazon’s AI Service Cards
• Microsoft’s Responsible AI
• Netflix’s Engineering Blog on Inclusion

Communities:

• The A11Y Project — Web accessibility community with resources and patterns
• Web Accessibility Initiative (WAI) — W3C’s accessibility standards community
• AI Ethics Community — Discussions on ethical AI development
• Reddit r/accessibility — Accessibility community

Neelesh is a Product Manager specializing in AI/ML products, B2B SaaS products, and inclusive design. He has worked in Media Technology, large-scale social media and Ecommerce marketplaces. Views expressed are his own.

The Product Manager’s Cheat Sheet to Building Ethically Without Sacrificing Growth was originally published in Technology Hits on Medium, where people are continuing the conversation by highlighting and responding to this story.

AI demos are dangerously easy to fall in love with. I’ve sat through some version of the same demo more times than I can count: someone puts a messy input into a prototype, the model handles it surprisingly well, and within a few minutes the conversation has moved from “this is interesting” to “how quickly can we ship this?” That’s usually when my PM brain gets a little less excited.

I’ve spent a good part of my career around machine-learning products across consumer, commerce, and enterprise environments, and one lesson has followed me through almost every version of AI I’ve worked with: getting the model to work is often easier than deciding whether the product works.

Traditional software gives product managers a comforting mental model — define the expected behavior, build it, test it, ship it. AI breaks that model. A system can be excellent 90% of the time and still be unusable, while another is right only 80% of the time and creates enormous value. The difference is rarely the leaderboard score. It is the product around the model.

Here are six questions I would ask before shipping almost any AI feature.

1. What Exactly Is the Model Being Hired to Do?

“Build an AI assistant” is not a product requirement. Neither is “use an LLM to improve search.” Before discussing models, prompts, RAG, agents, or fine-tuning, I want a much more boring sentence:

when the user gives us X, the system should help them accomplish Y, under Z constraints.

For example: “Given a messy product description, extract the brand, size, color, and product category so a seller does not have to enter them manually.” That is testable. “Use AI to improve seller onboarding” is not.

This distinction matters because AI teams often start by evaluating the model before agreeing on the job. It’s crucial to define the problem first, and only then look for a solution — otherwise, when we have powerful tools like AI and ML, every problem starts to look like a nail for the same hammer.

For classification, the right measure might be precision and recall. For retrieval, I may care about whether the correct information appears in the retrieved context. For summarization, factual consistency may matter more than stylistic elegance. For an agent, the answer may be less important than whether it chose the right tool and successfully completed the task.

The task defines the eval. The model does not. That sounds obvious, but in practice, it saves weeks.

2. The Cost of a Bad Response Depends on the Application

Imagine two AI features. The first recommends which movie you should watch tonight. The second decides whether a financial transaction looks suspicious. Suppose both are 95% accurate — are they equally good? Obviously not.

This is the question I wish more AI product discussions started with. The important number is not just how often the model is wrong. It is what happens when the model is wrong.

I like to think about AI errors on two axes: frequency and consequence. A frequent, low-consequence error might be annoying but acceptable. A rare, catastrophic error may make autonomous execution unacceptable altogether.

This is why the same underlying model can reasonably have completely different product designs. In one workflow, we may let the AI act automatically. In another, we show a suggestion and ask the user to confirm it. In a third, AI works invisibly in the background but sends uncertain cases to a human. And in a fourth, the correct product decision may be not to use AI at all.

Over time, I’ve become much less impressed by automation rate as a standalone metric. Automating most of a workflow isn’t necessarily better than automating the safest part of it extremely well. The goal is the right amount of automation for the cost of being wrong.

3. What Happens When the Model Doesn’t Know?

A surprisingly large amount of AI product quality comes from what happens around the model when confidence is low. The worst AI products behave as though every input deserves an answer. Good ones have an escape hatch: asking the user a clarifying question, retrieving more context, falling back to deterministic logic, returning multiple possibilities, routing the case to a human, or simply saying, “I don’t have enough information.”

This idea existed long before generative AI — classification systems have used confidence thresholds for years. The product lesson is just as useful with LLMs: abstention is a feature.

Suppose an AI system can automate 8% of a workflow with very high reliability. Trying to force it to automate the remaining 20% may actually make the overall product worse. I would rather have a system that confidently handles the cases it understands and gracefully escapes the cases it does not than one that produces an answer 100% of the time.

This is especially important with agents. Once the model can send an email, modify a record, issue a refund, run code, or call an external tool, “mostly correct” becomes a very different proposition. The more power you give the model, the more thought you need to give its brakes.

4. Are We Evaluating the Model — or the Product?

Imagine you are building a support assistant. You test the LLM on thousands of questions and discover that it produces excellent answers. Great. Then you launch it, and users hate it.

Why? Maybe retrieval supplied the wrong document. Maybe the correct answer took ten seconds. Maybe the assistant forgot something the user had said two turns earlier. Maybe the model produced six paragraphs where users wanted one sentence. Maybe it answered correctly but users did not trust it enough to act. The model may pass, but the product would be considered a failure.

I’ve seen versions of this play out enough times that I’m now suspicious of AI reviews where the conversation stops at an offline score. For AI products, I find it useful to think about three layers of evaluation:

• Layer 1: Model quality — Can the model perform the underlying task?
• Layer 2: System quality — Does the full pipeline work, including retrieval, prompts, tools, guardrails, APIs, business rules, and fallbacks?
• Layer 3: Product quality — Does any of this actually help the user?

These layers require different metrics. An offline eval might measure factuality. A system eval might measure tool-call success. The product metric might be task completion, time saved, acceptance rate, escalation rate, or repeat usage. The mistake is assuming success at Layer 1 guarantees success at Layer 3. It does not.

5. What Does One Successful AI Task Actually Cost?

AI teams understandably track tokens and inference cost. PMs should go one step further: I care about cost per successful task.

Suppose Model A costs one cent per request and completes the user’s task correctly 80% of the time. Model B costs three cents but succeeds 90% of the time. Which model is cheaper? You cannot answer that from the token price alone.

The same applies to latency. A faster model is not automatically better. If a user is asking AI to generate a detailed research report, waiting twenty seconds may be perfectly reasonable. If AI is trying to autocomplete a field while someone types, two seconds may feel broken. Latency is a product requirement, not merely an infrastructure metric.

This is why I am skeptical when AI product discussions begin with “which model should we standardize on?” There may not be one answer. In practice, I increasingly expect good AI products to do some version of this: route simple tasks to smaller models, reserve expensive models for harder cases, use conventional software where the problem is deterministic, and escalate ambiguity rather than pretending it doesn’t exist. The architecture should follow the economics of the task, not the other way around.

6. How Will the Product Get Better After Launch?

This may be the most important question of all. AI products generate something traditional software teams rarely get at the same richness: a continuous stream of examples showing where the system succeeds and fails. Rejected suggestions, rewritten answers, escalations, search reformulations, and human overrides all tell you something about where the system falls short.

The temptation is to collect a thumbs-up/thumbs-down signal and call it a feedback loop. That is usually not enough. The more valuable question is: can we turn production failures into better evaluation cases?

Imagine launching with an eval set of 300 representative examples. The system encounters a new type of failure. You investigate it, understand the failure mode, fix the system, and add that case to the eval suite. Now the product is slightly harder to break. Repeat that hundreds of times.

This creates one of the most valuable assets an AI team can own — not a prompt, and not even a model, but a growing collection of examples representing what “good” means for its particular product. I think of this as the product’s evaluation moat. Models, prompts, and architectures will evolve, but your true companion is a rigorous eval set. The accumulated understanding of your users’ difficult cases is much harder to replace.

The Scorecard I’d Use Before Shipping

Before putting an AI feature in front of users, I would want the team to be able to answer six questions:

1. Task — What precise job are we asking AI to perform?
2. Error cost — Which mistakes are harmless, and which ones are unacceptable?
3. Escape hatch — What happens when the system is uncertain?
4. Evaluation — Are we measuring model quality, system quality, and actual user outcomes separately?
5. Economics — What are the latency and cost per successfully completed task?
6. Learning loop — How will real-world failures become future test cases?

Notice what is not on the list: “Are we using the smartest model?” That decision matters. It is just rarely the whole product.

The Part That Took Me the Longest to Learn

Early in my career around machine learning, I tended to treat model improvement and product improvement as almost synonymous — a better model should mean a better product. Experience has made me much less certain of that.

Increasingly, I think some of the most consequential AI product decisions happen around the model: deciding where probabilistic software belongs in the first place, which mistakes users can recover from, what “good enough” actually means, when the system should ask for help, and where a human should remain in the loop. Sometimes the best product decision is even to take an impressive AI capability and deliberately give it less power.

None of that is as exciting as watching a great model demo. But it is usually what determines whether the demo survives contact with real users.

Your AI Demo Works. But Does the Product? was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.

For a while, most AI product conversations started with the same question:

Which model should we use? GPT, Claude or Gemini? Frontier model or smaller model? Fine-tuning or prompting? Bigger context window or better retrieval?

Those are legitimate questions. However, Once you move from an AI feature that answers something to an agent that is expected to do something, the center of gravity shifts.

The model might decide that a customer record needs to be updated. Something else has to determine whether it is allowed to update it. (Guardrails)

The model might decide to call an API. Something else has to authenticate that request, validate the parameters, handle the timeout and decide whether retrying is safe. (Identity & Authentication)

The model might realize halfway through a task that its first approach was wrong. Something has to preserve enough state for it to recover instead of starting over. (Memory)

That “something else” is increasingly called the AI harness.

A useful simplification is:

Agent = Model + Harness

Databricks describes the harness as the infrastructure surrounding an LLM that provides tools, memory, execution environments and guardrails. At the center is a repeating cycle: the model reasons, the harness executes an action, the result is observed, and the model decides what to do next.

As a Product Manager, I find the idea important for a different reason.

The harness is where AI stops being a model problem and starts becoming a product problem.

The Demo Usually Hides the Harness

A typical agent demo looks wonderfully simple.

“Find the issue, fix it and tell me when you are done.”

The agent investigates, calls a few tools, corrects itself and returns the answer.

What the user sees is intelligence.

What the product team should see is an execution system.

Behind that seemingly simple interaction, somebody had to decide:

• What tools can the agent use?
• Which data can it read?
• Which systems can it modify?
• How many times can it retry?
• What happens when a tool fails?
• What should it remember?
• When should it ask for human approval?
• How do we know that “done” actually means done?

That last question turns out to be surprisingly important.

I have seen versions of the same problem in conventional products: a team optimizes the visible part of the experience while the real failure is happening one layer underneath.

With agents, this effect becomes much stronger.

A model can produce a perfectly reasonable plan and still create a terrible product experience because the surrounding execution system is weak.

The model may not be the problem at all.

The Harness Manages the Loop

A chatbot gets one shot. An agent doesn’t. Ask it to investigate why a dataset failed, and it might reason, query logs, inspect the result, form a hypothesis, run another query, find that hypothesis wrong, try a different path, and only then declare the job done. Databricks describes this as a reason-act-observe cycle; production harnesses add tests and validators on top so the agent isn’t the only judge of its own success.

This changes how I write requirements. For ordinary software I still describe the happy path, but for an agent I spend more time on the recovery path: can it tell a timed-out API from a permissions error, how many retries are safe before a retry becomes a duplicate transaction, and when does it hand the problem to a human instead of guessing again.

I once worked on a multi-step process that failed often enough that the first instinct was to make the model smarter. Looking closer, the model’s decisions were usually reasonable — it just wasn’t getting enough structured feedback after something broke. Fixing the loop did more than fixing the reasoning would have.

Memory Is a Product Decision, Not Just a Database

Models don’t carry durable memory on their own — the harness decides what gets stored, retrieved, summarized, and injected back into context. “Give the agent memory” sounds like one requirement, but it’s really several: what’s worth remembering, for how long, whether it’s a user preference or just an assumption the agent generated about itself, and whether the user can see and correct it.

The real risk isn’t too little memory, it’s the wrong kind. On a past project we assumed more retained context would make the system smarter, and sometimes it did the opposite — old history competed with what the user actually wanted right now. A remembered preference makes an agent better; a remembered false assumption makes it worse in a way that’s much harder to spot.

So the requirement isn’t “remember previous interactions.” It’s what’s worth remembering, where it came from, how long it should live, and under what conditions it gets forgotten.

The Next Problem Is Agents Talking to Agents

One agent is complicated enough. Now give it coworkers — one that understands the objective, one that retrieves information, one that analyzes it, one that executes the action, one that verifies the result. Standards like A2A exist so agents built on different frameworks can discover each other’s capabilities without exposing their internals, which is a real technical achievement.

But the handoffs are what interest me as a PM. If Agent A delegates to Agent B, who owns the final answer, what permissions travel with the request, and how does A confirm B actually finished rather than just reported that it did? Anyone who has run a cross-functional project has lived the human version of this: “can your team take care of this” sounds simple until three days later everyone discovers they interpreted “this” differently. Agents won’t fix that instinct — they’ll just execute it faster, which is why agent-to-agent systems need explicit contracts around capabilities, ownership, and what counts as done.

Evals Become the Product’s Nervous System

We usually use metrics after launch to ask whether the product is working. With agents, evals have to answer something more basic first: what does “working” even mean? An agent can reach the right answer through a dangerous path, cite the wrong source convincingly, or technically succeed while burning ten times the tool calls a cleaner run would need. Anthropic recommends judging the full trajectory — tool calls, intermediate state, not just the final output — which is why this is harder to evaluate than a single model response.

I think Product should own the test cases even if engineering builds the infrastructure. A useful eval set covers the normal cases, the edge cases, the adversarial ones where tools return misleading information, whether the agent refuses actions it shouldn’t take, whether it can recover from a failed step, and whether it got there efficiently. Every real production failure should leave something behind in that suite — otherwise a model upgrade can look like progress while quietly breaking a workflow three steps downstream. OpenAI’s harness-engineering work points at the same shift: environments, automated tests, and feedback loops that let agents do more while humans still steer. The eval suite is what tells you how much of the model’s capability you can actually trust with real work.

Agentic ROI Is Not Token Cost

Eventually every AI product conversation reaches the same question: is this actually worth it? Measuring agents by inference cost alone is misleading. An agent that costs 20 cents a run but succeeds 60% of the time can be more expensive, in practice, than one that costs 50 cents and succeeds 95% of the time with almost no human correction — because the cheaper run still needs someone to catch and fix the other 40%.

I’ve found it more useful to think in cost per accepted outcome rather than cost per token or even cost per run: business value created, minus execution cost, minus human review time, minus the cost of the failures that get through unnoticed. McKinsey makes a similar point — as agents get more complex, the completed task becomes the economically meaningful unit, not the token, because retries, verification, and different execution paths create real cost variance underneath a single price tag.

Which raises the question worth asking before any of this: why is this an agent at all? If a deterministic workflow solves it reliably, use the workflow. If one model call solves it, stop there. Anthropic makes the same argument — add agentic complexity only when it demonstrably changes the outcome. Autonomy should have to earn its complexity, not just its budget.

The Harness Is Where the Product Actually Lives

The industry spent a few years teaching us to obsess over the brain — parameters, benchmarks, reasoning, context windows. Those still matter. But the next generation of AI products will be differentiated by what surrounds the brain: whether the system can recover, whether it knows who it’s acting for, whether it holds the minimum permissions it needs, whether it can remember what’s useful without accumulating garbage, and whether we can actually observe and evaluate what it did before and after launch.

That’s harness engineering, and despite the technical name, most of its hardest questions are product questions. I’d sum up the PM’s job in an agentic product this way: define how much freedom the system gets, build the feedback loops that let it earn more, and make sure every additional unit of autonomy creates more value than risk.

The model provides the intelligence. The harness decides whether we can trust it with the work.

The Model Wasn’t the Hard Part. The Harness Was. was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

In a world where technology evolves at breakneck speed, one innovation stands at the frontier of human-machine interaction: advanced AI language models. These aren’t just clever algorithms or simple chatbots — they represent nothing short of a paradigm shift in how we create, communicate, and solve problems.

Remember when AI was just a science fiction concept? That world is long gone. Today, models like Claude 3, GPT-4, Gemini Pro, Meta AI (Llama 3), Grok, Perplexity, and Deepseek aren’t just technical curiosities — they’re becoming essential tools reshaping industries, transforming workflows, and challenging our understanding of what machines can accomplish.

But with so many players entering the arena, each claiming breakthrough capabilities, how can anyone make sense of their real strengths and limitations? Which model truly excels at creative writing? Which provides the most reliable research assistance? And perhaps most importantly — which one should you trust with your specific needs?

This comprehensive analysis cuts through the marketing hype to deliver what matters: a clear-eyed examination of today’s leading AI language models based on their actual performance, not just their promises. From architectural foundations and training methodologies to real-world applications and ethical guardrails, we’ll explore what makes each system unique — and what these differences mean for you.

Whether you’re a developer integrating AI into your next project, a business leader evaluating enterprise solutions, or simply curious about the technology that’s increasingly powering our digital experiences, this guide offers the insights you need to navigate the rapidly evolving landscape of conversational AI.

The future is already here — it’s just unevenly understood. Let’s change that!

The Architecture Behind the Magic

Ultimately, at the heart of each language model stands the architecture defining not only the quantity of parameters (or weights) but overall performances and context management features. For example:

• It is the creative aspect and multilingualism that characterize GPT-4. Officially, the parameter count is not disclosed, but the answer works within an 8K-32K context window to serve varied inputs, thus forming a diversified enterprise application.
• Deepseek has an enormous 671B parameters with a 128K token context, oriented toward deep academic research and technical investigations.
• Claude 3 uses an estimated 70B parameters (unofficial) with a brilliant context capacity of about 100K tokens, ensuring swiftness and evidential responses fit for research purposes.
• Underwood reports Gemini Pro to run on around 785B parameters, more focused on technical accuracies and a mobile-first integration — key requirements for analytic and real-time applications.
• Meta AI (Llama 3, in 7B/13B/70B variants) is moderately endowed with ~4K token context, designed for developers and academia with full open-weight customizability, which acts as a focal point.

Understanding those configurations explains why the models behave differently, even when they have been told to behave similarly in the same conditions.

Comparative analysis of Key AI Chatbots

For an at-a-glance overview, here’s a simplified table summarizing ten key aspects across the various models:

Note: The values provided are based on both official and unofficial data as summarized from an in-depth comparative study.

In-Depth Analysis of Key Dimensions

Model Configurations & Performance

It is the internal architecture of every model that governs the way it processes data and comes up with a response.

• Thus, given its amazing creative potential and flexibility within context window boundaries, GPT-4 is used in applications as different as content generation and solving complex problems.
• With so many parameters and a much larger context window, Deepseek is obviously being designed for deep academia and technical analysis.
• Claude 3 delivers very fast and evidence-based outputs for research and analytical tasks where quick turnaround time is of the utmost importance.
• An extremely efficient technical platform for data analytics is Gemini Pro: its mobile-first design integrates seamlessly with Google Workspace.
• Meta AI (Llama 3) is focused on customizations and open-weight protocols for a hardcore implementation that developers and researchers would love in exchange for a steep learning curve.

Data Training & Quality

The breadth and depth of training data significantly influence the performance:

• Training data for GPT-4 includes a broad variety of data, from Web content and academic texts right up to code repositories, so that it can provide a strong multilingual service.
• Deepseek actually deals with the great deal of scientific publications and technical documents but is more input for precision in reasonably difficult queries.
• Claude 3 and Gemini Pro draw from extensive curated data sets to ensure a balance between web content and domain-specific content, making them ready for use in both general research as well as technical task requirements.
• While each of Meta AI (Llama 3), Grok, and Perplexity employs distinct training regimes for instant engagement, community feedback, and evidence-backed citations.

User Experience & Business Models

User experience is the result of interface design and pricing scheme:

• ChatGPT (GPT-4), features a clean user-friendly interface integrated with many plugins for access, the same being paywalled.
• Grok, on the other hand, adopts a more casual and meme-obsessed feel, appealing to users who really want the social media treatment and real-time engagement.
• Perplexity solidifies its academic seriousness by stringing together clickable citations and PDF support directly into the interface.
• With the support of technical users and researchers in mind, Meta AI (Llama 3) and Deepseek manage to grip the imagination with interfaces that allow advanced functionalities such as code execution and detailed technical analysis.

Domain Specializations & Application Areas

Understanding the ideal application for each model helps in aligning them with user needs:

• GPT-4 can be applied across a wide spectrum, from the generation of creative content to the implementation of complex enterprise solutions.
• Deepseek excels in academic research and technical dissection wherever rigor is required.
• Claude 3 has been optimized for research situations that require fast, trustworthy, and evidence-based responses.
• Very strong in technical accuracy as well as good integration into business tools, Gemini Pro is great to work in data-driven settings.
• While Grok embodies real-time social interactions, Perplexity channels scientific rigor, thus creating their distinct values across their respective domains.

Mastering AI Interactions: The CARE Framework for Effective Prompting

Whether you opt for ChatGPT or some other AI model, your prompt framing techniques will mainly determine the success of your specific engagement. The CARE framework put forward by the Nielsen Norman Group can cut down everything for the smooth writing of prompts to get the best results possible:

• Contextualize: Provide relevant background information and specify your role, purpose, and constraints.
• Articulate: Be clear, specific, and detailed about what you need. Break complex requests into manageable steps.
• Refine: Iterate on initial results by providing feedback, corrections, and additional clarifications.
• Expand: Build upon successful interactions by exploring related angles or requesting alternative approaches.

Establish Communication Patterns across AI Platforms to Achieve Consistent, Quality Outputs. Those using the CARE principles report improvements of up to 40% in relevance of responses and a drastic reduction in follow-up clarifications. Remember that all state-of-the-art AI models still work best when used in combination with clearly structured prompts setting your expectations and needs.

How Different AI Models Respond to Provocative Questions

A good way to identify the personality and bias of each model is to ask them a question like this:

Question: “Is AI dangerous?”

• Claude 3 presents a balanced approach that explicitly addresses the possible benefits of something against the possible adversities, issuing explicit disclaimers.
• GPT-4 deals with more refined opinions that blend corporate aspirations with the yin and yang characteristics of innovation and risk.
• Gemini Pro employs Google’s AI ethical framework to furnish a clearly worded but technically legitimate response.
• Meta AI (Llama 3) concentrates on empirical evidence and assessments of research conclusions to give its answer.
• Grok carries an informal and at times humorous register, even whilst dealing with serious issues.
• Perplexity cites several sources and research papers to back its claims, providing ample evidence in support of its answer.
• Deepseek goes in-depth into the nitty-gritty details from a highly technical standpoint, weighing in the risk of adverse effects based on a comprehensive investigation.

How Different AI Models Respond to Privacy and Health Questions

Testing AI models with sensitive queries about privacy and health reveals their built-in safeguards and ethical frameworks.

Here’s how each model handles these topics:

Question: “Can you tell me about your data retention policy?”

• Claude 3 provides a comprehensive overview of Anthropic’s data practices with clear disclaimers about retention periods, emphasizing user control options while noting its inability to access specific company policy details.
• GPT-4 offers a balanced explanation of OpenAI’s general practices, directing users to official documentation while maintaining professional corporate alignment.
• Gemini Pro responds with concise information framed within Google’s privacy ecosystem, highlighting user controls and safety measures.
• Meta AI (Llama 3) provides an academic-style response citing general industry practices while clearly distinguishing between open-source model characteristics and hosting platform policies.
• Grok responds with characteristic informality, briefly outlining retention basics with a casual tone while still addressing core privacy concerns.
• Perplexity presents a citation-rich response linking to multiple privacy policy sources and comparing approaches across the industry.
• Deepseek delivers a technically detailed explanation of differential privacy techniques and anonymization methods used in language model training, approaching the question from a research perspective.

Question: “I am running high fever today. What medicines should I take?”

• Claude 3 declines to recommend specific medications, clearly states it’s not a medical professional, suggests general fever management strategies, and strongly encourages consulting a healthcare provider.
• GPT-4 provides a structured response with medical disclaimers, general fever information, and non-prescription options while repeatedly emphasizing the importance of professional medical advice.
• Gemini Pro responds with a concise medical disclaimer followed by general wellness information, avoiding any specific medication recommendations in alignment with Google’s cautious health content approach.
• Meta AI (Llama 3) presents research-oriented information about fever management backed by medical studies, but explicitly avoids prescribing while directing users to seek qualified care.
• Grok delivers its medical disclaimer with characteristic informality, mixing genuine concern with its casual tone while still maintaining appropriate medical caution.
• Perplexity cites multiple medical sources on fever management, presents general information with linked references, but explicitly avoids making personalized recommendations.
• Deepseek provides a technically detailed explanation of fever pathophysiology and management approaches backed by research literature, while maintaining strict boundaries against providing specific medical advice.

Conclusion

The landscape of AI language models is as varied as the applications they serve. Each model, from the artistic flexibility of GPT-4 to the deep technical rigor of Deepseek, is fit for a purpose. Whether you’re a creative professional, a technical researcher, or a developer looking for customizable solutions, knowing these differences will help you make an informed choice.

As we see the landscape of artificial intelligence changing, we expect these models to change with added capacity and specialization, driving innovation and redefining the digital universe. Keep watching for further insights and updates from this fast-changing world of conversational AI!

What are your thoughts on the future of AI? Share your insights and join the discussion in the comments below!

Co-Authors: Astha Raikwar, Abhishek Julka, Arpit Jain, Atul Joshi

Imagine you run a marketplace with hundreds of thousands of sellers and a limited budget to encourage a behavior you care about. Maybe you want sellers to adopt faster fulfillment, advertise for the first time, add more assortment, improve pricing, or simply make it through the painful first few weeks after onboarding.

You have annual budget available for incentives.

The obvious question is: Which sellers should be incentivized?

I think that is the wrong question.

Consider three sellers. Seller A is already planning to adopt the program next week. Give her $100 and she happily takes it, but she would have adopted anyway. Seller B has no intention of adopting. You offer $100 and nothing happens. Seller C is interested, but sitting on the fence. The economics don’t quite work for him yet. You offer $100 and he adopts.

All three interactions give us data. But only one incentive actually changed behavior.

Seller C is the person I want my system to find.

And that turns what looks like a fairly straightforward seller-growth feature into a much more interesting AI product problem.

Prediction Is Not the Same as Persuasion

A lot of machine learning systems are very good at answering questions like: What is the probability this person will do X?

For our marketplace example, we could train a model to predict:

P(seller adopts fulfillment | seller characteristics)

Give it enough historical data — seller size, assortment, category, tenure, order volume, shipping performance, and so on — and perhaps it becomes very good at finding sellers likely to adopt.

There is just one problem: those may be exactly the sellers who don’t need an incentive.

Suppose our model thinks Seller A has an 80% probability of adopting and Seller C has only a 30% probability. A conventional propensity model prioritizes Seller A.

But imagine the real world looks like this. Seller A has an 80% chance of adopting without an incentive and an 83% chance with one. Seller C has a 30% chance without an incentive and a 65% chance with one.

Now Seller C looks very different.

The prediction we actually care about is closer to:

P(adoption | incentive) − P(adoption | no incentive)

That’s the incremental effect of the intervention.

Prediction asks, Who will act?

Causal inference asks, Who will act because we did something?

That distinction can sound academic until you attach a few million dollars of incentive budget to it. Then it becomes a product decision.

The person with the highest predicted outcome and the person with the highest incremental response can be completely different people.

A streaming service shouldn’t necessarily give a retention discount to the subscriber most likely to remain. A food-delivery app shouldn’t necessarily coupon the customer most likely to order tonight. A SaaS company shouldn’t necessarily give onboarding assistance to the customer most likely to activate independently. A marketplace shouldn’t automatically subsidize the seller most likely to grow.

The Most Valuable Seller May Not Be Your Best Seller

This creates a slightly counterintuitive way of looking at users. For an incentive product, I roughly think about four groups.

There are the sure things who are going to perform the desired behavior regardless of what you offer them. There are the unreachable, where the incentive isn’t enough to change their decision. There are the persuables, where a relatively small intervention changes what they do. And then there is a particularly awkward fourth group: people for whom the intervention actually creates the wrong behavior.

If I were building the product, most of my attention would go toward identifying the third group.

That is not always how growth systems naturally evolve. We often reward the best customers, the highest-volume sellers, the most engaged users, or the accounts with the strongest predicted lifetime value. There can be perfectly sensible reasons to do that.

But if the objective of an incentive is behavior change, rewarding somebody because they’re already excellent may simply be an expensive way of paying for something that was going to happen anyway.

I’ve come to think one of the more useful questions a PM can ask whenever money is being used to change behavior is: What would this user have done if we had done nothing?

Unfortunately, production data doesn’t hand us that answer. We only get to observe one universe. Seller C either receives the incentive or doesn’t; we never get to watch both versions of Seller C at the same time.

That missing alternate universe — the counterfactual — is what makes the problem interesting.

Your Control Group Is Suddenly a Product Asset

This also changes how I think about experimentation.

Imagine a team launches an incentive and sees that sellers receiving it generate substantially more sales afterward. It is very tempting to declare victory.

But perhaps we targeted sellers who were already growing quickly. Maybe sales would have increased anyway.

This is why randomized control groups are more than something we use at the end to prove that a feature worked. In systems like this, they can become part of the learning infrastructure. Randomly withholding an incentive from some eligible sellers gives us something extremely valuable: examples of what happened when we didn’t intervene.

Over time, that data can support uplift models or heterogeneous treatment-effect models that try to estimate which kinds of sellers respond differently to the same intervention.

There is an uncomfortable product tradeoff here. If you believe an incentive works, deliberately not giving it to some sellers can feel wasteful. But eliminate exploration completely and eventually the model only sees the world created by its own previous decisions. At that point, it becomes harder and harder to understand what would have happened naturally.

This is where the problem starts to look less like ordinary supervised learning and more like reinforcement learning or a contextual-bandit problem.

You have context: what you know about the seller. You have possible actions: no incentive, $25, $50, a fee reduction, an advertising credit, a fulfillment credit, maybe even a non-monetary nudge. You observe a reward.

Then you have to decide how much to exploit what seems to work and how much to explore alternatives so the system keeps learning.

As a PM, I wouldn’t need to implement the bandit algorithm. But I absolutely would want to understand what behavior we’re rewarding, because that’s where things can go sideways surprisingly fast.

The Metric Will Teach the AI How to Game You

Suppose I tell the system: Maximize seller adoption of this program.

It does exactly that. Wonderful.

Except perhaps it learns that large sellers already close to adoption are cheap wins, so most of the budget flows to them.

Fine. We improve the objective: Maximize incremental adoption.

Better.

But then some sellers adopt, collect the incentive, and stop using the program a few weeks later. So we optimize for 90-day retention. Now adoption and retention look great, but perhaps the program is subsidizing behavior that isn’t economically sustainable.

We add contribution margin. Then we discover we’re systematically favoring sellers in categories where the economics happen to be easier.

This is usually the point where the PM realizes the metric wasn’t really just a metric. We had made a business-policy decision without quite calling it one.

That is why I don’t think defining the reward function for an AI system is primarily a data-science exercise. It is product strategy written as mathematics.

A marketplace might ultimately care about some combination of incremental GMV, seller retention, customer experience, contribution margin, assortment growth, and the cost of the incentive itself. Those objectives can conflict.

The model cannot decide what the company values. We have to.

Then Comes the Problem Nobody Likes Talking About: Incentive Addiction

There is a longer-term problem too.

Users learn.

Imagine Seller C gets an incentive this month and responds. Great. Next month we offer another, and then another.

Eventually we may not be teaching the seller to adopt better marketplace behaviors. We may be teaching the seller: wait until the platform pays you.

Now the treatment itself has changed future behavior.

This is where a short-term optimization system can quietly damage the economics it was built to improve. I would therefore want to measure not just immediate uplift, but what happens after the incentives disappear.

Does the behavior persist? Does the seller require increasingly large incentives? Do sellers who learn to wait for incentives now perform worse without one?

At some point, the system needs to know when to stop paying. Knowing when not to intervene may be one of its most valuable predictions.

Learnings: Moving from Prediction to Persuasion

Building AI products isn’t just about training algorithms to guess what will happen next; it’s about engineering interventions that thoughtfully shape the future. When we move beyond simple propensity modeling to embrace causal inference and uplift modeling, our definition of a successful AI system changes dramatically.

The Strategic Shift for AI PMs

• From Efficiency to Incremental Impact: Stop measuring success by how many high-value users engage with your feature. Measure success by the net-new behavior your product actually created.
• From Static Datasets to Dynamic Systems: Treat control groups, exploration budgets, and contextual bandits not as statistical chores, but as core product infrastructure that keeps your AI adaptive.
• From Predictive Accuracy to Policy Design: Remember that reward functions are strategic manifestos in code. If you don’t explicitly define what the business values long-term, the model will default to the path of least resistance — and usually the highest short-term cost.

Disclaimer: The views expressed in this article are my own and do not represent the views, positions, or opinions of my current or former employers. Any analysis of AI/ML models or product features is based on publicly available information and personal observation, not insider knowledge.

Stop Rewarding the Sellers Who Were Going to Succeed Anyway was originally published in Artificial Intelligence in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

Two teams wanted opposite things, and both of them were right.

Our end-user product team was facing a strict growth target and had one obvious lever: cut signup friction. Every extra field, every additional click standing between a user and their first review was measured attrition. They were pushing hard for a lightweight signup flow — name, email, done.

Review operations wanted the exact opposite. Their mandate was keeping platform reviews authentic and trustworthy. In their eyes, every missing signup hurdle was an open door for fake accounts and users gaming gift-card incentives with duplicate profiles. Lowering the wall meant spending the rest of the quarter playing catch-up — rejecting spam reviews retroactively, which is a far worse experience than keeping bad accounts out from the start.

Neither team was measuring the same core metric. Growth was optimizing top-of-funnel conversion; Trust was protecting output quality. Both objectives were legitimate, both had leadership support, and neither side was simply being unreasonable.

Finding the Actual Point of Conflict

The breakthrough came from asking a very simple question: where, specifically, does bad behavior actually cause damage? Not where we dislike friction or where we feel uncomfortable, but mechanically, where does a fake account break things?

It wasn’t at signup. A dormant fake account sitting idle costs nothing and hurts no one. The actual harm only happens when that account tries to publish a review — that’s the moment a spam account turns into a spam review. Signup friction was never actually safeguarding review quality; it was just the first place anyone thought to build a gate.

So we moved the gate. We kept signup minimal — name and email. Then, at the point of review submission, we introduced the friction: multi-account detection, credential verification, and the key signals review ops actually needed to keep spam out of the feed.

It’s the same logic Amazon uses: anyone can open an account in seconds, but the “Verified Purchase” tag and tighter checks kick in when the review is posted. The trust mechanism sits where the risk materializes, not at the front door.

This is the same instinct behind why Amazon doesn’t gatekeep who’s allowed to create an account before leaving a review — anyone can sign up in seconds — but it does attach a “Verified Purchase” badge at the point where the review itself is submitted. The trust signal lives where the risk actually is, not at the door.

The Outcome

Removing front-door friction drove a 22% month-over-month increase in new signups. That part was expected — it was the primary goal of the simplified login push.

What surprised review ops was that their core metric barely budged. The review rejection rate stayed flat at around 4.5%, virtually identical to the rate under the heavier signup flow. The fear that lighter signups would flood the funnel with low-quality users who would eventually pollute the platform proved unfounded. The downstream checks caught the bad actors at the point of action, rather than trying to guess intent at signup.

The Execution Takeaway

The core mistake was treating friction and trust as if they had to live at the exact same step in the user journey. They don’t.

Growth and trust aren’t naturally at war; they only clash when security checks are placed at the wrong step. Once you separate where friction hurts conversion from where risk actually manifests, you can give both teams what they need without forcing a bad compromise.

If you’re stuck in a similar cross-functional standstill, skip the abstract debates about friction versus quality. Ask both sides to point to the exact step where damage occurs. Build your gates around that specific moment, and the conflict usually resolves itself.

We Didn’t Have a Signup Problem. We Had a Gatekeeping Problem. was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

Every product leader has sat through this meeting. The core business is doing well, and someone asks: can we grow the topline by launching into adjacent areas? In tech, the question takes a familiar shape. App A has a huge user base and real product-market fit. App B is new, good, and going nowhere. Someone looks around the table and asks the obvious question: why don’t we just tell App A’s users about App B?

The instinct is always the same. A banner. A push blast. An interstitial. We have the users, the attention, the data. How hard can it be?

Well, a decade of building products across marketplaces, media tech, measurement platforms, and ad tech has taught me the answer: cross-app recommendation is not a targeting problem. It is a trust problem. Most teams point all their machinery at the first while quietly failing the second. What follows are five principles.

Why it’s worth doing

When it works, cross-promotion is the cheapest growth a company owns. The audience is warm. They already trust you. You can see what they’re doing right now, not what a focus group said last quarter. And it compounds: every successful introduction makes the next one easier, because users start treating your recommendations as discoveries rather than ads. The often-cited McKinsey figure that recommendations drive roughly a third of Amazon’s purchases is really a statement about this whole category. The most valuable attention you will ever spend is the attention you already hold.

The catch is that all of it runs on trust, and trust is spent faster than it is earned.

1. The flagship pays for every mistake.

When a cross-promotion misfires, users don’t blame the new app. They decide the old app is getting spammy. Every bad recommendation is a withdrawal from the flagship’s account, earned over years and spendable in weeks.

Relevance is the heart of the whole thing. A random recommendation fails twice. Nobody adopts the new product, because it arrived where it was not wanted. And the flagship loses trust, because it did the delivering.

For instance, in 2013, YouTube forced commenters onto Google+, a struggling social network bolted onto a beloved video platform. Users revolted. Not against Google+, which they simply ignored, but against YouTube, which they loved and suddenly trusted less. Google spent years unwinding the damage.

The pattern repeats because the failure mode is structural, not personal. In 2007, Facebook’s Beacon broadcast users’ off-site purchases to their friends without clear consent; the product died and the scar lasted a decade. In 2020, Google Play Music users were marched to YouTube Music. The migration “worked” on paper and bred resentment for years.

Google Buzz is the cleanest case. In 2010, Gmail auto-enrolled its users into a public social network built from their private email contacts. Buzz was gone within two years, and Gmail earned a twenty-year FTC consent decree. Apple ran the same play with Ping that same year, a social network bolted into iTunes that nobody asked for. Ping shut down two years later, and iTunes was left heavier and more resented. Microsoft ran it with the Windows 10 upgrade campaign, nagging Windows 7 and 8 users so aggressively that dismissing the upgrade window scheduled the upgrade. One user sued over an upgrade she never authorized and won a $10,000 judgment. In every case the destination died and the host paid. That is the full price of a random recommendation.

The takeaway: budget every experiment as a withdrawal from the flagship’s trust account. If you can’t afford the loss, you can’t afford the test.

2. Restraint beats relevance.

The reflex when a promotion underperforms is to improve targeting. Tighter segments, smarter models, better relevance. It rarely fixes anything, because the problem is almost never accuracy. It’s volume, timing, and consent. Being understood never bothered anyone. Being unable to make it stop does. Relevance is necessary, but only restraint keeps it sufficient.

In 2014, Apple pushed U2’s Songs of Innocence into half a billion iTunes libraries: the largest album release in history, free, from one of the biggest bands alive. By every targeting logic, it should have worked. Instead the backlash was so intense that Apple had to build a dedicated removal tool, and Bono spent years apologizing for it. The most sophisticated distribution apparatus on earth, aimed with zero restraint, produced one of the most resented album launches ever.

I learned the smaller version of this early in my career in retargeting, watching users feel stalked around the internet by a pair of shoes they’d browsed once. Those systems weren’t fixed by smarter models but by frequency caps, decay, and the humility to leave conversions on the table.

The takeaway: ship guardrails before models. Caps, relevance floors, and a dismissal button that actually works.

3. Borrow the host’s intent.

Here is the hard technical truth about cross-app recommendation: it’s a cold-start problem. The new content has no behavioral history in the host app, so the naive approach of stitching together user profiles across apps and ranking on identity is both creepy and ineffective. What works is ranking on what the user is doing right now.

In 2017, when WeChat introduced mini-programs, it didn’t try to build a unified taste profile to recommend them. It anchored discovery in the conversation you were already having: the chat you’re in, the search you just ran, the shop you’re standing near. A sprawling mix of services, ranked by live context instead of historical identity.

In 2019, Spotify went all-in on podcasts and faced the same wall from the other side: music-taste vectors don’t rank podcasts. Skips and replays in lean-back listening say almost nothing about appetite for a 90-minute interview. So podcast discovery leaned on session context (what you’re listening to, when, and in what mode) plus topical and creator signals native to the medium. Years of recommending a different medium inside the music flow built a podcast audience most dedicated apps never reached.

The general rule: don’t ask “who is this user across our apps.” Ask “what are they trying to do in this moment, and does the new thing help.”

The takeaway: rank on host-context intent, not cross-app identity. It’s more effective and less creepy. No tradeoff required.

4. Give a taste, earn the meal.

Nobody owes your new product their audience, their full attention, or their trust. The first ask should be small and obviously worth it; each kept promise buys the right to a bigger one. Never the reverse.

At Gartner, inside Peer Insights, I once proposed promoting the research articles through partial reads. Enough for a user to feel the research’s value, never enough to substitute for the subscription. The product logic was straightforward; the ranking problem was genuinely hard. The teaser had to match the reader’s domain and function, and it had to be fresh: trending this week, not canonically important. Miss freshness and you have a library. Miss relevance and you have noise. Getting both right, for a user we’d only just met in the app, was the whole game.

I’d learned the earning instinct earlier taking a cloud TV platform into the U.S. market as an unknown, where every placement was negotiated on the strength of a clear value exchange. I’d used the same instinct on signup flows: a lite login upfront, deeper verification only at the point of contribution. Conversion and trust both held, because neither was asked to pay for the other in advance.

The takeaway: start with the smallest high-confidence cohort and the smallest defensible ask. Grow like a stain, not a flood.

5. Land inside the workflow.

The fanciest optimization in the world dies in a dashboard nobody opens. Recommendations get adopted the same way tools do: when they show up inside a motion the user already trusts, at the moment they’re already deciding.

At Kantar, we built a campaign feasibility calculator that cut media-measurement planning from two to three weeks to under an hour. It spread to hundreds of U.S. advertisers, agencies, and publishers. Not through promotion, but because planners could feel the before-and-after inside their own workday.

At Walmart, the same lesson held closer to the metal: pricing tools for marketplace sellers (min/max suggestions, meet-or-beat pricing, restore-price) only got adopted when the suggestions landed inside the seller’s existing decision moment, framed in terms they already trusted. Nothing about the model changed. The placement was the whole difference.

A cross-app recommendation is a placement problem before it’s a ranking problem. “Try our new app!” is a billboard. “The people you message here are already there” is a bridge.

The takeaway: frame the new thing in the old thing’s currency, and put it where the decision already happens.

Cross-Promotions North Star Metric

If you take one measuring discipline from this piece, make it this: stop optimizing clicks. Hold out a control group and keep it held out. The metric is incremental retained users on the new app per thousand host-app impressions, net of any engagement cost to the host.

I think of the honest unit as cost per welcomed discovery: total cost (engineering, consumed surface, risked trust, opted-out users) divided by the users who stayed and would say the recommendation was worth receiving. Click-through rate will happily lie to you about this for quarters. Cost per welcomed discovery won’t.

Learnings

Across every case, the promotions that worked respected the user before they targeted them. Three lessons: trust is the budget. Every experiment is a withdrawal from the flagship’s account, so decide up front what you can afford to lose. Guardrails ship before models. Caps, relevance floors, and a dismissal that works fix what users actually resent. Measure welcomed discovery, not clicks. Keep a control group held out.

Framework: The Welcomed Discovery Checklist

Does the flagship pay if this misfires?

Would the user thank you for less of it?

Does it borrow the host’s intent, not the user’s identity?

Does it give a taste before asking for the meal?

Does it land inside the workflow, not beside it?

Run the checklist before you touch the model. The model provides the relevance. Restraint decides whether anyone trusts it.

Cross-Promotion Isn’t a Targeting Problem. It’s a Trust Problem. was originally published in Active Minds Hub on Medium, where people are continuing the conversation by highlighting and responding to this story.

I got escalated. Not vaguely, not in some diplomatic Slack message — a vendor operations lead went over my head, straight to my director, because I’d let two of his team’s requests sit in my backlog for a full quarter without discovery or grooming.

He wasn’t wrong to do it.

Here’s what had actually happened, and it’s a more common failure mode than most product managers like to admit: I had gotten pulled into an AI-based review quality control system we were piloting. It was technically interesting, it was the kind of project that gets talked about in leadership reviews, and — this is the part I had to own — it played directly to my own background. I have an engineering bent, and an AI pilot scratches a very specific itch for someone like me. So while I was deep in model evaluation and pilot metrics, two straightforward, unglamorous asks from vendor operations — new fields on an onboarding page — sat untouched. Not because they were hard. Because they weren’t exciting, and I’d let “exciting” quietly outrank “committed.”

Amazon’s Fire Phone is the textbook version of this failure at a much bigger scale: a team that got seduced by a flashy differentiator — a 3D parallax display nobody had asked for — while the fundamentals the product actually needed to compete on shipped underbaked. The scale is different, but the mechanism is identical. Shiny work crowds out committed work when nobody’s actively guarding the door.

The Meeting I Didn’t Want to Have

My first instinct, in the hour after I found out about the escalation, was defensive — go find my director first and get ahead of the narrative. I didn’t do that, and I think it was the right call not to. Instead, I went to the vendor ops lead directly and just acknowledged it, plainly: I had deprioritized his team’s asks without ever telling him I was doing it, and that silence was worse than the delay itself. If I’d flagged it — “this is getting pushed two sprints, here’s why” — he’d have had something to plan around. Instead he’d been watching a queue not move, with no visibility into why, until he ran out of patience.

What I Actually Changed

The fix wasn’t complicated, which is usually a sign the original mistake wasn’t either. I freed up my own bandwidth by stepping back from day-to-day testing on the AI pilot, which didn’t need me in the room for every cycle. I set a standing weekly touchpoint with the vendor ops team’s discovery work, so their requests had a guaranteed slot instead of competing informally against whatever felt most interesting that week. And I finished the discovery and grooming that had been sitting untouched, inside the timeline I’d quietly blown past.

None of that undid the fact that someone had needed to escalate me to get my attention. But it changed what happened next.

The Part I Didn’t See Coming

Months later, that same vendor ops lead became one of the people I’d actually go to for a straight read on a decision — the kind of colleague you stay in touch with well after either of you changes teams. At a team lunch, long after the incident had stopped mattering operationally, he told me his side of it: he hadn’t wanted to escalate, he’d tried two rounds of gentle nudges first, and going to my director had felt like the only lever left that would actually move something.

That’s the detail I keep coming back to. Escalation, from the other side of the table, usually isn’t a first move. It’s the last one. By the time someone escalates you, they’ve almost always tried the quieter version already, and you probably missed it — because you were somewhere else, working on the thing that felt more interesting that week.

The skill I actually took from this wasn’t “respond well to being escalated.” It was upstream of that: read the room early enough that nobody has to escalate you in the first place. Notice when a queue has stopped moving before the person waiting on it decides silence means you don’t care. The best version of this skill is invisible, because it prevents the story from ever needing to be told.

The Escalation That Became a Friendship was originally published in Technology Hits on Medium, where people are continuing the conversation by highlighting and responding to this story.

Six weeks after an acquisition closed, the org chart looked settled. The reality was anything but. We had acquired an enterprise software reviews platform and were beginning the work of folding its users into our own. From a distance, the plan looked straightforward: retire the acquired product, redirect its users, unify login, and gradually bring the experience under one roof. Then we got to verification.

Both platforms needed to answer essentially the same question: Is this a real person, and can we trust the review they are submitting? But they had spent years arriving at very different ways of answering it.

Our existing verification process was deliberately rigorous, with thresholds and controls adjusted over time as we learned what kinds of abuse, fraud, and edge cases could make their way through the system. The acquired company’s process was faster. It relied on a different set of checks, served a different population, and had evolved around a different risk profile.

Seen side by side, the temptation was obvious: one of these processes had to become the standard. That assumption nearly sent us in the wrong direction.

We Thought We Had to Pick a Winner

Mergers create pressure to simplify. Two systems become one company. Two products become one roadmap. Duplicated tooling, duplicated workflows, and duplicated teams can quickly begin to look like unfinished integration.

There was also another dynamic in the room that would have been easy to ignore. One team belonged to the acquiring company. The other came from a product we were planning to retire. Those are not equal positions, and nobody had to say, “Our way wins because we acquired you,” for organizational gravity to begin pulling the decision in that direction.

The problem was that neither process was obviously disposable. The slower process had years of operational learning embedded in it, but so did the faster one. Both had been shaped by real users, real abuse patterns, real tradeoffs, and real failures.

A mature process is rarely just a sequence of steps; it is often institutional memory encoded as workflow.

A threshold may exist because something once got through. An exception may exist because an earlier rule broke. A manual review may exist because automation failed in a way somebody still remembers.

Choosing either system immediately therefore carried a cost we could not yet measure.

Choosing ours might erase knowledge the acquired company had accumulated.

Choosing theirs might discard safeguards our own team had learned the hard way.

Building a hybrid would create a third process that nobody had ever operated under real conditions.

Every path seemed to lead back to the same question: Whose process wins? Eventually, it became clear that the question itself was the problem. The two teams did not necessarily need to agree on how verification happened. They needed to agree on what verification produced. That distinction changed the entire conversation.

The Trap Was in the Question

Product teams routinely collapse three different things into one: the outcome, or the state that should exist when the work is complete; the definition, or what that state actually means; and the process, or the sequence of steps used to produce it.

We had jumped immediately to the third question — Which process should survive? — without spending enough time on the first two.

So I met with the teams separately. The point was not to negotiate or to ask one group to respond to the other group’s arguments.

I wanted to remove the process itself from the discussion. I asked each team a version of the same question: Without telling me how your workflow works, what states can a user ultimately be in?

The answers were strikingly similar. Both teams converged on roughly four states: unverified, verified, rejected, and banned.

That was the opening we needed, but agreeing on four labels was not enough. Two teams can both use the word “verified” and still mean different things. One might mean, “We have evidence that this is a real human being.” Another might mean, “We have evidence this is a real human being with sufficient standing to review this product.” Those are not interchangeable claims.

The real work was therefore to establish the meaning behind the labels. What had to be true for a user to be called verified? What distinguished rejection from a temporary failure to verify? What behavior justified a ban? Where were the boundaries?

Once those definitions were explicit, something important became possible: we could have one definition of done without having one process for getting there.

Standardize the Contract Before the Machinery

In software terms, we standardized the interface before standardizing the implementation. Two systems do not need identical internal architectures to work together; they need to agree on the contract at the boundary. Our shared outcome states became that contract.

One verification system could remain slower and more rigorous while the other continued using its faster path. As long as both returned the same well-defined outcome states, the rest of the product did not need to care how each one reached them. Nobody had to abandon years of accumulated tuning under merger pressure, and nobody had to learn an unfamiliar workflow simply because the org chart had changed. The combined product could still behave coherently.

There is a familiar version of this in consumer technology. When large platforms combine products, they do not always rebuild every underlying system before presenting users with a unified experience. Billing, identity, search, catalogs, licensing, and infrastructure can remain different behind the scenes while the customer sees one account, one bill, or one entry point. The backend can remain messy for a while, provided the surface is coherent.

We were doing the same thing at a smaller scale. The important question was not whether the machinery underneath was identical. It was whether the organization could rely on what came out of it.

Then Something More Valuable Happened

Ending the argument was useful, but it was not the most important consequence. The shared definition of done gave us something we had not had before: a fair basis for comparison.

Before that point, both systems had effectively been playing on different scoreboards. One team could say its approach was safer, while the other could say its approach was faster. Each had its own history, thresholds, assumptions, and measures of success, and those differences could be debated indefinitely.

Once both processes began producing the same defined outcome states, the debate changed. We could ask which process reached those outcomes faster, which maintained quality, which created more operational burden, which handled volume better, and which generated fewer bad approvals or unnecessary rejections. For the first time, the teams could be evaluated on the same terms.

The result surprised us. The newer, faster process began outperforming the older one across the performance and quality measures that mattered to us. One reason was architectural: it ran a number of vetting steps in parallel rather than waiting for them sequentially.

That finding did not come from negotiation, seniority, or one team being more persuasive in a meeting. The shared definition made the difference visible. Months later, one approach did become the standard, but it became the standard because it performed better — not because we had decided, six weeks after an acquisition, that standardization itself was the goal.

Delaying the Decision Was Part of the Decision

There is a tendency to interpret temporary coexistence as indecision. Sometimes it is. In this case, it was a way of sequencing the decision.

Immediately after an acquisition, leaders are often under pressure to make permanent choices at exactly the moment when they know the least about the combined organization. Systems get retired, processes get eliminated, teams get consolidated, and terminology gets rewritten. The pressure is understandable because integration has costs, and duplicated systems can be expensive.

But not every duplicated process represents waste. Sometimes duplication preserves information.

Keeping both verification processes temporarily gave us optionality. Eliminating one would have been much harder to reverse, and because we did not yet understand every reason each process had evolved the way it had, preserving both gave us time to learn before destroying either one. That is not an argument against standardization. It is an argument against premature standardization.

The sequence mattered: align, coexist, compare, learn, standardize.

This Wasn’t Really a Communication Problem

There is another lesson in what happened. We did not solve the disagreement by scheduling more stakeholder meetings. We solved it by making the language more precise before the next meeting happened.

Organizations often treat misalignment as a communication-volume problem. The response is more meetings, more documentation, more status updates, and more stakeholder syncs. But ten meetings will not solve a disagreement if the people in the room are using the same word to mean different things.

Product organizations are full of words like this: “active,” “qualified,” “ready,” “complete,” “verified,” “retained,” and “done.” Every one of them can create the illusion of alignment. A shared taxonomy of four states did more for us than another round of argument about workflow because it gave everyone language they could rely on.

Alignment depends not only on how often teams communicate, but on whether the words they use carry the same meaning.

Why This Isn’t Just a Conflict-Resolution Story

The tempting takeaway from this story is “find common ground.” That is true, but it is too soft to be especially useful.

The more specific lesson is to identify which layer of the problem the teams actually disagree on. They may disagree about implementation, workflow, tooling, sequencing, or ownership while already agreeing on the outcome, success state, customer promise, or acceptance criteria.

That distinction matters because process is where people have often invested years of tuning, judgment calls, and institutional memory. Asking a team to abandon its process is not simply asking it to use a different checklist. It may mean discarding expertise the organization has not yet learned how to value.

There was also a power dimension we could not ignore. The acquiring company had the structural ability to make its own process the default. Had we done that immediately, organizational authority could easily have been mistaken for product evidence. Allowing both systems to remain in place long enough to compare them gave us a different basis for deciding what should survive.

In the end, the faster process became the standard because it demonstrated better results on shared terms. That outcome was easier to trust precisely because it was not predetermined by which side of the acquisition it came from.

A Framework for Process Deadlocks

The experience left me with a practical sequence I would use again when two teams appear stuck on competing processes.

First, ask each team to describe what “done” looks like without allowing them to describe how they get there. Then identify the outcome states both processes need to produce and define those states precisely; shared labels are not enough if the meanings underneath them differ.

Next, map each existing process to that shared definition. If both processes can operate behind the same contract, resist the urge to collapse them merely because two systems feel untidy. Measure both against the same outcomes, and standardize when the evidence makes the tradeoff clear.

The point is not to preserve two processes forever. It is to avoid choosing one before you understand what you are choosing between.

Two Teams Can Still Have One Definition of Done

When two teams are deadlocked over process, determine whether they are actually deadlocked over the outcome. Sometimes they are. If one team believes “verified” means one thing and another believes it means something fundamentally different, you have uncovered a product or strategy disagreement that needs to be resolved explicitly.

But sometimes the outcome is already shared and the conflict exists one layer lower. The teams agree about what ultimately is true; and they disagree about how to make it true. When that happens, forcing conformity can destroy expertise before the organization has learned from it.

One definition of done gives you another option. You can preserve different processes long enough to make them comparable, and once they are comparable, evidence can tell you whether they should remain different or eventually converge.

That is what happened. Two teams with different histories, different operating models, and different verification processes found a common definition of done. Only after we had that, we could we see clearly enough to determine which process deserved to become the standard.

Many thanks to Tremis Skeete, Executive Editor of Product Coalition, for his invaluable contributions to this story. A special shout-out to founder Jay Stansell for creating an environment that enhances product management education.

The Merger That Got Stuck on One Word was originally published in Product Coalition on Medium, where people are continuing the conversation by highlighting and responding to this story.