The GCC Product Discovery Playbook: Interviews, Signals and Fast Validation

Product discovery continuously identifies which customer problem deserves attention and which solution can create value without unacceptable business, usability, technical or regulatory risk.

In GCC markets, discovery needs additional discipline. A few English interviews in Dubai cannot represent customers in Riyadh. A B2C survey cannot explain enterprise procurement. Arabic preference, family or organisational roles, payment methods, regulation and service expectations may change the problem and the solution.

The goal is a repeatable rhythm that reduces the largest uncertainty before the next decision.

Begin with an outcome and decision

Start every discovery cycle with two statements:

• Outcome: the customer behaviour or value signal the team wants to improve.
• Decision: what the team must decide next and by when.

For example: “Increase the share of qualified Saudi customers who complete their first workflow. Decide within six weeks which onboarding opportunity deserves a bet.” This keeps research focused on relevant evidence.

Write the baseline, target direction and guardrails. A faster onboarding journey should not create more errors, support work or privacy risk.

Build a deliberate GCC sample

Recruit users who match the research question. GOV.UK guidance recommends explicit criteria, inclusive recruitment and privacy protection; a typical interview or usability round may include four to eight participants.

That number is a round, not proof that every segment is understood. Track coverage across variables that could change behaviour:

• Saudi Arabia versus UAE
• City or region where relevant
• Arabic, English or bilingual preference
• Customer, user, approver and administrator roles
• Company size and sector
• Digital confidence and accessibility needs
• New, active, inactive, lost and prospective customers

Do not combine segments until evidence shows similar needs. Collect only required participant data and obtain informed consent for recording or observation.

Run story-based interviews

Use a flexible discussion guide, but ask about real events rather than hypothetical preferences. GOV.UK advises open, neutral questions and a focus on stories and concrete examples.

Useful prompts include:

• Tell me about the last time you tried to complete this task.
• What triggered it, and who was involved?
• What did you do first, then what happened?
• Where did you wait, repeat work or ask for help?
• What information or approval was missing?
• What happened when it failed?
• Which language and channel did you use at each stage?

Avoid showing the solution too early. “Would you use an AI assistant?” invites speculation. “Show me how you handled the last enquiry” reveals workflow, workarounds and consequences.

A shared interview snapshot should capture the story, actors, context, opportunity, evidence strength and open questions—not feature requests.

Triangulate interview stories with signals

Qualitative research explains why; behavioural and operational data help show where and how often. Combine interviews with:

• Funnel and workflow completion data
• Search and navigation behaviour
• Form errors and abandoned steps
• Support tickets, chats and call reasons
• Sales objections and lost opportunities
• Retention, repeat use and cancellation reasons
• Delivery time, manual work and failure rates

Check instrumentation before trusting a pattern. Missing events, mixed definitions or language-switch behaviour can distort the result.

Respect each source’s limitations. Support overrepresents people who ask for help; sales notes may describe prospects; analytics shows behaviour but not motivation. Convergence strengthens confidence.

Map opportunities before selecting solutions

Organise evidence in an opportunity solution tree:

1. Outcome at the top
2. Customer needs, pain points or desires beneath it
3. Possible solutions under a chosen opportunity
4. Assumption tests under each solution

The structure prevents the first idea from becoming the plan and keeps solutions connected to customer value.

Write opportunities in the customer’s context: “I do not know which documents my company must prepare” is more useful than “build a document checklist.” The first leaves several solutions open.

Prioritise opportunities using frequency, severity, strategic fit, underserved evidence and the team’s ability to influence the outcome. Do not use interview vote counts as market size.

Generate multiple solutions

For the chosen opportunity, involve product, design and engineering in generating distinct approaches. Include service and process changes, not only software features.

A slow enterprise onboarding problem might need clearer requirements, a guided workflow, reusable templates or better handoff. Building the largest solution first wastes discovery.

Define the riskiest assumption for each idea:

• Value: Will the customer care enough to change behaviour?
• Usability: Can the intended user understand and complete it?
• Feasibility: Can the team build and operate it reliably?
• Viability: Does it work with economics, policy, sales and service?
• Ethics and compliance: Could it create unfair, unsafe or prohibited outcomes?

Match the test to the assumption

Strategyzer recommends making the hypothesis precise and selecting participants relevant to the idea. Use the smallest credible test:

• Message or fake-door test for interest, with honest disclosure
• Clickable prototype for comprehension and usability
• Concierge service for workflow and value
• Technical spike for integration or performance
• Data review for volume and segment patterns
• Paid or contracted pilot for commitment and delivery economics

Define the hypothesis, participant, method, threshold, guardrails and decision before running the test. A prototype compliment is weak evidence. Successful task completion is stronger. Repeat use, data access, a signed pilot or payment demonstrates greater commitment.

One test rarely validates an entire solution; build confidence across its riskiest assumptions.

Test Arabic and English as product contexts

Test both language experiences before release: right-to-left layout, terminology, mixed text and numbers, search, forms, help and handoffs.

Ask whether language changes who participates in the decision. An English-speaking product user may need an Arabic executive summary for an approver. A consumer may discover in Arabic, compare in English and complete through WhatsApp.

Store language and market as research attributes, but avoid stereotypes. Let observed behaviour determine whether experiences should differ.

Establish a weekly discovery rhythm

A practical cadence is:

• One or more customer touchpoints each week
• A weekly product-trio synthesis session
• Continuous opportunity-map updates
• One active assumption test at a time per major bet
• A monthly evidence and outcome review

Product Talk case studies show teams using weekly interviews, frequent experiments and opportunity maps to connect customer and business needs. Start smaller if needed: one interview every two weeks is better than a quarterly research event that never influences a decision.

Keep searchable interview snapshots, experiment cards, consented evidence, product signals and decision history. The repository matters only if it changes prioritisation.

Use a clear decision gate

At the end of a cycle, choose:

• Advance: evidence supports a bounded solution or pilot.
• Adapt: the opportunity is important, but the approach needs change.
• Explore: evidence is mixed and the next uncertainty is identifiable.
• Stop: the opportunity or solution does not justify more investment.

Record why. Discovery creates value when it prevents weak work as well as when it identifies strong work.

DEMA helps GCC product teams connect customer research, analytics, experiments and commercial strategy. Request a free growth audit or book a free consultation to build a discovery rhythm that turns local evidence into better product bets.