← Selected work

Operating models · Portfolio strategy · Talent

Scaling Apptegy from 800 to 4,000 Customers

How do you build product systems that survive hypergrowth instead of breaking under it?

Company
Apptegy
Period
2018–2023
Disciplines
Product Strategy, Operating Models, Leadership
Chapters
8
800 → 4,000
Customers
400%
Market share growth
$20M
ARR contributed to
01The situation

Apptegy was winning, which is its own kind of problem. Every quarter brought more customers, more districts, more feature requests, and more people who needed to know how decisions got made. The instincts that worked at 800 customers, talk to everyone, decide fast, ship, stopped scaling somewhere around 1,500.

02The actual problem

The request was

We need to ship faster to keep up with sales.

Discovery showed

Velocity was not the constraint. Repeatability was. The same decisions were being re-litigated in every squad because there was no shared operating model for how work entered, got prioritized, and got judged.

Hiring more product managers into an undefined system produces more opinions, not more throughput. The durable fix was designing how the portfolio operated, intake, prioritization, discovery standards, launch criteria, and the coaching model that let new PMs become good ones quickly.

03What I learned
  • Traced how requests actually entered the roadmap versus how the process claimed they did.
  • Segmented the customer base by district size and maturity to find where the portfolio was over- and under-serving.
  • Interviewed sales, implementation, and support to surface the recurring commitments product was absorbing invisibly.
04How I framed it

Exhibit

Customer Growth, 2018–2023

2018
800
2019
1,400
2020
2,100
2021
3,000
2022
3,600
2023
4,000
What you're looking atMarket share growth of 400% over five years. The interesting part is not the curve, it is that the operating model changed three times underneath it to keep the curve possible.

Exhibit

Product Operating Model

  1. 01

    Intake

    One front door for every request, from any function

  2. 02

    Framing

    Problem statement, evidence, and the decision being asked for

  3. 03

    Discovery

    Minimum evidence bar before anything enters a roadmap

  4. 04

    Commit

    Explicit tradeoffs, named owner, defined success measure

  5. 05

    Launch & learn

    Adoption reviewed against the stated measure, not vibes

Same spine, every squad. Different products, comparable decisions.

What you're looking atThe intake-to-launch spine every squad shared. Standardizing the path, not the products, is what made growth repeatable and made new PMs productive in weeks.
05What we built
  • 01A durable product operating model, intake, framing, discovery standards, commit criteria, launch review.
  • 02A portfolio strategy that segmented investment by district size and product maturity.
  • 03A coaching and development model that produced product leaders whose impact continued after my tenure.
  • 04Repeatable launch and adoption practices shared across squads.
She set the tone for the product team and laid the foundations for the majority of the products that are growing today in Apptegy.
Guillermo Araiza, Staff Product Manager at CrunchyrollGuillermo AraizaStaff Product Manager at CrunchyrollRead in full →
06My role
Strategy
Owned portfolio strategy across an EdTech product line spanning multiple countries.
Operating design
Designed and iterated the product operating model three times as scale demanded.
Leadership
Hired, coached, and developed product managers.
Execution
Ran discovery and launch on the highest-risk bets personally.
07The outcome
  • 400% market share growth: 800 to 4,000 customers.
  • Contributed to sustained growth reaching $20M ARR.
  • Operating models that remained the foundation for growth after I left.
  • A generation of product managers who went on to lead elsewhere.
08What I'd do differently

I rebuilt the operating model twice before accepting that it needs rebuilding roughly every time the company doubles. Treating the model as a product with its own version history, rather than a policy to defend, was the shift that made the third one much easier than the second.

Contact

Let's get into it.

Ambiguous problem, AI adoption that stalled, an operating model that stopped scaling, a support function that should be a product. That is the conversation I want.