# How to Answer Use one cohesive STARL story if possible: - **Situation:** product, customer problem, teams, timeline. - **Task:** your goal and constraints. - **Action:** alignment, conflict resolution, launch, customer feedback, course correction. - **Result:** measurable outcomes. - **Learning:** what changed in your process. ## Model Answer **Situation:** I owned an enterprise analytics dashboard that required work from three engineering teams: data platform, API, and web. The customer need was clear: admins wanted reliable usage and compliance reporting without filing support tickets. We had committed to a three-month beta for about 50 enterprise customers. The challenge was that each engineering team had different priorities. Data platform wanted to fix pipeline reliability, API wanted to standardize contracts, and web wanted to ship the dashboard experience quickly. **Task:** My goal was to launch a reliable beta that increased weekly admin usage and reduced reporting-related support tickets, while meeting a p95 latency target and avoiding stale data. **Action:** I first aligned the teams around the customer outcome rather than each team's preferred implementation. I wrote a one-page launch brief with the customer problem, success metrics, guardrails, dependencies, and open decisions. Then I set up a weekly dependency review and used a DACI model so we knew who recommended, who decided, and who executed. The biggest conflict was between API and data platform. API wanted a stable final schema before building endpoints, while data platform wanted more time to clean historical edge cases. That threatened the launch date. I facilitated a trade-off discussion with three options: delay launch for a complete schema, ship a narrow API contract for the top use cases, or launch a static export as a temporary workaround. We chose the narrow API contract because it served the highest-value customer jobs and kept quality risk manageable. I documented the deferred edge cases and made them explicit in the beta scope. We shipped the beta on time, but the first customer feedback showed that we had missed an expectation: admins did not just want a dashboard; they needed scheduled exports for compliance workflows. Usage was lower than expected because customers still had to manually download reports. I treated that as a course correction, not a failure to defend. We interviewed beta customers, reviewed support tickets, and found that scheduled exports were a stronger job to be done than interactive chart exploration. I reprioritized the next sprint toward scheduled exports, alerting, and clearer data freshness labels. I also adjusted the success metric from dashboard views to weekly admins completing a reporting workflow. **Result:** After the course correction, weekly active admin usage increased, reporting-related support tickets fell, and customer satisfaction in the beta improved. The teams also adopted the launch brief and dependency review as the standard process for later cross-team projects. **Learning:** I learned that cross-team alignment should be built around customer workflows, not internal components. I also learned to validate the job to be done before over-investing in a polished surface. ## Why This Answer Works It shows: - Multiple teams with real conflicting priorities. - A concrete alignment mechanism. - A trade-off that protected both timeline and quality. - Customer feedback changing the roadmap. - Metrics and learning. ## Common Mistakes - Making the conflict sound like other teams were unreasonable. - Describing process without customer impact. - Saying the initial launch failed but not explaining recovery. - Providing no metrics. - Overstating authority instead of showing influence.