Building professional services while building the product: Clutch’s blueprint for scale

When your company’s in hypergrowth, you don’t get to build a perfect professional services (PS) org in isolation, you make it while delivering.

That was the reality for Clutch’s PS leadership team as they navigated the leap from Series A to Series B while launching a second product and managing over 20 implementations.

At Propel25, Clutch’s panel featuring Jake Weber (Manager, Technical Delivery), Jill Young (Manager, PMO), Zul Gire (Manager, Technical Delivery), and Daniel Levine (Director, PS) shared their inside story. From tooling and training to monetization and methodology, they offered a no-fluff playbook for building a resilient PS engine that scales with the company.

Startups don’t pause for PS to catch up

In 2024, Clutch hit an inflection point. The company had:

• Just launched a second product (digital account opening)
  
  
• 20+ implementations in-flight
  
  
• A product evolving weekly
  
  

The catch? The PS team was still figuring out how to implement that second product.
“No knowledge transfer yet. No methodology. But implementation needed to start in January,” said Daniel.

Their answer: build while delivering, or as they framed it, “taxis before subways.”

The ‘taxis before subways’ metaphor

In early-stage PS, you’re not operating a streamlined metro. You’re a fleet of scrappy taxi drivers:

• Each implementation engineer or PM takes a slightly different route
  
  
• Documentation is “good enough” but not perfect.
  
  
• Flexibility trumps rigidity
  
  

Eventually, you evolve into buses (shared, semi-standard processes), then subways (repeatable, automated, scalable operations). But trying to build a subway system too soon, without product stability, only adds overhead.

Key lesson: Don’t over-process too early

• Lean on adaptable team members who thrive with ambiguity
  
  
• Let early customer delivery inform the system.
  
  
• Build tooling that evolves alongside the product.t
  
  

Building resilient internal tooling

The Clutch team took pride in building tools for themselves. One standout: a browser extension that lets any employee click on part of the product UI and see if it’s configurable.

Why this mattered:

• Reduced noisy Slack threads (“Can this label be changed?”)
  
  
• Created a self-updating knowledge base
  
  
• Enabled anyone to contribute answers, not just engineers
  
  

Pro tip: “Your tools should anticipate change. If your product evolves weekly, your tooling must be editable and crowd-sourced, not static,” said Jake.

Building the PS foundation, one layer at a time

1. Define methodology, then scale repeatability

Jill explained how the team:

• Defined key milestones and exit criteria
  
  
• Created a high-level project plan (20 tasks)
  
  
• Grew it to 50+ tasks within 2 months
  
  

Templates, weekly update formats, testing scripts, and recordings helped new hires deliver consistently from day one.

2. Train your taxi drivers with implementation bootcamps

With engineers initially leading the second product rollout, knowledge transfer became key. The team:

• Ran internal bootcamps by engineers for PS
  
  
• Centralized docs (moving away from Slack chaos)
  
  
• Created examples for every step: kickoff slides, testing scripts, timelines
  
  

“We had templates on templates on templates. Notion, Gong recordings, docs all in one hub.” – Zul

They also adopted documentation standards, created SME tracks, and ensured that implementation engineers could now not only deliver but teach newer teammates. This multiplied their effectiveness without increasing headcount too early.

3. Turn PS into a business, early

You might not need bookings in Series A. But wait too long to monetize, and you’ll struggle to change sales behavior.

Clutch’s approach:

• Flat PS fee: 20% of ARR, regardless of effort
  
  
• Don’t optimize for margin yet, optimize for muscle memory.
  
  
• Get sales compensated on PS to align incentives
  
  

“We didn’t even know how many hours projects took. But we added the PS fee line item so sales never skips it.” – Daniel

Assembly lines and specialization

With implementation becoming more repeatable, the Clutch team shifted focus to specialization:

Creating SMEs and role clarity

Some team members became:

• Product SMEs (e.g. integrations)
  
  
• Cross-functional liaisons
  
  

This reduced dependence on engineers and ensured knowledge stayed within PS.

They also formalized responsibilities and internalized enablement. PMs knew which lane they operated in, IEs were equipped with templates for edge cases, and SMEs became force multipliers across projects.

Avoiding over-specialization

Daniel warned: “Do you need 4 roles on every call? Or can one person wear multiple hats?”

Balance efficiency with expertise. Hire generalists who can grow into specialists.

Tooling up with Rocketlane

As Clutch moved toward the “bus and subway” stage, they needed tooling that supported their maturing methodology. Rocketlane became the backbone.

Why it worked:

• Enablement inside project plans: kickoff task = slide template + sample + Gong clip
  
  
• Health monitoring: project load, CSAT, time-to-value, IE bandwidth
  
  
• Onboarding ramp: new hires launched within weeks
  
  

“If we hired a PM off the street, they could run a kickoff by just following Rocketlane’s instructions.” – Jake

Rocketlane also allowed them to move beyond spreadsheets for managing time to value. By tracking IE bandwidth and automating status updates, they preempted delivery bottlenecks and improved partner satisfaction.

Mistakes to avoid in your PS scale journey

The Clutch team shared what not to do:

1. Hiring too fast, too early

• Requests are easy to approve but expensive to sustain
  
  
• If you hire fast, make sure there’s utilization and long-term value
  

2. Over-complicating roles

• Don’t split the PM, solutions, BA, and engineer too soon
  
  
• Combine roles until processes and volume demand separation
  

3. Waiting too long to track metrics

• Start tracking time cards, time-to-value, and utilization early
  
  
• Even if the data isn’t perfect, you’ll learn what to baseline
  
  

“If you’re Series C and just starting timecards, you’re already behind.” – Daniel

What changed in 12 months

In 2024:

• Launched 50 clients
  
  
• 20+ were on new products
  
  
• Cut time-to-value from 6 months to 10 weeks
  
  

Revenue wins:

• $891K in professional services sold in Q4 + Q1
  
  
• Without discounting or cannibalizing software ARR
  
  

The secret? Building the foundation while delivering, without waiting for perfect maturity.

Final takeaways for PS and onboarding leaders

1. Build tooling that learns and grows. Your product changes weekly. Your tools should adapt.
2. Empower taxi drivers first. Don’t wait for subways. Hire people who can drive without GPS.
3. Monetize early. Not for margin, but for mindset. Make PS a habit for sales.
4. Centralize your enablement. Templates, recordings, and scripts in one place = faster onboarding.
5. Use Rocketlane to scale repeatability. It’s your subway map for implementation.
6. Focus on enablement, not just execution. Turn IEs and PMs into multipliers by empowering them with tooling, documentation, and autonomy.
7. Design for today, but build for tomorrow. Put processes in place now that support specialization and monetization as scale hits.

Check out the rest of our Propel25 recaps here and subscribe for more insight-driven lessons from top PS and onboarding teams.