Cristian Malpica Professional Portfolio

Professional work · Anonymised

From fragmented pricing work to system-ready decisions

I developed an internal application that connects a clear pricing workflow to system-ready output, with preventive checks and decision context designed for traceable review.

Role
Product framing, workflow definition, requirements and application development
Outcome
Implemented and in ongoing internal use; broader adoption is not attributed to my work alone
Shipped
System-ready output with preventive checks at the point of decision
Scope
An internal pricing-to-system workflow for a broad internal audience
Reconstructed product view

One workspace from pricing task to system-ready output

The screen makes working context, preventive checks and output readiness visible in the same path.

Reconstructed portfolio artefact based on the method used during the project. This is not an original internal company document.

Pricing workspace Illustrative task · synthetic data
Review in progress

Change setWorking draft

InputAuthorised source

DestinationSystem-ready file

ItemsReview queue
3 illustrative rows
Illustrative product records and validation status
ItemEntryValidationOutput
Item AReference generalised Complete Ready Mapped
Item BReference generalised Complete Review Blocked
Item CReference generalised Complete Ready Mapped

Output structure protectedReady rows retain the required format and decision context.

Release unavailable · 1 check open

Challenge and product decision

A fragmented pricing workflow created avoidable rework, discrepancy risk and limited traceability.

Decision: Treat the user workflow and required system output as one product problem—not two processes joined by repeated manual work.

01 · The problem

A fragmented handoff created preventable risk

Pricing decisions moved through multiple working and system formats. This increased transformation effort, discrepancy risk and loss of decision context.

Reconstructed portfolio artefact based on the method used during the project. This is not an original internal company document.

Cost 01

The handoff created preventable discrepancy risk

Observed condition
Checks were not consistently available at the point a pricing decision moved into the system workflow.
Product implication
Prevention belonged inside the task rather than in retrospective correction.

Cost 02

Formats required repeated transformation

Observed condition
The format people used to make a decision and the format required downstream were not aligned.
Product implication
The solution had to produce usable and system-ready output in one flow.

Cost 03

Decision context was not consistently preserved

Observed condition
Context could be lost as information moved between working and system formats.
Product implication
Traceability had to be designed into the workflow.

What people needed

A task they could complete

  • Pricing task
  • Usability
  • Accessibility
  • Context
The fragmented handoff Where effort and discrepancy risk accumulated

What the system required

Output ready for downstream use

  • Required structure
  • Compatibility
  • Control
  • Traceability

02 · Discovery

Map the decision from start to finish

This reconstructed discovery view shows how I framed the workflow and the constraints the application had to reconcile. Internal systems, approval logic and implementation details have been generalised.

Reconstructed portfolio artefact based on the method used during the project. This is not an original internal company document. Findings are paraphrased and anonymised.

  1. 01

    Bring the workflow into one view

    Combining operational perspectives makes handoffs, repeated transformation and missing context visible.

  2. 02

    Trace where information changes shape

    Each transformation point becomes a potential source of effort, discrepancy or lost context.

  3. 03

    Separate evidence from assumption

    The workflow issue was documented; its financial magnitude was not. Confirmed observations remain separate from unquantified assumptions.

  4. 04

    Identify non-negotiable constraints

    Separating genuine output requirements from working conventions clarifies the product’s scope without exposing internal architecture.

Assumption 01

Usability was the primary cause

Interpretation
Usability mattered, but format transformation was the larger structural constraint.
Implication
A friendlier interface alone would preserve the repeated handoff.

Assumption 02

Errors were mainly individual

Interpretation
The risk was structural: important checks depended on memory at the point of work.
Implication
Training alone would not remove the underlying process risk.

Assumption 03

A retrospective report was sufficient

Interpretation
A retrospective report would surface issues after the handoff rather than prevent them.
Implication
Control belonged at the point of decision.

03 · The decisions

One product across two realities

Three product decisions shaped the solution. Each addressed a different risk: preserving the handoff, detecting issues too late, or excluding part of the internal audience.

Reconstructed portfolio artefact based on the method used during the project. This is not an original internal company document.

Decision 01

Treat the workflow and system output as one problem

Why
Optimising either side alone would preserve manual transformation. The application produces system-ready output directly.
Instead of
A clearer interface that still exports work requiring repeated re-entry.

Decision 02

Make control part of the product, not a report about it

Why
Checks had to sit inside the task rather than after the downstream handoff.
Instead of
A retrospective report that would identify issues only after they entered the system.

Decision 03

Treat accessibility as a release criterion

Why
An internal tool that some team members cannot use will invite workarounds that recreate the manual process.
Instead of
Shipping first and treating access as a later fix.

Non-negotiable

System fit

Required output structure and relevant operational constraints had to be validated before release.

Prove first

Product fit

The workflow, its checks and its accessibility had to work together in a complete end-to-end path.

Deliberately left out

Non-essential enhancements

Capabilities that did not address the primary workflow or control risks remained outside the first-release scope.

04 · Delivery

Sequence by risk, release by evidence

This reconstructed delivery model prioritises system compatibility, control accuracy and operational ownership before visible enhancements. Technical details and internal release mechanics are omitted.

Reconstructed portfolio artefact based on the method used during the project. This is not an original internal company document.

  1. 01

    Validate compatibility risk first

    The system constraint comes before interface refinement because every later decision depends on it.

  2. 02

    Prove a controlled end-to-end slice

    A complete but bounded workflow can expose dependencies that an isolated demonstration cannot.

  3. 03

    Expand only with supporting evidence

    Each additional path should meet the same workflow, control and accessibility criteria.

  4. 04

    Define operational ownership

    Guidance, support responsibilities and feedback routes belong in release readiness.

Reconstructed portfolio artefact

Definition-of-ready model

Intent

Connect an accessible pricing task to the required downstream structure while preserving the context needed for review.

A pricing user completes the task through an accessible workflow that produces system-ready output and preserves the information needed for later review.

Ready meant all five

  • User outcomeThe task and the value it produces are explicit.
  • System constraintThe relevant output requirement is known, not assumed.
  • ControlThe check and its point in the workflow are explicit.
  • AccessibilityThe access criteria are part of acceptance.
  • EvidenceOpen assumptions and test scenarios are visible.

05 · What changed

Operational outcome

Implemented internally

The delivered workflow is in ongoing internal use. It produces system-ready output and embeds preventive checks at the point of decision.

What I can defend

Evidence I can discuss directly

  • The application was implemented for ongoing internal use
  • It provides an implemented alternative for the workflow in scope
  • Preventive checks sit inside the workflow
  • Output is produced in the required downstream structure
  • The workflow was designed to preserve the context required for review

Not claimed

Outcomes and details not claimed

  • Adoption figures or usage patterns
  • Financial impact and value protection
  • Administrative time recovered
  • Delivery dates, architecture or implementation mechanics
  • Exclusive causal attribution to the application

Reconstructed measurement model

Four measures for continued product learning

Reconstructed portfolio artefact based on the method used during the project. This is not an original internal company document.

Variance

Priced-versus-recorded variance, before and after.

Effort

Time spent reconciling pricing against the enterprise system, per period.

Control

Exceptions caught inside the task rather than after handoff.

Access

Successful keyboard-only task completion and any remaining workarounds.

Attribution limit. The application operates within a broader commercial process. Wider commercial outcomes are not quantified here and cannot be attributed exclusively to this intervention.

User experience and system requirements were never in competition here. The recurring manual reconciliation between them was the cost.

Professional approach

How I approach B2B portfolio decisions

Explore seven anonymised decision frameworks across lifecycle, commercial, launch, availability, product data, adoption and supplier questions.

View decision approach

Academic mobility portfolio

Electric mobility: from concept to investment gates

Follow SOLAR MOTION from individual brand and business design through export operations and a collaborative Chile strategy.

View case study