Demonstrate motivation, feedback, and prioritization

How to structure STAR answers with metrics - Situation: Brief, factual context (who/what/when/where). 1–2 sentences. - Task: Your specific goal or responsibility. 1 sentence. - Action: What you did. Focus on decisions, frameworks, and collaboration. 3–5 bullets. - Result: Quantified outcomes (absolute and relative), guardrails, and learning. 2–3 bullets. - Tip: Use simple, auditable metrics (%, pp, hours saved, WAU/MAU, P95 latency, adoption rate, revenue impact). When experimentation is involved, mention MDE/power and guardrail metrics (e.g., error rate, latency). 1) Why join Atlassian (STAR with two trade-offs) - Situation: I was choosing my next role after 3 years driving product analytics and ML for collaboration tools, prioritizing mission-aligned products with strong experimentation culture. - Task: Identify a company where my impact on activation, collaboration workflows, and AI-assisted productivity would be maximized. - Action: - Evaluated Atlassian’s products—Jira, Confluence, and Jira Service Management—focusing on onboarding funnels, search/ranking, and Atlassian Intelligence opportunities (e.g., summarization, issue routing). - Mapped my past outcomes to Atlassian’s mission to “unleash the potential of every team,” and to working practices like open-by-default docs, Team Anywhere, and blameless postmortems. - Spoke with 3 current Atlassians about their data-informed culture (weekly experiment reviews, RFCs, and decision logs). - Result: - Concluded I can meaningfully move metrics that matter to Atlassian (e.g., new-team activation +2–4pp, WAU/MAU +3–5%, P95 search latency −10–20%). - Motivations tied to: (a) breadth and impact of Jira/Confluence in knowledge work, (b) scale for experimentation (10Ks of daily cohorts), and (c) principled openness/async rituals that suit my working style. - Trade-offs I accept: 1) Distributed, async work can slow alignment by 1–2 days per decision; I’ll mitigate with crisp written RFCs, decision deadlines, and pre-reads. 2) Strong privacy/compliance guardrails can lengthen data/ML cycles by ~10–20%; I’ll plan for privacy-by-design, synthetic data, and staged rollouts to keep velocity. 2) Constructive feedback (code and communication) - Situation: A new analyst’s dashboard for executive QBRs had flaky metrics and slow queries, leading to 2 incident escalations in one month. - Task: Provide feedback that improved reliability and helped the analyst level up without harming trust. - Action: - Scheduled a 1:1 framed around shared goals; cited 3 concrete issues (missing time filters, inconsistent joins, unindexed filters) with examples. - The analyst initially reacted defensively, noting time pressure. I acknowledged constraints and proposed pairing on one critical chart. - Introduced a review checklist (freshness SLA, source-of-truth table, null handling, query plan check), created a dbt model to standardize joins, and ran a 45-min query tuning session (added 2 indexes, partition pruning, CTE rewrite). - Set up a pre-merge validation: unit tests for metrics definitions and a 30-min async peer review window. - Result: - Reduced median dashboard load time by 62% (12.6s → 4.8s); eliminated incidents (0 in next 60 days); PR review cycle time fell 28% (2.5d → 1.8d). - Analyst’s engagement improved (took ownership of the checklist; led 2 brown-bags). Our team adopted the checklist as a standard, cutting BI incidents by 35% quarter-over-quarter. - Learning: Pairing + concrete examples defuse defensiveness; checklists and tests institutionalize feedback. 3) Balancing competing priorities (RICE and sequencing) - Situation: In a quarter, I owned (A) shipping a next-best-action (NBA) model for upsell and (B) analyzing a high-visibility onboarding A/B test that could affect activation goals. - Task: Make explicit trade-offs to maximize business impact while protecting data quality and team throughput. - Action: - Sized both with RICE: RICE = (Reach × Impact × Confidence) / Effort. - NBA model: Reach 50k users/mo, Impact medium (1–2% revenue), Confidence 0.6, Effort 5 weeks ⇒ (50k×M×0.6)/5. - Onboarding test: Reach 200k new users/mo, Impact medium-high (2–4pp activation), Confidence 0.7, Effort 2 weeks ⇒ higher RICE. - Sequenced: prioritized the onboarding analysis first; time-boxed the NBA model to a rules-based baseline in week 3 to unblock experimentation. - Established guardrails: For the A/B test, pre-registered metrics (activation primary, support tickets and latency as guardrails), MDE 2pp with 80% power; for NBA, a shadow period to monitor precision/recall and customer support volume. - Communicated trade-offs to stakeholders with a one-page plan and weekly burn-down. - Result: - Onboarding experiment shipped in week 2 with +3.2pp activation (p<0.05), no guardrail regressions; projected +4.5% WAU. - NBA baseline launched in week 5; drove +1.1% incremental revenue (A/B holdout), with <0.2pp increase in support contacts. - Learning: Explicit RICE scoring and time-boxed baselines de-risk sequencing; shadow modes protect customer experience. 4) Went above and beyond for customers; effort failed - Situation: Enterprise admins reported SLA breaches going unnoticed in our ticketing workflow. I proposed a predictive SLA-breach alert feature to reduce MTTR. - Task: Validate and drive adoption of the feature with measurable impact on MTTR and admin satisfaction. - Action: - Built a quick logistic model on historical tickets (AUC 0.78), exposed as an alert in the admin view; set an adoption goal of 30% of eligible projects and MTTR −10%. - Ran a 6-week opt-in pilot with 40 customers; instrumented feature adoption, alert precision/recall, and MTTR as primary KPI; guardrails: alert fatigue (dismissals), false positives, and page load latency. - Overinvested in enablement: office hours, Loom walk-throughs, and templated playbooks. - Result (failure): - Adoption reached only 8% (goal 30%); alert precision 0.61 led to alert fatigue (dismissals +35%); MTTR change was statistically insignificant (−1.3%, p=0.28). - Post-mortem interviews revealed setup complexity (permissions, notification routing) and misalignment: admins needed bulk triage, not just alerts. - Learning: 1) Solve for the workflow, not just the prediction—“decision + action” > “signal.” 2) Treat activation friction as a first-class problem (1-click default routing would have helped). 3) Increase bar for pilot readiness: require precision ≥0.75 or add tiered alert levels; dogfood internally first to refine UX. 5) Most effective team I’ve been on - Situation: A cross-functional growth squad (PM, 5 engineers, DS, designer) responsible for team activation and collaboration features in a productivity product. - Task: Improve activation, experiment velocity, and decision quality while maintaining reliability. - Action (what made it effective): - Clear ownership: team-level north star (activated teams), with a compact metric tree (activation → WAU → retention) and 3 guardrails (latency, crash rate, support tickets). - Strong rituals: weekly experiment review (written pre-reads), bi-weekly metrics office hours, monthly pre-mortems for risky launches, and a living decision log. - High trust: blameless postmortems; PR templates for data/experiment quality. - My contributions: formalized experiment QA (power calc, CUPED for variance reduction), built a reusable metrics package and a dbt layer to standardize definitions, and created a “red/yellow/green” quality bar for experiments. - Result: - Experiment throughput +40% (10 → 14/quarter), win rate from 27% → 36% via better hypothesis formation; analysis cycle time −33%. - Activation +3.8pp over two quarters; P95 latency held flat; support tickets −12%. - Team engagement rose (eNPS +15); onboarding new members’ time-to-first-PR −50% due to templates and docs. - Learning: Written culture and reusable analytics assets compound; guardrails preserve user experience while enabling speed. Tips to adapt these to your story - Swap in your product areas (e.g., search ranking, permissions, billing) and metrics you truly owned. - Keep numbers conservative and verifiable; call out your direct actions and cross-functional partners. - When you name trade-offs, state how you mitigated them (time-boxing, baselines, guardrails, RFCs). - For experiments, mention basic statistical hygiene (power, MDE), guardrails, and what you’d monitor post-launch.