From fragmented pricing work to system-ready decisions
I took an internal pricing product from 0 to 1, from discovery to a phased regional rollout: a single source of truth for commercial conditions, a self-serve app to consult them and build quotes, and an approval workflow with a full audit trail that turns approved changes into ERP-ready records.
Role
Product owner in practice, 0→1: discovery, requirements, data model, UX and workflow design, pilot, internal GTM
Outcome
Pilot, then a phased rollout across several regional consolidations; in operational use
Shipped
Single source of truth, self-serve consultation and CPQ-style quoting, approval workflow with audit trail
Built with
Low-code: Power Apps and Power Automate on Microsoft Power Platform
Reconstructed product view
From self-serve lookup to approved change, with guardrails
A regional user reviews their conditions and proposes a change; margin guardrails and the audit trail are visible before anything reaches the master data.
Pricing review
Illustrative region · synthetic data
Review in progress
RegionRegion A
Customer groupGroup 2
DestinationChange event
Pricing familiesProposed changes
3 illustrative rows
Illustrative proposed pricing changes and their margin guardrail checks
Family
Change
Guardrail
Record
Family A
Discount revised
Passed
Queued
Family B
Discount raised
Review
Held
Family C
Comment added
Passed
Queued
Problem statement and product bet
Commercial conditions sat in data silos (regional matrices, local records and the ERP) with no single source of truth, inconsistent margin rules, margin-leakage risk and no audit trail of who changed what, or why.
The bet: fix data quality before automating anything, then separate read from write: self-serve consultation for everyone, one maker–checker workflow for every change.
01 · Problem space
The pricing matrix was not one thing
It was a mix of data, business rules, exceptions and tribal knowledge, split across regional matrices and the ERP and maintained by different people. Consulting, updating, reconciling or auditing a condition depended on knowing where to look and whom to ask: a textbook key-person dependency.
Reconstructed problem model
Pain point 01
No single source of truth
Observed condition
Some discounts existed in the ERP but not in the commercial records, others the reverse, and some in both with different percentages.
Product implication
Garbage in, garbage out: data quality had to come before automation.
Pain point 02
Discount sprawl and margin-leakage risk
Observed condition
Material-level discounts sprawled without review, margin rules differed by region, and some discounts pushed the theoretical net margin below the agreed floor.
Product implication
Margin guardrails had to live in the product, not in a later report.
Pain point 03
No audit trail, heavy tribal knowledge
Observed condition
Who changed a condition, why, and whether it reached every system was hard to establish, and reading the data depended on specific people.
Product implication
Every change needed an owner, a reason and a status, and the data needed metadata a non-specialist could read.
Jobs to be done
What users needed to get done
Find their conditions
Understand them
Propose a change
Build a quote
The fragmented matrixWhere discrepancies and margin-leakage risk accumulated
Governance requirements
A single source of truth
Reconciled records
Margin guardrails
Normalised identifiers
Audit trail
02 · Discovery
From product vision to data requirements
I pitched the product vision: replace the regional matrices with one governed architecture, keyed by region, customer group and commercial criteria. I then ran requirements elicitation, translating commercial needs into the entities, fields and relationships the data and ERP teams could extract. The result was a data-requirements spec, not a request for a download.
Reconstructed discovery model · findings paraphrased
01
Frame the opportunity
Problem, target users, value proposition and strategic direction in one proposal: fragmented maintenance; Marketing, Pricing, commercial and regional teams; centralised control and faster updates; one governed architecture.
02
Write the data-requirements spec
Sales office, region, pricing family, product hierarchy, price list, customer group, discount value, and material-level identifiers where they applied.
03
Model the domain
An entity model linking organisation, sales offices, pricing families, tariff types, margin criteria, materials, customer hierarchies, discounts, theoretical net margin and usage by operational centre.
04
Separate evidence from assumption
The discrepancies were documented; their financial magnitude was not. Confirmed findings stay separate from unquantified impact.
Riskiest assumption 01
Automation would fix the data
Interpretation
Automating access to unreliable data would only spread its errors faster.
Implication
Data quality first; build the self-serve layer on a clean source.
Riskiest assumption 02
Everything should be standardised
Interpretation
Some local conditions had a legitimate commercial reason and no regional consensus to remove them.
Implication
Standardise the core, configure the edge: keep justified exceptions, explicitly.
Riskiest assumption 03
A periodic audit report would be enough
Interpretation
A report finds a margin or value problem after the condition is already live.
Implication
Shift left: put guardrails where a change is proposed and approved.
03 · Data quality
Data quality before scale: five audit increments
Before automating how the data was used, I made it reliable. I shipped the clean-up as five incremental audits, each de-risking one dimension of data quality, and ran them as federated data stewardship: every accountable owner received their filtered records, a keep / correct / remove decision field, instructions and a deadline. Each agreed decision became a structured change record.
Reconstructed audit sequence
01
Completeness: does the record exist?
Conditions present in the ERP but missing from the commercial records, and the reverse.
02
Accuracy: is the value right?
Records held in both places with different percentages, reconciled side by side with the variance calculated.
03
Validity: is the exception still justified?
Material-level discounts reviewed one by one, then retained, corrected or deprecated.
04
Business rules: does the margin logic hold?
Margin criteria compared across regions, and discounts that took the theoretical net margin below the floor flagged, including strategically priced items that needed their own margin rule.
05
Metadata: can a non-specialist read it?
Commercial comments added and sales-family descriptions rewritten, so the data no longer depended on tribal knowledge.
Standardised: the core
Records, values and margin rules
Existence, discount values, margin criteria and descriptions now follow one standard.
Configured: the edge
Justified exceptions
Where a location had a legitimate commercial requirement and no regional consensus existed, the exception stayed, documented rather than hidden.
Deprecated
Unjustified conditions
Discounts that were no longer commercially justified were retired through the same structured change records.
04 · Solution
Three layers, one governed flow
With a clean source, I designed the solution as three decoupled layers with a clear separation of concerns, built low-code on Power Apps and Power Automate. Business users self-serve complex pricing rules without ever touching the data model underneath.
Reconstructed product architecture
Data layer
A single source of truth
The golden record for matrices, regions, customer groups, families, materials, discounts and margin criteria: validated, synced with the apps and decoupled from the UI.
Experience layer
Self-serve consultation and quoting
Conditions sliced by region, office, centre, customer group, family, material, price list and margin criterion; material-level exceptions nested under their family; and a guided, CPQ-style flow to a structured commercial proposal.
Workflow layer
Maker–checker change control
Propose, justify, review, approve: a human-in-the-loop, four-eyes flow. Changed values are flagged automatically, and approved changes become change events for the ERP with requester, timestamp and decision.
Decision 01
Separate read from write
Why
Most users needed read access and quotes, not write access to master data; uncontrolled writes were where untraceable changes came from.
Instead of
Shared files with everyone as an editor.
Decision 02
Guardrails in the flow, not reports after it
Why
Margin rules and validation run before a change is submitted and approved, and role-based access control (RBAC) protects critical fields.
Instead of
A retrospective audit that catches issues once conditions are live.
Decision 03
Every change is an event
Why
Original value, proposal, requester, reason, status and decision travel together as a full audit trail, with normalised identifiers so each approved change maps to its ERP record.
Instead of
Untracked edits across separate files.
05 · Go-to-market
Pilot, internal launch, phased rollout
Stakeholder demos closed the feedback loop before launch. A single-region pilot then tested the riskiest question (could a regional user review their own matrix and propose changes through the controlled process, unaided?) before a phased rollout.
Reconstructed rollout model
01
Demo before launch
Formal stakeholder demos, with the feedback applied before release.
02
Pilot one region
Access current data, select the region, review discounts and margin criteria, propose changes, see modified records flagged automatically, and submit for validation: user acceptance in real conditions.
03
Internal go-to-market
Access provisioning, enablement through user guides and demos, controlled deployment in the organisation’s internal environment, stakeholder comms and hypercare through first-line support.
04
Phased regional rollout
Regional matrices compared and consolidated into common structures, exceptions reviewed, customer classifications revised, then tested end to end in operations.
Reconstructed pilot criteria
Pilot exit criteria
Intent
A regional user reviews their pricing matrix and proposes changes through the controlled workflow, without write access to the master data.
As a regional user, I want to find and understand my conditions and propose a justified change, so that it reaches review as a structured, traceable record.
Acceptance criteria: all five
AccessCurrent data for the selected region, without the master structure.
UnderstandingFamilies, exceptions and margin criteria read without a specialist.
ProposalChanges and their reasons are captured in the workflow.
GuardrailsModified values and margin issues are flagged before submission.
Audit trailEach submission becomes a record with owner, timestamp and status.
Lesson learned. Testing in one region surfaced a customer-group allocation defect outside the application. After the fix, a retest confirmed the discounts applied correctly and the consolidation was signed off. In-app guardrails reduce risk; only end-to-end testing (approved change, ERP load, customer classification, applied condition) proves a change has really shipped.
06 · Outcomes
Outcomes and evidence
In operational use
Regional pricing moved from data silos to a single source of truth that people consult, review and change through one audit-trailed process.
Verified outcome
What is established
The five-increment data-quality programme was completed
All three layers went live for operational use
A single-region pilot validated the core flow before rollout
It supported several regional consolidations; one was signed off after end-to-end testing and a retest
Technical and user documentation shipped with the product
The product is maintained and iterated after launch
Measurement boundary
What requires verified measurement
Time saved and change cycle time
Errors avoided and margin impact
Active users, adoption and quotes generated
ROI and causal attribution
Reconstructed measurement model
Proposed metrics: a north star and three inputs
North star
Share of pricing changes that flow through the governed workflow rather than around it.
Cycle time
Lead time from a proposed change to its approval and ERP load.
Data quality
Discrepancy rate between the source of truth and the ERP, per audit cycle.
Guardrail hits
Changes held by margin or validation checks before approval.
Tech debt and risks
Known limits
Platform dependency: permissions, licensing, connectors and admin policies
No transactional ERP integration: approved changes are prepared, then loaded and verified
Brittle to upstream schema, identifier or connector changes
No metrics framework at launch, so value is evidenced qualitatively
Roadmap
Next bets
Move the golden record to a dedicated data platform
Direct, API-based ERP integration
Product analytics and telemetry from day one
Granular security and CI/CD across environments
Role in practice. End-to-end ownership: alongside the product-owner remit I covered business analysis, the functional data model, solution and workflow design, data-quality coordination, QA, the pilot, internal launch, documentation and first-line support, aligning Marketing, Purchasing, Pricing, Data and PIM, IT, market managers, regional teams and commercial centres. “Product owner” describes the work, not a formal job title.
Attribution boundary. The product operates within a broader commercial process. Wider commercial outcomes require verified measurement and cannot be attributed exclusively to it.
Standardisation was never the goal. A reliable source, justified exceptions and traceable change were.