← Home

Shipping Teachable's B2B platform in four months

I directed design and managed the Senior PD on the team that built Teachable's first B2B foundation: from organizations and seat management through org-level reporting, shipping the MVP in four months and opening a six-figure line of closed sales contracts.

Full-flow solution overview of the B2B platform
Role
Product Design Manager
Timeline
4 months, concept to MVP
Scale
Six-figure closed contracts
11K+ seats allocated
Team
Group PM, Head of Design,
Senior PD, Pod PM and EM.
01 · Context and problem
The company

Teachable makes money when sales run through its checkout

Teachable is a platform where creators and schools build, sell, and deliver online courses. Its revenue depends on those sales routing through its own checkout, where GMV and transaction fees are captured.

The problem

Creators were already selling B2B, just not through Teachable

One flagship creator sold hundreds of course seats to three universities using a calendar reminder to revoke access, hand-reformatted CSV reports, and no way to enforce course sequencing. Every sale like it happened outside Teachable's checkout: capturable revenue the platform never saw.

  • 57%of enrollments were bypassing Teachable's checkout as of March 2024, per the checkout-bypass research I helped drive internally.
  • 18%of creators were already selling B2B through workarounds, per company research.
  • 37%expected to be selling that way within a year.
02 · Impact

Every number below is revenue and adoption that previously happened off-platform or not at all.

0 → 6 figures

Sales contracts closed attributable to this project

502 schools

Admitted, against a target of 500.

11,161 seats

Allocated through the system.

5K+ students

Enrolled by organizations.

03 · What shipped
The platform

A B2B layer on top of every creator's school

Organizations, seat management, CSV bulk enrollment, org admins, and org-level reporting: the pieces a creator needs to sell course seats to an institution, and the pieces that institution's admin needs to run them. It replaced calendar reminders and hand-built spreadsheets with a system either side can operate.

SHIPPED NOW
  • Organizations
  • Seat management
  • CSV bulk enrollment
  • Org admins
  • Org-level reporting
FOR LATER
  • Native invoicing (direction set, in development)
  • Self-serve bulk purchasing (in development)
  • GTM materials (followed once the beta expanded to a larger alpha group)

“We thought we were going to have to switch to a different platform… And now that you have organizations, we can stay.”

Team lead delivering training contracts, nonprofit clients
04 · Management insight

The scope crisis I didn't see coming

Midway through the build, my senior designer told me in a 1:1 that she had been working late nights to absorb a growing MVP scope. The pod's PM was holding out for a scope large enough to produce complete beta results and finished GTM materials before any release, and the beta date was slipping out of reach.

ObservedThe scope kept growing, the designer was covering the gap after hours, and I only learned about it when she raised it herself.
IntervenedI made it my problem. I partnered with the PM's manager, then asked the Head of Product to have the pod spend one week paring scope to bare essentials, pitched deliberately harder than needed so the team would push back and own the middle line themselves.
What changedThe beta shipped on time on the pod's own negotiated scope. The price: GTM materials were not ready at launch. Shipping earlier let the designer start user research sooner, which ended up deprioritizing several features from the original MVP plan.
05 · Deep dive

Assigning a product and seats to an organization

This is where a creator sets what an organization can access: which product, and how many seats. It is also the exact spot where the deferred invoicing feature was always meant to land, work that is in development now: the deferral was sequencing, not a cut.

Seat-count field
Sets the organization's product access. The entity model underneath it was shaped around Stripe's documented data constraints before any billing work existed, so invoicing can land here without a redesign.
Add product modal with seat-count field {{ s1Hint }}hover to play

Bulk enrollment by CSV

The org admin's side of the platform. Institutions enroll their own people instead of routing lists back through the creator.

CSV upload control
 Replaces the hand-managed spreadsheets creators were using to enroll a buyer's students: the exact workaround that anchored the business case.
CSV file picker for bulk enrollment {{ s2Hint }}hover to play

Org-level reporting

Reporting an institutional buyer can pull themselves: completion, quiz scores, a leaderboard. Before this, the anchor creator was reformatting CSV exports into branded Excel files by hand.

Filterable completion and quiz-score reporting
 The direct replacement for those hand-built reports, and the piece that takes the creator out of the middle of every reporting request.
Org-level reporting with report type dropdown and completion table
The rest of the flow, end to end A creator creates the organization, creates its admin, and a student lands in their assigned path.
{{ modalNode }}
06 · Team and early-signal metrics

Early-signal and process numbers, not impact.

100 schools

Activated: target hit exactly.

70%

Of schools that enrolled one student went on to enroll 5+.

43 schools

With 5+ students enrolled.

30 pieces

Of written feedback, against a target of 25+.

92% of seats sat in the top ten schools and the median school held seven. Most orgs were still testing, not fully live.

07 · Key decisions

Defer the revenue features until the platform earned them

Native invoicing and self-serve bulk purchasing were the most-requested capabilities in discovery and the two tied most directly to revenue. I pushed to launch without both.

ChoseShip the value layer first. Defer monetization features until they could be justified.
RejectedBuilding now meant building on an aging payments infrastructure (that was going through a revamp of its own).
CostA dealbreaker for some prospects at launch. Adoption ran lower than it could have.

Back the Retool bet, and keep my designer's objections alive

Engineering proposed Retool to build the admin UI faster on greenfield work. My senior designer objected on legitimate grounds: design-system inconsistency and long-term inflexibility.

ChoseValidate her concerns, back the faster path for quicker user feedback, and commit to revisiting the call.
RejectedBuilding the admin UI natively from day one.
CostAccepted design-system inconsistency risk. Final sign-off on Retool itself sat with the Head of Design; my job was the buy-in.

Migrate off Retool once the risk stopped being hypothetical

Post-launch, Retool's inflexibility became a proven constraint rather than a predicted one, and engineering was hitting the same walls independently.

ChosePush the migration to native components, with a plan for swapping each Retool-built experience.
RejectedLeaving the admin UI on Retool indefinitely.
CostNative engineering work after launch instead of before it. The designer mapped existing design-system components onto the Retool pieces rather than redesigning from scratch.

Design around Stripe before committing to build

Invoicing was deferred, not ignored. I ran a three-day on-site sprint with my designer and the PM, scoped to the invoicing problem alone.

ChoseStripe Billing as the eventual solution, and shaping the platform's data model and UI around Stripe's documented constraints now so the future integration would be cheaper.
RejectedA different third-party billing provider; building invoicing fully in-house.
CostUX flexibility. The UI accommodates Stripe's data model rather than an ideal-from-scratch one.
08 · Reflection

What I only understood afterward: scope creep doesn't look like scope creep while it's happening. It looks like a PM being thorough. By the time it reads as a pattern, it has already cost someone real hours. Now, any time scope is contested, I run a lighter and more frequent pulse-check instead of waiting for a scheduled 1:1 to surface it.

I didn't know my designer was working late nights until she told me in a 1:1, which means it had been happening for a while before I had any visibility. I trusted the pod to flag problems, which put the burden on her to raise it instead of on me to notice it first.