Shaili Pankaj
Open to roles
← All work

6 · Leadership

Building the team, and the practice that outlived me

The only case here that isn't about a number, which is why it's last.

Company
Doodle, with one from Gett
Role
Director of Growth, then Chief Growth Officer
Dates
2018–2025
Team
Built Product Growth from scratch, 2 direct reports and a 5-person squad. Grew to 18 direct and indirect across product growth, marketing, brand, CX and support.

The problem

Growth work fails in the gaps between teams. At Doodle the marketing team was lean and fielding simultaneous requests from four senior stakeholders, all of whom were right. At Gett, prioritisation was decided by proximity: the team sitting nearest the developer got their work done first. Neither was a capability problem. In both cases nobody had agreed how to decide.

What we did

  • Built the Product Growth team at Doodle from nothing, then grew the remit to eighteen people across five functions.
  • Ran a thirty-minute ICE exercise with the marketing team, added a short-term versus long-term lens, and published the result on a company-wide JIRA board. That last part mattered most. It let senior stakeholders see the trade-off instead of arguing for their own item in private.
  • At Gett, replaced “loudest team wins” with Asana ticketing, SLAs and impact-effort scoring. The team that lost most from the change pushed back hard, so I had that conversation face to face rather than defending the process over email. They ended up combining requests with other teams to score higher.
  • Trained every PM and designer at Doodle on hypothesis design and success metrics, and ran company-wide demos that included the tests that failed.
  • Standardised impact-centric prioritisation across product, CX and marketing.

The call I had to make

An A/B test showed a new hero lifting sign-ups twenty per cent, every guardrail stable. Our Director of Design disagreed on brand grounds and escalated. The CPO and CEO sided with him. So I committed, and we built variants that held the brand and still improved clarity. That version did fifteen per cent. Data alone doesn't win the argument, and I'd brought design into it too late.

Impact

  • +25% on feature development cycle time from standardised prioritisation
  • The disagree-and-commit variant shipped at +15% conversion, with better alignment across product, marketing and design
  • The experimentation practice ran without me: 100+ tests a year, run by PMs and designers rather than by my team
  • At Gett, teams that had been competing for the same developer started combining requests

What it taught me

The strength that came back from every single person in a six-way feedback review I ran last year was the one I'd have listed last myself: getting people to trust each other enough to move in the same direction. I've come round to thinking that's most of the job. A prioritisation framework isn't really about prioritisation. It's a way of making the trade-off visible, so people can disagree with the decision instead of with each other.