# Riley Szulc - Product Round **Date:** 2026-03-03 **Interviewer:** Riley Szulc (Senior PM) **Format:** Panel week, Product Round **Overall feel:** Fast-paced, not as conversational/"vibey" as expected. Felt underprepared due to competing priorities but managed okay. ## Riley's Context - His product domain covers the **first half of the user journey**: purchase requisition → approval → vendor outreach → receiving - **Theme he set:** Product design, but really a PM approach to operations -- specifically around **simplicity**, **measuring impact**, and **design thinking** - Personal aside: his kid is also about to start daycare (came up when Andrea mentioned completing maternity leave) --- ## Q1: Simplicity in Products/Workflows **Question:** Procurify is known for broad feature sets but relatively simple processes/workflows. How do you get simplicity into workflows and products? **Andrea's answer:** Drew on Lalamove experience -- joined at a couple dozen people, left when it was thousands across multiple markets. At that scale, clarity and simplicity were critical for the company to scale appropriately. Three principles: 1. **Repetition** -- important things are reframed and re-communicated, but ultimately with the same core message 2. **Communication cadence** -- structured rhythm to support that repetition 3. **Visuals** -- visual notes, flowcharts, diagrams to help audiences understand what's going on Also emphasized that **culture and communication** were essential to supporting simplicity at scale. **What she thought but didn't say out loud:** Everyone needs to be speaking the same language -- using the same terms, shared vocabulary as a driving force for simplicity at scale. **Self-assessment:** Answer didn't land well. Knew the topic but couldn't phrase the response well in the moment -- partly a first-question warmup issue. The question was about product/workflow simplicity but the answer skewed toward communication principles. Should have clarified the question. The visuals point could also be read as contradicting simplicity since flowcharts can imply complexity. --- ## Q2: Redesigning for Simplicity / "Cutting to the Bone" **Question:** When redesigning a process for simplicity, how do you know if you've reduced too much -- "cut it down to the bone"? **Andrea's answer:** - Simplification is usually driven by **user feedback** -- frustration and impatience are clear indicators of what needs cutting - But **friction isn't always bad** -- sometimes it's required for critical things like compliance - **Measuring success vs. over-cutting:** - **Successful simplification** → sudden drop in complaints/feedback (satisfied users don't report back, they just use it) - **Over-simplification** → new uptick in feedback where users notice missing capabilities or use cases that were cut - Example: a workflow that previously served several use cases gets oversimplified, removing one or two use cases -- users will surface that something they relied on is gone **Self-assessment:** Hard question to answer because it was abstract. Would have appreciated a more specific example to anchor on. --- ## Q3: Tracking Impact of Product Changes (R&D ROI) **Question:** For product changes (e.g., a customer dashboard redesign), how would you track whether changes are strategically sound and moving the needle? **Andrea's answer:** - First understand **current behavior and expectations** across different teams using the same surface -- a redesign can have outsized impact on specific users based on existing usage patterns - Example: a user who checks a specific chart in the top-left corner daily -- if that moves, even if it's still on initial load, the impact may be larger than expected - Pair **quantitative data** (clicks, engagement, analytics -- work closely with data/analytics teams) with **qualitative feedback** from customers - Impact tracking isn't just for customers -- also internally for the business, depending on the **business intent** behind the change **Follow-up (Riley pushed harder):** How would you communicate impact tracking internally, say first 30/60 days after a feature launch? **Andrea's refined answer:** - Drew on experience building an internal knowledge base at Ting - Established a **specific cadence** for communicating to cross-functional teams - Created and repeatedly pointed teams to a **single central location** for consistent updates and progress tracking - Structure: **broad/glanceable summary** on initial access for all teams, with an **index for deeper dives** into specific details relevant to certain teams - Incorporated feedback: if teams identified missing dimensions of tracking, she'd add those. Also proactively surfaced new insights discovered through ongoing tracking - Always emphasized: one canonical place, easily accessible, consistently updated **Self-assessment:** Initial answer was too unspecific for his unspecific question. Once Riley reframed to 30/60 day internal tracking, she understood better and gave a stronger, more grounded answer. --- ## Q4: GTM Misalignment with Product/Engineering **Question:** Describe a situation where GTM teams (sales, marketing) were misaligned with product and engineering. How did you approach and resolve it? **Andrea's answer (Ting phased rollout):** - **Situation:** Internal platform required a phased rollout -- product/engineering insisted on it due to risk, but GTM teams hated it because it created operational complexity (different workflows, communications, messages, and systems across markets over time) - **Approach:** 1. **Educated GTM teams** on why phased rollout was necessary for risk reduction 2. **Took GTM input** on what would make the process less painful and operationally simpler for them - **Resolution:** Agreed to start with markets that were: - More **homogenous** (less variation) - **Limited in scope** (manageable) - More **stable** (customers more likely to forgive initial hiccups) - Once initial markets validated the approach and teams aligned on what the rollout looked like, they completed the full rollout successfully **Self-assessment:** This went well. When Riley asked for a specific example from experience, Andrea was able to structure and deliver the response much more clearly than the earlier abstract questions. --- ## Themes & Takeaways **What worked:** - Specific experience-based answers (Ting phased rollout, knowledge base) were strongest - Feedback/sentiment signals for measuring simplification was a solid framework - Dashboard redesign answer showed good instinct for user empathy and pairing quant + qual **What to improve:** - Q1 on simplicity -- answer was about communication principles, not product/workflow design. Need a better framework for *product* simplicity specifically - Prepare for abstract "how would you approach X" questions with concrete anchoring examples ready to deploy - When a question feels unclear, **ask for clarification** rather than powering through - Should have been better prepared overall given the panel week stakes **Signals from Riley:** - The 30/60 day tracking question felt like something Procurify is already doing or building toward - Strong focus on operational PM skills: measuring, communicating, simplifying -- consistent with the role being "Product Strategy & Operations"