# Ali Manasra

> Ali Manasra is Lead Product Manager at Al Jazeera Media Network with 10+ years of experience across media, SaaS, travel and AI/ML. He founded Al Jazeera's AI Lab, leads its AI strategy and digital product portfolio (website, mobile apps, streaming), and previously built the Product Management function at Maqsam and led airline e-commerce, AWS migration and API platform work at Expedia Group.

Source: https://alimanasra.com · Last updated 2026-10-07

## Fact sheet

- **Role:** Lead Product Manager
- **Company:** Al Jazeera Media Network
- **Based:** Amman · working in Doha
- **Experience:** 10+ years
- **Focus:** AI, data, complex platforms
- **Sectors:** Media · SaaS · Travel · Fintech
- **Languages:** Arabic · English
- **Studying:** DBA, Acacia University
- **Email:** ali_manasra@hotmail.com
- **LinkedIn:** https://www.linkedin.com/in/alimanasra

## About

I work where ambition meets organizational reality: unclear opportunities, emerging technology, and teams that don't share the same definition of done. My job is to turn that into direction people can act on, and into products that survive contact with the real world.

I'm Lead Product Manager at Al Jazeera, where I founded the AI Lab and run the website, mobile apps and streaming platform. Before that I built the product function at Maqsam and shipped airline commerce at Expedia.

## Experience

### Lead Product Manager, Al Jazeera Media Network

Mar 2024 — Present · Doha, Qatar

Leading AI strategy and the digital product portfolio: web, mobile apps and streaming.

- Own the portfolio of digital products (website, mobile apps and streaming platform) and align roadmaps with editorial and business priorities.
- Led the company's AI strategy and founded the AI Lab, raising AI literacy across teams and introducing GenAI workflows for writing, translation, media search and content packaging.
- Operationalized LLMs and open-source model stacks with structured evaluation, prompt governance, MCP and MLOps (model lifecycle, deployment and scaling).
- Delivered AI prototypes into newsroom workflows, improving publishing efficiency and cutting manual work through automation and workflow orchestration.
- Modernized the CMS into a unified headless platform and coordinated vendor and technology integrations for performance, stability and scalability.
- Use Python, SQL, Power BI, Tableau and Amplitude for analysis, feature measurement and product decisions.

### Senior Product Manager, Maqsam

Dec 2021 — Mar 2024 · Amman, Jordan

Built the Product Management function from zero at a cloud communications startup.

- Pioneered and led the Product Management department, establishing foundational practices and growing the team from inception.
- Integrated AI and ML into the product, enhancing functionality and user engagement by more than double.
- Used analytics to improve platform reliability and minimize payment failures, lifting customer satisfaction and loyalty.
- Led the migration to Stripe as the primary payment gateway, improving payment reliability and optimizing the prepaid credit flow.
- Introduced Agile methodologies that improved lifecycle efficiency and team productivity.
- Ran customer discovery calls that drove product improvements and reduced customer turnover.

### Senior Product Manager, Expedia Group

Sep 2017 — Dec 2021 · Amman, Jordan

Airline e-commerce, an AWS cloud migration and the API platform, at global scale.

- Led the design and delivery of a new B2C and B2B experience for the airline e-commerce platform, improving client satisfaction and engagement.
- Directed the transition of infrastructure from traditional data centers to AWS, improving operational efficiency and reducing overhead.
- Drove technical programs for IT infrastructure and operations, using automation and machine learning for efficiency gains.
- Helped shape the vision, strategy and roadmap of the API platform.
- Oversaw numerous A/B testing initiatives to refine and optimize product features.
- Applied Agile digital transformation to evaluate and improve business processes and system efficiency.

### Product Manager, iMENA Group

Sep 2016 — Sep 2017 · Amman, Jordan

Delivered B2B products for the MENA region and the go-to-market behind them.

- Managed multiple B2B projects focused on the MENA region.
- Contributed to go-to-market strategies for more than five products.
- Built SQL and Tableau visualizations for product ROI and KPIs, saving 8 hours of manual reporting per week.
- Supported operational and strategic marketing plans and planned digital campaigns across web, SEO/SEM, email, social and display.

### Product Analyst, Electronic Health Solutions

2014 — 2016 · Amman, Jordan

Where it started: hospital information systems and the full product lifecycle.

- Supported cross-functional teams across the product lifecycle, from inception to rollout.
- Expanded and modified the hospital information system to meet new objectives and improve workflow.
- Documented workflows and requirements through FRS, SRS and BRD documents.
- Analyzed data with statistical methods to produce business reports for decisions and strategy.

## Selected work

### Founding an AI Lab inside a global newsroom

Al Jazeera Media Network · 2024 — now · AI strategy · GenAI · LLMOps

Defined the company's AI strategy and founded the AI Lab, moving GenAI from prototypes into the daily workflows of editorial teams.

- Raised AI literacy across teams so that adoption had a shared language, not just a pilot.
- Introduced GenAI workflows for writing, translation, media search and content packaging.
- Operationalized LLMs and open-source model stacks with structured evaluation, prompt governance, MCP and MLOps practices.
- Shipped AI prototypes into newsroom workflows, improving publishing efficiency and reducing manual work through automation and workflow orchestration.

Highlights: Founded the AI Lab; AI literacy across teams; GenAI in newsroom workflows; Evaluation and prompt governance

### Building a product function from zero

Maqsam · 2021 — 2024 · 0→1 team · AI/ML · Payments

Pioneered the Product Management department at a communications startup and used data and AI to raise engagement and reliability.

- Established the foundational practices of the department and grew the team from inception.
- Integrated AI and ML into the product, enhancing functionality and engagement by more than double.
- Led the migration to Stripe as the primary payment gateway and optimized the prepaid credit flow.
- Used analytics to improve platform reliability and minimize payment failures; customer discovery calls reduced turnover.

Highlights: Built the product team from day one; AI/ML that more than doubled engagement; Stripe payment migration; Discovery calls that cut churn

### Airline commerce, cloud and APIs at Expedia scale

Expedia Group · 2017 — 2021 · B2C + B2B · AWS · API platform

Redesigned the airline e-commerce experience, moved infrastructure to the cloud and helped define the API platform strategy.

- Led a new B2C and B2B experience for the airline e-commerce platform, improving satisfaction and engagement.
- Directed the transition from traditional data centers to AWS, improving efficiency and reducing overhead.
- Contributed to the API platform's vision, strategy and roadmap.
- Oversaw numerous A/B tests and used Agile transformation to improve processes and systems.

Highlights: New B2C and B2B airline experience; Data centers to AWS; API platform strategy; A/B testing program

## Skills and domains

- **AI & data:** Generative AI, LLMOps, MLOps, Prompt governance, MCP, Python, SQL, Power BI, Tableau, Amplitude
- **Product:** Product strategy & vision, Roadmapping, A/B testing, Discovery, Market research, Go-to-market
- **Platforms & leadership:** Headless CMS, API platforms, AWS migration, Payments, Agile transformation, Cross-functional leadership

Topics: Product management, Product strategy, Generative AI, Large language models, LLMOps, MLOps, AI strategy, Headless CMS, Digital platforms, API platforms, Cloud migration, Payments, Data analysis, A/B testing, Agile transformation, Media technology.

## Education

- Doctor of Business Administration (DBA), Acacia University (2026 — 2030), In progress
- Professional Certificate, Leadership and Management, London School of Business Administration (2026), In progress
- MSc, Business Consulting & Analysis, University of Strathclyde (2018 — 2020)
- MSc, Strategic Management, University of Sussex (2018 — 2020)
- Bachelor's, Engineering, Al Ahliyya Amman University (2008 — 2014)

## Certifications

- AWS Certified SysOps Administrator
- Microsoft Power BI
- Splunk Certified User
- Business Analysis
- Entrepreneurial Bootcamp

## Publication

- Blind Assistive Technology Based on Android Platform (Published research)

## Frequently asked questions

### Who is Ali Manasra?

Ali Manasra is a product leader with 10+ years of experience across media, SaaS, travel and AI/ML. He is Lead Product Manager at Al Jazeera Media Network, where he leads AI strategy and manages the website, mobile apps and streaming platform. Earlier he built the Product Management department at Maqsam and was a Senior Product Manager at Expedia Group.

### What does Ali Manasra do at Al Jazeera?

Since March 2024 Ali has been Lead Product Manager at Al Jazeera Media Network in Doha. He owns a portfolio of digital products (website, mobile apps and streaming), led the company's AI strategy, founded the AI Lab, and modernized the CMS into a unified headless platform.

### What is Ali Manasra's experience with AI and LLMs?

Ali founded Al Jazeera's AI Lab and introduced GenAI workflows for writing, translation, media search and content packaging. He has operationalized LLMs and open-source model stacks using structured evaluation, prompt governance, MCP and MLOps practices, and earlier integrated AI/ML at Maqsam, where engagement more than doubled.

### Which companies has Ali Manasra worked for?

Al Jazeera Media Network (Lead Product Manager, 2024 to present), Maqsam (Senior Product Manager, 2021 to 2024), Expedia Group (Senior Product Manager, 2017 to 2021), iMENA Group (Product Manager, 2016 to 2017) and Electronic Health Solutions (Product Analyst, 2014 to 2016).

### What are Ali Manasra's strengths as a product leader?

Turning ambiguous opportunities into clear product direction; evaluating technology by customer and business value rather than novelty; and creating alignment between editorial, engineering, data, operations and leadership. He is data-driven (Python, SQL, Power BI, Tableau, Amplitude) and experienced in Agile transformation and A/B testing.

### Is Ali Manasra open to new roles or advisory work?

Yes, selectively. Ali is open to senior product leadership conversations in AI, data and complex platforms, and to advisory work on AI product strategy and platform transformation. The fastest way to reach him is ali_manasra@hotmail.com or LinkedIn.

### Where is Ali Manasra based and what languages does he speak?

Ali is based in Amman, Jordan, and currently works with Al Jazeera Media Network in Doha, Qatar. He speaks Arabic (native) and English (full professional proficiency).

### What is Ali Manasra's education?

Ali holds an MSc in Business Consulting & Analysis from the University of Strathclyde, an MSc in Strategic Management from the University of Sussex and an engineering bachelor's degree from Al Ahliyya Amman University. He is currently pursuing a Doctor of Business Administration at Acacia University and holds AWS, Power BI and Splunk certifications.

## Articles

### What I'd tell anyone starting an AI Lab inside a newsroom

https://alimanasra.com/ideas/founding-an-ai-lab-in-a-newsroom · 2026-10-07

> **The short version**
>
> - Start with AI literacy. Teams that understand what models can and can't do bring better use cases.
> - Pick workflows, not tools. Writing, translation, media search and content packaging each have an owner and a definition of "good".
> - Treat evaluation and prompt governance as part of the product, not paperwork you add later.

At Al Jazeera I led the AI strategy and founded the AI Lab. A newsroom is one of the hardest places to introduce generative AI: accuracy is the product, deadlines are real, and the people who will use the tools are experts in their craft. Here is what I'd tell anyone starting a lab in a similar environment.

## Why a lab, and not just a few tools?

Tools arrive on their own. Any team can sign up for something this week. What does not arrive on its own is a shared way to decide which use cases deserve effort, how they are tested, and what "good enough to publish" means.

A lab is that shared mechanism. It gives AI work a home, a method and a place for lessons to accumulate, so the tenth experiment benefits from the first nine instead of repeating them.

## Start with literacy

The first investment I'd make is in understanding, not software. If editors, producers and engineers use the same words for what a model can do, where it fails, and why it can sound confident when it is wrong, the conversations about use cases get much better.

Literacy also changes the quality of requests. People who understand the technology stop asking for "an AI that writes the news" and start describing concrete jobs: a first-draft summary, a translation that keeps names and quotes intact, a way to find relevant footage in an archive. Those are jobs you can build, test and improve.

## Pick workflows, not features

A workflow has an owner, an input, an output, and a person accountable for the result. That makes it testable. The GenAI workflows I introduced covered writing, translation, media search and content packaging. None of them is glamorous. All of them are real work that takes time, and in each one a human can review the output before anything reaches an audience.

The test I use for a candidate workflow:

- Is there a clear task that happens often enough to matter?
- Can a domain expert tell, quickly, whether the output is good?
- What happens when the model is wrong, and who catches it?
- Does the workflow still make sense if the model gets worse, or if the provider changes?

## Make evaluation and prompt governance part of the product

Demos hide the question that matters in production: how do you know it works, and how will you know when it stops working?

I'd build two habits from the beginning. The first is structured evaluation: a set of representative examples, reviewed by the people who know what good looks like, that every change is measured against. The second is prompt governance: prompts are versioned, reviewed and owned, the same way code is. When a prompt changes, you can see who changed it, why, and what happened to quality.

Neither habit is exciting. Both are what allow a prototype to be trusted by the people who have to rely on it.

## Keep editorial judgment in the loop

In a newsroom the principle is simple: AI adds leverage, people stay accountable. That has design consequences. Review steps should be built into the workflow, not left to goodwill. Outputs should be easy to check against sources. And the interface should make it obvious which parts were machine-generated.

When teams see that a tool respects their judgment, adoption follows. When they suspect it is trying to route around it, no amount of training helps.

## Run it like a product, not a project

Once a workflow is live, the job changes. You are now responsible for the model lifecycle, deployment and scaling: the MLOps side of the work. That includes choosing between hosted models and open-source stacks, deciding how models connect to tools and data (this is where protocols such as MCP help), and watching quality over time.

I'd also keep one rule: every workflow needs a named owner and a way to show that it reduced manual work or improved publishing efficiency. If you can't say what got better, you haven't shipped yet.

## A first-quarter checklist

- Run a literacy program before you run pilots.
- Choose three or four workflows with clear owners and reviewers.
- Write the evaluation set with the people who will use the output.
- Version prompts, and decide who is allowed to change them.
- Define the human review step and make it part of the interface.
- Pick one metric per workflow and report it honestly.

A lab succeeds when AI stops being a separate topic and becomes part of how the work gets done.

### Migrations are product work: cloud, payments and CMS

https://alimanasra.com/ideas/migrations-are-product-work · 2026-10-07

> **The short version**
>
> - A migration has customers. Name them before you plan anything.
> - Define "no worse" first. Parity is the first release; improvement comes after.
> - Sequence by risk and reversibility, not by what looks tidy on an architecture diagram.

I've been responsible for three migrations in three industries: moving Expedia's infrastructure from traditional data centers to AWS, moving Maqsam's payments to Stripe as its primary gateway, and modernizing Al Jazeera's CMS into a unified headless platform. The technology was different every time. The reasons they succeed or stall were remarkably similar.

## A migration has customers

It is tempting to treat a migration as an engineering project with a product manager attached. I find it works better the other way round. Every migration changes someone's day: the engineers who run the system, the support team who answer questions, finance who reconcile the numbers, the editors who publish, and the end users who just want things to work.

For each group I write down three things: what they do today, what must not break, and what gets better. That list becomes the success criteria and the communication plan.

## Define "no worse" before "better"

Before you migrate anything, measure the baseline: reliability, failure rates, speed, cost to operate. Then make parity the first goal. A migration that cannot show it is no worse than what it replaces is not ready, however elegant the new design is.

On the Stripe migration at Maqsam, the goals were payment reliability and a cleaner prepaid credit flow. A reliability goal only means something if you can see how payments fail today, so a clear failure baseline has to exist before the cutover, not after it.

## Sequence by risk and reversibility

Architecture diagrams suggest an order that is tidy. Risk suggests a different one. I prefer small slices that carry real traffic, with every step reversible and a rollback that has been rehearsed. Keep both systems alive for as long as you need to. And don't promise a final date until the first slice has run in production.

## Payments deserve extra care

When money moves, trust is fragile. The questions I'd always ask on a payments migration:

- **What are the failure types?** Declines, technical errors and abandoned checkouts need different fixes, so separate them.
- **What are the balance edge cases?** With prepaid credit: top-ups, partial failures, retries, refunds.
- **Can a retry ever charge twice?** Idempotent requests are the answer.
- **Who reconciles the numbers?** Finance should see the new reports before cutover, not after.
- **How will you know within minutes if something is wrong?** Monitoring belongs in the first slice.

## Cloud migrations are about the people who run the system

Moving from data centers to AWS is often described in terms of efficiency and reduced overhead, and those are real benefits. But they only arrive if the teams who operate the system are ready: new skills, clear ownership, new ways of working. I treat those teams as the users of the migration and plan for their adoption as carefully as I would for a customer-facing launch.

## CMS migrations are workflow migrations

For a newsroom, the editorial workflow is the product. A headless platform lets one content system serve the website, mobile apps and streaming, which is a real strategic gain. But it only counts if the day-to-day experience for editors stays fast and familiar.

Much of the work is coordination: vendors and technology partners need clear integration contracts, and performance, stability and scalability need owners. I measure the migration by whether publishing gets easier, not by whether the new architecture is clean.

## Communicate like it's a launch

Write release notes for internal users. Hold office hours. Keep a visible status. Say plainly what changes for each group and when. In my experience, much of the friction in a migration comes from surprises rather than from the technology.

## The measure of success

The best migrations are boring. Nobody remembers the cutover; they notice, months later, that things are faster, steadier or cheaper to run. That is the outcome to design for, and it is a product outcome.

### Building a product function from zero: what to put in place first

https://alimanasra.com/ideas/building-a-product-function-from-zero · 2026-10-07

> **The short version**
>
> - Start by listening to customers, before you write a process.
> - Make ownership and decision rights explicit.
> - Keep the cadence light, measure early, and let structure grow only when it earns its place.

At Maqsam I pioneered the Product Management department, establishing the foundational practices and growing the team from inception. Starting a product function is a different job from running one. There is no inherited playbook to follow, so every habit you introduce becomes the culture. Here is what I'd put in place first.

## Begin with customer conversations

Before any framework, I'd talk to customers. At Maqsam, discovery calls led to customer-focused product improvements and lower customer turnover. It is a practice worth building into any new function from the first week.

A few habits make these calls useful:

- Ask about situations and workarounds, not features. "Tell me about the last time this went wrong" beats "Would you use X?"
- Listen for the effort customers already spend to solve the problem themselves.
- Record patterns, not just quotes, and share the raw words with engineers and designers.

## Make ownership explicit

Early product functions lose time to unclear decisions more than to anything else. I write down, on one page, who decides what: product owns the what and the why, engineering owns the how, and anything in between has a named person. When two people disagree, it is clear who decides, and everyone knows they can disagree openly first.

## Choose a cadence you will keep

I introduced Agile ways of working, which improved the efficiency of the product development lifecycle and team productivity. The lesson I took from it is to start with the smallest set of rituals that produce decisions:

- A weekly planning conversation.
- A regular demo so progress is visible.
- A short retrospective so the process improves.
- Quarterly priorities that everyone can repeat.

If a ritual doesn't change a decision, drop it.

## Measure before you optimize

Instrument the product early, even crudely. At Maqsam, analytics helped improve platform reliability and reduce payment failures, which in turn improved customer satisfaction and loyalty. Metrics don't need to be sophisticated. What matters is that they exist before the debates start.

Choose a handful: reliability, activation, engagement, and one that reflects customer value. Review them regularly, and use them to decide, not to decorate a slide.

## Write down how you decide

Prioritization is where a new function either earns trust or loses it. I use a simple frame of impact, effort and confidence, with explicit room for strategic bets. The scoring is not the point. The point is that people can see the reasoning, challenge it, and learn how decisions are made. (If you'd like to try it, the roadmap game on the [home page](/#playground) is a small version of the same exercise.)

## Grow the team for judgment

Process can be taught; judgment takes longer. When the team grows, I look for curiosity, clear thinking and comfort with ambiguity, and then teach the practices by doing the work together rather than handing over a document.

## Avoid process theater

A new function is tempted to prove itself with templates, ceremonies and dashboards. Resist it. Customers, engineers and the leadership team should feel that product work makes decisions faster and better. If it makes them slower, something has gone wrong, however well-organized it looks.

### From ambiguity to direction: the seven steps I use

https://alimanasra.com/ideas/from-ambiguity-to-direction · 2026-10-07

> **The short version**
>
> - Most product work starts as noise: competing asks, unclear owners, messy data.
> - Seven steps take it from there to something adopted: opportunity, evidence, direction, alignment, execution, adoption, impact.
> - Each step has a question to answer, something to produce, and a trap to avoid.

Across media, SaaS, travel and AI, the situation I'm asked to help with looks similar: there is a real opportunity, but the path is tangled, technically or organizationally. This is the sequence I use to untangle it. (There is an interactive version in the [Approach section](/#approach) of the home page.)

## 1. Opportunity

**The question:** What problem is worth solving, and for whom?
**What I produce:** A short problem statement that someone outside the team can understand.
**The trap:** Starting with a solution. "We need AI" is not an opportunity; "editors spend hours on a repetitive task" is.

## 2. Evidence

**The question:** What do users, data and operations actually tell us?
**What I produce:** A baseline: a few numbers from analytics and SQL, plus what customer conversations reveal.
**The trap:** Collecting evidence to confirm a plan you've already made. Look for what would change your mind.

## 3. Direction

**The question:** What is the thesis, and what is the first bet?
**What I produce:** A product thesis, a short list of priorities, and, just as important, what we are not doing.
**The trap:** A roadmap that is only a list of features. Direction explains why these things, in this order.

## 4. Alignment

**The question:** Who needs to agree for this to work, and on what?
**What I produce:** A shared definition of success, named owners and the decisions that are still open.
**The trap:** Consensus theater. Alignment is not everyone liking the plan; it is everyone knowing what they are doing and why.

## 5. Execution

**The question:** What is the smallest coherent version that can create value?
**What I produce:** A scoped release, with experiments or A/B tests where the answer isn't obvious.
**The trap:** Scope that grows because nobody wants to say no. Small and coherent beats big and late.

## 6. Adoption

**The question:** Will people actually use it, and trust it?
**What I produce:** A rollout plan: training, champions inside the teams, and a feedback loop that works.
**The trap:** Declaring victory at launch. If it isn't embedded in real work, it hasn't shipped.

## 7. Impact

**The question:** Did the outcome change?
**What I produce:** Honest measurement against the baseline from step 2, and a decision: reinforce or rethink.
**The trap:** Vanity metrics. Choose the one that would convince a skeptic.

## Why a sequence helps

Skipping steps is where most initiatives get into trouble. Teams jump from opportunity to execution and discover, late, that nobody agreed on success, or that the people who need to use the product were never part of the plan.

The sequence also makes ambiguity less frightening. You don't need certainty to begin. You need the next question, and the next thing to produce.

### From prototype to production: why AI demos stall

https://alimanasra.com/ideas/from-prototype-to-production · 2026-07-29

> **The short version**
>
> - A prototype answers "is there something here?" Production asks whether it can be trusted, supported and measured.
> - AI work stalls in four predictable places: ownership, workflow change, evaluation and success criteria.
> - Before each step forward (prototype, pilot, production), ask four plain questions about ownership, measurement, failure and daily use.

Prototypes answer a useful question: *is there something here?* Production asks different ones. Can this be trusted? Can it integrate into real work? Can teams support it? Can we measure whether it creates durable value?

Moving AI from prototype to production is part of my day job at Al Jazeera, where I operationalize LLMs and open-source model stacks and bring AI prototypes into newsroom workflows. In my experience, the hard parts are rarely the model.

## Where it stalls

**Ambiguous ownership.** Product, data and engineering each assume another team owns the outcome. Name one accountable owner for the workflow, and make clear what the other teams are responsible for.

**Underestimated workflow change.** A model that works in a notebook still has to fit into how people actually work: the tools they use, the approvals they need, the deadlines they face. The change to the workflow is often the larger task.

**Weak evaluation and feedback loops.** If you can't tell whether quality is improving or degrading, you can't operate the system. This is where structured evaluation and prompt governance earn their keep.

**Success criteria that celebrate demos.** "It impressed the leadership team" is not a measure. Choose an outcome tied to the work, such as less manual effort or better publishing efficiency.

## What "production-ready" means

Beyond the model itself, I look for:

- **Reliability:** a known quality level, and a known fallback when it isn't met.
- **Evaluation:** a representative test set, reviewed by domain experts, re-run on every change.
- **Governance:** versioned prompts and models, clear access rules, and a record of what changed.
- **Monitoring:** quality, cost and latency are visible, with someone watching.
- **Support:** a named owner and a path for users to report problems.

## Run it as a lifecycle

Production AI is an operating model, not a launch. The model lifecycle runs on: deploy, monitor, update, roll back. That is the MLOps side of the work, and it needs owners and routines like any other service. Decide early who handles model updates, who reviews quality, and how a change gets promoted.

## Make adoption part of the plan

Even a reliable system fails if people don't use it. I plan adoption alongside the build: training, champions inside the teams, and a short feedback loop so users see their input change the product. In newsroom workflows, I aim for AI that reduces manual work and fits into how editors already publish, rather than asking them to change tools.

## A simple promotion test

Before moving from prototype to pilot, and from pilot to production, I ask four questions:

1. **Who owns it?** One name, not a committee.
2. **How do we measure it?** One metric, with a baseline.
3. **What happens when it fails?** A fallback, and someone who will notice.
4. **Who uses it on Monday?** A real person, in real work.

If the answers are clear, the move is usually safe. If they're not, the gap is rarely technical, and it is the work worth doing next.

### Practical AI product strategy: five questions before you build

https://alimanasra.com/ideas/practical-ai-product-strategy · 2026-07-15

> **The short version**
>
> - Start with the job to be done, not the model's capability.
> - Check that the data, the process and the people are ready before you build.
> - Ship the smallest coherent product that can earn trust, and say "not yet" when the conditions aren't there.

Most AI conversations start with capability: what the latest model can do. Useful product conversations start somewhere else, with the job, the workflow that holds it, and the organizational conditions needed for adoption. Having led AI strategy at Al Jazeera, and overseen the integration of AI and ML into the product at Maqsam before that, these are the five questions I ask before any AI idea earns a place on the roadmap.

## 1. What decision, task or workflow becomes meaningfully better?

Name the job. Who does it today, how long does it take, and what does it cost when it goes wrong? Then define what "better" means: faster, more accurate, less risky, or something people couldn't do before.

If you can't say it in one sentence, you don't have a use case yet; you have a technology looking for a problem.

## 2. Is the data and the process ready?

AI is only as useful as the data it can reach and the workflow it can slot into. I look at both:

- **Data readiness:** Is the data accessible, reasonably clean, permitted for this use, and current enough to matter?
- **Process readiness:** Does a stable workflow exist? AI can't fix a process nobody agrees on.

When the data isn't ready, the first product is often the work that makes it ready. That's less exciting than a demo, and much more valuable.

## 3. Where does human judgment sit?

Decide, deliberately, where a person reviews, approves or overrides. The cost of an error should set the design: when it is low, automate more; when it is high, let the model draft and the human decide.

Make the review step part of the interface. If it relies on goodwill, it will disappear under deadline pressure.

## 4. Build, buy, or assemble?

There is rarely one right answer. Hosted models, open-source stacks and vendor products trade off control, cost, privacy, speed and lock-in differently. I've worked with both LLMs and open-source model stacks, and the practical rule I follow is to decide with evidence: build a small evaluation set and compare the options on your own tasks, not on someone else's benchmark.

## 5. What is the smallest coherent product that can earn trust?

Pick one workflow. Define how you will evaluate it. Put a human review loop around it, choose one metric, and ship that. Trust is the scarce resource in AI products; you earn it with something small that works reliably, then expand.

Delivering AI prototypes into newsroom workflows is a good example of the target: less manual work and better publishing efficiency inside the workflow people already follow, not a demo that impresses a room.

## Knowing when to wait

Part of strategy is saying "not yet." I'd hold an AI idea when:

- nobody owns the workflow it would change,
- the data isn't accessible or permitted,
- the cost of an error is too high for the current level of reliability, or
- the problem isn't painful enough to justify the change.

Novelty is easy to demo. Value is harder to operationalize. The work of product leadership is bridging that gap with clarity, sequencing and restraint.

## Contact

- Email: ali_manasra@hotmail.com
- LinkedIn: https://www.linkedin.com/in/alimanasra
- Instagram: https://www.instagram.com/alimanasra/