← All product projects

Flagship case · Project 02

Price & Market Intelligence Platform

The customer saw pricing intelligence. Underneath it was a decision-and-trust system that had to classify sources, clean data, combine matching signals, route uncertainty to people and continuously challenge its own outputs.

OrganisationA retail price and market-intelligence SaaS company
RoleProduct Manager
Period2018–2020
StageProduction customer SaaS and internal data-operations platform
≈40monitored websites
10countries
≈200kproduct records
20customers
40internal reviewers
Evidence key

Every product visual is labelled by provenance, so original work is never confused with a portfolio-created explanation.

Original Product Artifact Surviving source material from the product work.

A genuine working document, wireframe, screenshot or output that can be shown publicly.

Portfolio Reconstruction Recreated from documented product logic using synthetic or anonymised content.

A recreated product view grounded in the original work, using synthetic or anonymised information.

System Explainer Created for this portfolio to explain product logic; not product UI.

A simplified model created for this portfolio to explain system behaviour, workflow or product logic.

01

Problem underneath the request

Collecting prices was the easy part. Trusting that two records represented the same product was the real product problem.

The same physical product could appear with different titles, images, identifiers, currencies, categories, variants and promotional structures. A false match could turn directly into bad commercial intelligence. The platform therefore had to optimise for scale without pretending that every decision could be automated with equal confidence.

B2B SaaS · Retail intelligence · Competitive pricing · AI/ML · Data platforms

01 Source variability

How should this source be processed?

Retailers, marketplaces, brand sites and comparison sites behave differently.

02 Data quality

Is this record safe to use?

Missing prices, broken URLs, currencies, duplicates and anomalies need explicit handling.

03 Match confidence

How certain is the product link?

Text, metadata, identifiers, images and models contribute different signals.

04 Human judgement

Where should automation stop?

Ambiguous and high-risk cases need specialised review and later quality control.

02

My role

I worked across the complete data-product stack — not only the customer dashboard.

I owned product strategy, roadmap and customer discovery across source acquisition, data quality, automated matching, human review, internal operations, analytics, APIs and the customer SaaS. The work required coordinating engineering, data science, operations, Sales and Customer Success because customer quality depended directly on the internal production system.

01

Product strategy, roadmap and customer discovery

02

Source acquisition and crawling workflows

03

Data-quality and anomaly-management product requirements

04

AI-assisted matching and confidence routing

05

Human-review and quality-control operations tooling

06

Customer SaaS, analytics, APIs and cross-functional delivery

03

Product system model

Automation creates scale. Confidence decides the route. Human operations create trust where certainty runs out.

The customer-facing experience was the final layer of a longer intelligence pipeline. Quality had to be designed into every step because a polished dashboard could not repair incorrect underlying matches.

System Explainer Portfolio-created model of the product system · not product UI
Retailers Marketplaces Brand sites Comparison sites
01AcquireSource-aware crawling
02NormaliseClean structure and metadata
03Quality gateReject unsafe records early
04MatchRules + text + images + ML
Decision routerConfidence changes the path.
High confidenceAutomate
Uncertain / high riskHuman review
Mismatch signalRe-check
05ValidateReviewer judgement + history
06Quality controlChallenge accepted matches
07Customer intelligencePrice · promotion · assortment · geography
04

Two products · one trust chain

The intelligence product had another product operating beneath it.

The customer-facing SaaS was the visible endpoint. The internal data-operations product produced, inspected and challenged the intelligence before it became something a customer could trust.

The recovered wireframes are used below only where they support a product decision. The complete source set remains available in the artifact archive.

Internal data-operations platform Produce and challenge the intelligence.

Source operations, automation visibility, exception control, matching support and continuous quality workflows.

Validated product intelligence
Customer intelligence SaaS Turn trusted data into commercial decisions.

Pricing, promotions, assortment, brand and geographic market intelligence.

05

Evidence integrated with product decisions

The evidence matters when it explains why the system had to work this way.

Three product problems show how source strategy, confidence routing and quality operations worked together as one trust system.

01
Product problem · Source variability

Heterogeneous sources needed an operating model.

Retailers, marketplaces, brand sites and comparison sites behaved differently. Source classification therefore shaped crawling, monitoring and cleaning before records entered the intelligence layer.

System Explainer Portfolio-created model of product logic · not product UI
01
Acquisition strategy

Source classification model

Separated source types so crawling and quality strategies could reflect how each source actually behaved.

02
Product problem · Automation uncertainty

Automation needed observable human control.

Matching combined rules, text, metadata, identifiers, images and models. Confidence determined whether a case could automate or needed reviewer judgement.

System Explainer Portfolio-created model of product logic · not product UI
02
Decision workflow

Confidence-routing workflow

Used confidence and risk to decide what could automate, what needed review and what required re-checking.

03
Product problem · Quality drift

Quality problems needed investigable control surfaces.

Accepted matches could degrade as products, prices and sources changed. Operators needed filters, context and corrective actions to investigate anomalies and challenge earlier decisions.

System Explainer Portfolio-created model of product logic · not product UI
03
Operational feedback model

Continuous quality-control loop

Allowed accepted matches to be challenged, corrected and fed back into the operating system.

06

Artifacts and source evidence

The evidence is now integrated into the decisions. This cabinet preserves the source trail.

Original wireframes remain inspectable in full resolution, while the portfolio-created system explainers stay clearly distinguished from source artifacts.

01 Anonymised Original Product Artifact

Price-intelligence operations wireframes

3 anonymised original wireframes covering platform architecture, automation visibility and anomaly-control operations.

02 System Explainers

Source, confidence and quality models

Three explanatory models are embedded directly beside the product decisions they clarify rather than repeated here as a second gallery.

Explore the broader artifact library
07

Outcome and evidence

Observed outcomes

What changed in the operating system around the product.

01

Faster customer onboarding through better source and configuration workflows.

02

Reduced manual matching work by focusing reviewers on uncertain cases.

03

Better match quality and fewer incorrect price comparisons through layered quality controls.

04

Expanded use cases beyond price monitoring into promotions, assortment, overlap, brand and geographic intelligence.

05

Improved operational throughput across a multi-country data pipeline.

Evidence boundary

Working customer SaaS and internal operations platform. Observed operational improvements are described conservatively; no unsupported percentage claims are presented.

08

What the work changed in how I think

The product shipped. The operating lessons travelled further.

01

AI accuracy is a system property.

Model performance alone is not enough; thresholds, review workflows, auditability and feedback loops determine real-world quality.

02

Human-in-the-loop works when humans handle uncertainty.

Reviewers create leverage when they focus on ambiguous cases rather than repeating deterministic work.

03

Internal tools create external quality.

Poor operational tooling increases errors, onboarding time and time-to-insight for customers.

04

Trust comes before sophistication.

Advanced analytics have limited value if the product relationships underneath them cannot be relied on.

Original Product Artifact

Wireframe

Open original ↗