# Tony Wang — Product Round
**Date:** 2026-03-06
**Format:** Panel interview, ~30 min
**Vibe:** Professional, on time. Straightforward conversation.

## Tony's Domain
- Platform integrations — third-party apps, ERP connections (QuickBooks and many others)
- Long tail of smaller, more custom ERPs beyond the major ones
- Consolidating architecture within his domain
- Goal: beef up integrations to support Procurify's push into mid-market

## AI & Future Direction
- No specific active AI enablements in his domain right now
- Current architecture work lays the foundation for AI
- Considering: because Procurify owns many of its own integrations, there may be an opportunity to expose functionality to the ecosystem and create agentic workflows
- Still too early to say — exploratory thinking

## Questions & Responses

### 1. Product with high complexity in the development lifecycle
Tony asked about a product Andrea was part of where there was a lot of complexity.

**Andrea's answer:** The Ting internal platform — developing new microservices and having to orchestrate/coordinate across them. Created a lot of need for:
- Thorough documentation
- Working closely with teams to understand expected outcomes
- Clarifying through testing what the actual functionality and dependencies looked like across the platform

Also mentioned developing the beta program as a proving ground in production to validate their understanding of how the platform worked.

**What landed:** Demonstrated comfort with platform-level complexity and microservice coordination — directly relevant to Tony's integration architecture work.

### 2. Trade-off that materially changed product direction
Follow-up from Q1. Asked about a product decision involving a trade-off that changed direction.

**Andrea's answer:** The beta program results revealed that the earlier trade-off of not rebuilding provisioning was not feasible for go-to-market. Took data from production (from the beta program) and used it to justify building a new provisioning system to ensure they could actually launch.

**What landed:** Data-driven decision reversal. The beta program wasn't just validation — it was the mechanism that surfaced the need to change course. Shows Andrea doesn't get attached to earlier decisions when evidence says otherwise.

### 3. Shared platform capability vs. one-off solution
How do you decide what becomes a reusable shared capability vs. a one-off?

**Andrea's answer:** Used the migration project scoping as the example — evaluating multiple billing systems and many one-offs from legacy systems (especially custom-built ones from previous acquisitions). Highlighted a memorable example: one acquired company had built a process for customers to pay with gift cards. Clear-cut one-off that would never be approved today.

But also noted that the harder calls are around **stopgap solutions** — things built because the company lacked resources or capability for the proper solution. These tend to be short-to-medium-term fixes that won't exist as workflows long-term. Evaluation criteria:
- Is this a stopgap born from resource constraints?
- Does it have a natural expiration (short/medium term)?
- Would it survive as a workflow in the long term?

If no to the last question, it's a one-off regardless of how embedded it currently is.

**What landed:** The gift card example got a reaction (funny, concrete). The stopgap framework shows mature platform thinking — not just "is it reusable?" but "why does it exist and will it persist?"

### 4. Cross-functional communication
How do you handle communications and working across teams?

**Andrea's answer — internal:**
- Early stages: flexibility before things get cemented — cadences and responsibilities aren't well-defined yet, so communication needs to be more fluid
- Once established: clearer swim lanes with structured feedback loops across teams
- Migration project example: reported upward to C-level internally and upward to C-level at the vendor. Also communicated laterally with team leaders of responsible teams internally.

**Follow-up — external/customer-facing communications:**
- Critical to have clear, regular cadence — biweekly syncs with marketing, sales, and customer support
- Purpose: get external feedback loops flowing back into product/engineering, and feed insights back out to GTM teams
- Example: used Zendesk as both CRM and support tool. Support tickets, marketing analytics/reporting all flowed through Andrea as the conduit between external-facing teams and product/engineering, and back outward to GTM.

**What landed:** Showed she understands communication as a two-way system, not just status reporting. The Zendesk example made the feedback loop concrete — she was the hub connecting external signal to internal decisions and back.

### 5. Operations experience
Tony asked specifically about Andrea's operations background after her intro.

**Andrea's answer:** Two examples:
1. **Atsu (Lalamove):** End-to-end operations — from picking up the phone and calling drivers to going down to the parking lot to check on cars. Later moved into product operations, working closely with dev teams and setting up smooth end-to-end workflows.
2. **Ting:** When she first joined, there were no established processes or workflows. Set up the product team workflows from scratch.

**What landed:** The breadth of operational experience — hands-on ground level to process design. Showed she's not above getting her hands dirty.

## Overall Assessment
- Tony was engaged and asked relevant follow-ups
- Andrea's ops stories demonstrated range and adaptability
- Questions were highly aligned with Tony's domain (platform architecture, integration complexity, reusability decisions) — he was likely assessing fit for his specific problem space
- The beta program story threaded through two answers naturally (complexity + trade-off), which gave it coherence
- Gift card anecdote was a good moment of levity in a technical conversation
- Integration domain is highly relevant if Andrea joins — understanding ERP complexity and long-tail customization will matter