Case Study 03
How the work unfolded
The product challenge was not drawing boxes and arrows. It was defining what each run means, how errors change the state, and what an operator can do when production behaviour differs from the design.
Problem
Client automations were moving into the product, but an action builder without execution controls or investigation tools would create a new support dependency.
Decision
Stage the platform around an explicit execution contract: state, concurrency, failure handling, idempotency, testing and inspectable history.
Observed result
Workflow paths reached production use and exposed real missed and duplicate-trigger cases that sharpened the observability and recovery model.
Sanitized product artifact
Workflow execution lifecycle
A sanitized view of the execution contract used to define scope and operational checks.
- 1TriggerHTTP, webhook, Store Purchase and data events
- 2QueueRun state, concurrency and idempotent ingestion
- 3ActionsTransformations, conditions, branching and bulk updates
- 4Error and historyStop behaviour, retry, run history and investigation
My contribution: I sequenced the work and defined execution, failure and recovery rules.
Observed result or limit: Named-client production use was internally confirmed; volume, sustained reliability and external acceptance were not measured.
Context
ReturningAI receives events from client systems and uses them to update member data, rewards, Store eligibility and engagement experiences. Bringing that automation into the platform gave clients more control, but also made execution state and recovery part of the customer experience.
What I owned
I shaped product scope and sequencing, execution and failure semantics, data selection, reusable event boundaries, acceptance criteria and production follow-through. Engineering and design collaborators owned implementation and detailed interaction work; my role was to keep the system coherent and operable.
How the system evolved
Phase 1: Triggers, HTTP and webhook actions
The first useful layer let teams configure external triggers and actions instead of moving every automation into another tool or engineering script.
What changed
- HTTP and webhook actions
- Currency and user-data operations
- Transformations and reusable data selection
What I shaped
I helped define the user jobs, action boundaries and product sequence so the builder could grow without pretending to support every automation at once.
Evidence and limits
The case demonstrates platform judgment and operational ownership. It does not claim a mature automation product with proven broad adoption.
- Internal platform inspection showed deployed and draft workflows plus successful run histories.
- Named-client production use was confirmed internally for Store Purchase and deposit-event paths.
- The archive also contains missed and duplicate-trigger evidence; the final reliability outcome was not fully recovered.
- Execution volume, stable-operation rate and external client acceptance were not measured.
What this demonstrates
A workflow product is a runtime as much as a builder. The PM decisions that mattered most were the ones that made execution predictable, inspectable and recoverable when real client events arrived.