Cristian Malpica Professional Portfolio

Professional product case

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
FamilyChangeGuardrailRecord
Family A Discount revised Passed Queued
Family B Discount raised Review Held
Family C Comment added Passed Queued

Change event loggedOriginal value, proposal, requester, reason and status form the audit trail.

Awaiting approval · 1 guardrail open

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 matrix Where 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

  1. 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.

  2. 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.

  3. 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.

  4. 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

  1. 01

    Completeness: does the record exist?

    Conditions present in the ERP but missing from the commercial records, and the reverse.

  2. 02

    Accuracy: is the value right?

    Records held in both places with different percentages, reconciled side by side with the variance calculated.

  3. 03

    Validity: is the exception still justified?

    Material-level discounts reviewed one by one, then retained, corrected or deprecated.

  4. 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.

  5. 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

  1. 01

    Demo before launch

    Formal stakeholder demos, with the feedback applied before release.

  2. 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.

  3. 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.

  4. 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.

Product toolkit applied in this case

Discovery
Opportunity assessmentProblem framingProduct visionRequirements elicitationData requirementsStakeholder management
Data governance
Single source of truthMaster data managementReconciliationData stewardshipException managementMargin guardrails
Delivery
Low-codeWorkflow automationRBACMaker–checkerAudit trailCPQ-style quotingIncremental deliveryUAT
Go-to-market
Stakeholder demosPilotPhased rolloutInternal GTMEnablementChange managementHypercare