Mahnoor Khan
Product Manager · Product Marketing ManagerFour B2B SaaS and AI products built at Programmers Force. Go-to-market for 7+ identity, fraud and AML products at Shufti. Same person, both halves.
I'm Mahnoor, a Product Manager and Product Marketing Manager working on B2B SaaS, RegTech and AI products, based in Lahore. I graduated from UMT as a Silver Medalist, and research has shaped how I work ever since: I question a source before trusting it, which turns out to be good training for compliance data.
I joined Programmers Force as an Associate Researcher on business-registry data and was promoted three times in a year: Product Analyst, Associate Product Manager, then Product Manager. There I've worked on four products and got hands-on with the technical side: MongoDB, APIs, SQL, testing ML models, and building a front end with AI tools.
Today I'm at Shufti, taking 7+ identity, AML and fraud products to market. Because I've built products, I can explain them properly to Sales and buyers, and take what buyers say back to Product.
Five products. Click one for the full story.
Track what the world says about a brand, a person or a topic.
Screen people against sanctions, PEP lists and adverse media.
Verify identities, stop fraud and screen for AML, in one platform.
Know if a business is real, active, and who owns it.
An AI agent that doesn't just answer. It finishes the task.
One loop, six stages: from a signal in the market to the field telling me what to fix next.
Everything else, one click away.
Email, WhatsApp or LinkedIn. Whichever is easiest for you.
Five roles in two and a half years. Each one is written up below as release notes: what shipped, what improved, what I owned.
Shufti · London, UK · Remote · Contract
Programmers Force · Lahore
Programmers Force · Lahore
Programmers Force · Lahore
Programmers Force · Lahore
BS Gender Studies · Lahore
What I can own on day one, as a Product Manager or a Product Marketing Manager, and the skills underneath both.
Set direction for four products at the same time, each with a different buyer.
Customer calls, prospect demos and competitor teardowns turned into requirements Engineering can build.
New products built from assets we already had. V1 proves the value; V2 gets the rest.
API inputs and outputs, data mapping, scoring logic, SQL and MongoDB. I test models and AI agents myself.
20+ features shipped with Engineering, Design and a 20+ person research and data team.
Framework-led positioning that makes a crowded category easier to choose from.
End-to-end GTM for 7+ products, from first research to the launch kit.
Training, battlecards and demo collateral for sales teams of 30+ reps.
Gartner, Liminal and G2 briefings, demos and submissions that ended in recognition.
100+ website pages rewritten, awareness campaigns, webinars and a case-study framework.
All B2B SaaS.
Every product I work on runs through the same loop. It starts with a signal in the market and ends with the field telling me what to fix next. Then it starts again.
A competitor posts a job for an AI engineer. A changelog quietly adds a feature. An analyst redefines the category. I read all of it: websites, API docs, release notes, reviews, hiring posts, and reports from Gartner, Forrester, Liminal and G2 on how buyers are told to evaluate the category.
Is it a real differentiator, or just a claim? What would it cost us to build, and what does it save the customer? When a competitor offered bulk processing, one request instead of hundreds of API calls, the saving for clients made the case. When two or three prospects ask for the same thing in demos, it goes on the roadmap. One product's V1 started exactly that way.
Scope is set with Engineering against what customers actually asked for, and anything that doesn't prove the value waits for V2. Before release I test it myself: the data, the models, the AI agent output.
The launch date is agreed with Product first, and the go-to-market plan works back from it. Internal teams get the launch kit before launch, so their questions come up in a Slack thread instead of on a customer call.
Every product gets its own sales training and live-call support. Recognition is planned like a launch: I map the events and reports competitors appear in, check the evaluation criteria, request the briefing, and close capability gaps before the demo. One analyst briefing reshaped how we positioned a product still in development.
15–18% → ~1% demo errors after training
Win/loss and pipeline are tracked in the CRM. What Sales hears goes straight into the feature-gap list, and every two quarters we re-run the go-to-market for live products with fresh research. Which takes me back to step one.
Up to 40% more pipeline deals within a few months of launch
I'd rather take longer than ship something I have to walk back.
AI runs the operations; strategy stays with me. Everything it produces gets read and checked before it reaches anyone, and I hold my team of 10+ to the same standard.
Handed 2.4 million news URLs in a database I had never used, I learned MongoDB and cleaned them within a day. Blockers get flagged the day I find them.
A client asked us to delete records we were required to keep.
Monitoring social media raised a fair question: what happens to people's posts?
RhythmDaily stand-ups with the VP and team · monthly cross-department reviews · a quarterly company-wide meeting
“Hand her something she's never touched before, give it a week, and she's the one explaining it to the room.”
Hamza Khan ↗Technical Product Manager · Managed me directly · Programmers Force“She knew the products properly, not just the talking points, so her positioning held up in front of technical buyers who asked hard questions.”
Muhammad Jiad Ali Cheema ↗Product Manager & Business Analyst · Worked together, different teams · Shufti“She consistently brought a strong research mindset to her work, analysing target markets, ICPs and competitors, and translating those insights into clear positioning and value propositions.”
Daniela Marin ↗Global tech GTM · Same team · Shufti“I've watched her build products from ground zero and bring them to life at incredible speed, without ever cutting corners on quality.”
Muhammad Zahid ↗Product Designer · Same team · Programmers Force“Mahnoor is the definition of “i will handle it” no matter the bug is bigger than a mountain.”
Bakhtawar Bokhari ↗Product Marketing · Same team · ShuftiAdverse-media screening needs a constant feed of news and the processing to read it. That already existed inside AML Watcher, and so did its cost. Media Watcher asked a simple question: who else would pay for it?
Teams that need to know what's being said about a brand, a person or a topic, across news and social, were the obvious answer. Adding social meant paid platform APIs, and running AI on every post added a second cost, so each source had to justify what it cost to bring in. In-house ML models were trained to cut what we spent on GPT and other third-party AI.
A media monitoring tool. You choose keywords and the platforms to watch, results come back grouped by channel, and a dashboard shows what's being said, with an Influence Score and a Sentiment Score for each mention.
How the idea took shape.
Deciding what waits.
Getting the data in.
Where the coverage comes from.
Sentiment is scored at three levels: each person or entity, each topic, and the whole article. Every mention also gets an Influence Score.
What a user does every day.
The views a media monitoring tool needs.
Shipping fast.
3 major clients signed in the first three months.
Media Watcher is the first product where I did both jobs: pricing research and competitor demos on the market side, API costs and sentiment testing on the build side, and then the demo calls with buyers.
No client names, API costs or model details. Visuals are recreated with dummy data.
Before a bank, fintech or crypto business onboards a customer, it has to check them against sanctions lists, PEP lists, watchlists and adverse media. AML Watcher does that screening for compliance teams.
Screening fails in two directions. Miss a real match and a sanctioned person gets onboarded. Flag too many and analysts spend their day clearing noise, which makes a real hit easier to miss.
Names cause most of the noise. One person can appear in different scripts, transliterations and spellings, with or without diacritics, or under a former name or alias. A common name like Muhammad Ali returns a long list of possible matches. The source data adds its own problems: incomplete records, inconsistent formatting, and lists that don't normalise cleanly.
One search screens a person against sanctions, PEP, watchlist and adverse-media data. Matches come back scored, and analysts review them in case management. Ongoing monitoring re-checks customers over time, and everything is available through an API.
Matching logic built for how names really vary: phonetic variants, diacritics, Arabic-to-Latin transliteration, prefixes and suffixes, and alias or AKA detection.
Designed from scratch on three parameters: Country risk (FATF grey and black lists, Corruption Perceptions Index), Database risk (PEP level, sanctions status, watchlist recency) and Criminal activity risk (adverse-media sentiment). Clients set the weights, thresholds and risk appetite per jurisdiction.
From keyword hits to a context-aware, sentiment-analysed, multilingual engine. NLP and entity extraction work out the role of each person mentioned in a story.
1:1 facial image matching against AML databases, giving reviewers another signal alongside the name match.
Screening sanctioned crypto wallets, taking the product into DeFi.
Sanctions, adverse-media and watchlist data behind every search.
How we compared, and how we could look and work better.
The screens analysts use every day, including case management and comments.
A false positive is a screening hit that turns out not to be the person being checked. Fewer false positives means clients spend less time clearing wrong matches in their results.
This is where I stopped looking at data like a researcher and started looking at it like a PM. The question changed from "what's wrong with this record" to "which problem costs the analyst the most time, and should we fix it first."
When I later wrote AML positioning at Shufti, I already knew what a false-positive rate means to an MLRO, and that name matching is the first thing a buyer tests in a demo.
No client names, thresholds, source lists or product screenshots. Visuals are recreated with dummy data.
Shufti sells identity verification, AML, fraud and compliance products to enterprise buyers who hear similar claims from every vendor.
Each product has its own buyer, its own competitors and its own technical depth. Product marketing had to make each one clearly different, give Sales a story that holds up in a demo with a technical buyer, and keep Product hearing what buyers say.
A portfolio of 15+ identity verification, AML, fraud and compliance products. I run go-to-market for 7+ of them: facial biometrics, document verification, age verification, AML screening, KYB, Transaction Monitoring and more. I also co-own Transaction Monitoring with Product.
Every launch goes to market twice: inside, so Sales can defend it in a demo, and outside, with core Marketing.
The same seven-step process for every product.
Research on 20+ competitors, done the way a careful buyer would.
One story for fraud and AML: Shufti as one platform instead of two separate capabilities, so the value of buying both from one vendor is easier to see.
In compliance sales, the demo is where a buyer tests whether the vendor knows its own product.
Research, collateral and deal analysis were eating the week, so I built agents for the repeatable parts.
Judged by compliance officers who know the rules better than most vendors. Scoping it and selling it need the same AML knowledge, so I co-own it with Product.
Taking products outside, with core Marketing.
A demo error is a mistake caught in our QA review of every sales demo: a feature or product shown inaccurately, or a client concern not handled the way it should have been.
Most product marketers learn the product from the PRD. I'd written PRDs, so I could bring buyer feedback back to Product in terms they could act on, and keep our claims close to what the product really does.
No pricing, deal details, client names, rules or internal dashboards. Visuals are recreated with dummy data.
Before a business can be onboarded, you need to know it's real, active and who owns it, and not a shell or an inactive company.
That means finding its registration number, tax ID, status history, filings and beneficial owners. The information is split across country, state, province and local registries. Some charge and some are open. Some offer an API or a bulk data dump. Others mean searching a portal by hand.
For one company that's slow. At onboarding volume it doesn't work.
Enter a company's name or details and get the available official records in one place: registration number, tax ID, status and history, documents, and ownership or UBO information where the registry provides it. UBOs can then be screened for sanctions and other risk.
Where the data comes from.
Getting access, then getting it in.
Making every source line up.
A feature that came out of client calls.
Making it work, and work well.
Where we stood.
This lets me talk to KYB buyers in their own terms: UBO depth, how fresh registry data is, and which jurisdictions are API-backed and which aren't.
No provider names, pricing or contract terms. Visuals are recreated with dummy data.
Barie started as an idea for a better deep-research assistant: stronger sources, fewer hallucinations. But the research tools already out there could search and summarise, and then stop. Someone still had to finish the work.
As MCP made it possible for AI to connect to real tools, the bigger opportunity became an agent that does the job, not one that only reports on it. An agent like that is harder to build and harder to judge. The question was how we'd know when it had really finished a task.
An AI agent that performs tasks, not just research. You give it a job; it plans the steps, picks the tools it needs, reads, checks and acts across connected apps, remembers context between sessions, and delivers a finished result.
Where Barie should go.
What Barie should do.
Did it actually do the task?
Fixing what went wrong.
Proving multi-step reasoning, not just fluent answers.
Reading and acting across business apps from one conversation.
Testing demand before spending on growth.
Prompt design, model behaviour and task execution depend on each other. That changed how I think about requirements for any AI feature.
At Shufti I build my own agents for research and collateral. Barie is where I learned to check an agent's output before trusting it.
No client names or model details. Visuals are recreated with dummy data.