New York City

The best systems don't create more work — they make the work disappear.

I'm Stevon Judd — a technology and platform leader who designs systems that help companies operate with less friction, more reliability, and better execution. Across MongoDB, SquadTrip, and advisory work, I've built AI-assisted workflows, platform strategies, and operational systems that turn complexity into scale.

0-disruption platform sunset 40% restore-time improvement $10M SaaS scale Techstars NYC '22
Scroll

How I improve operations

01

I translate complexity into systems.

I connect engineering, product, operations, and executive priorities so teams can make better decisions faster. The work is not just alignment — it is turning ambiguity into repeatable operating systems.

Evidence: At MongoDB, I translated customer SLAs into infrastructure investment priorities that engineering could execute against. At SquadTrip, I'm the person who talks to the payment processor, the angry customer, and the engineer — in the same hour.
02

I use AI to remove operational drag.

I identify repeated manual work, decision bottlenecks, and coordination overhead, then design AI-assisted workflows and internal tooling that reduce friction without adding complexity.

Evidence: Built AI-assisted PRD, bug capture, and stakeholder response workflows that replaced hours of manual coordination. The point isn't novelty — it's removing the work that shouldn't exist in the first place.
03

I build platforms and workflows that scale.

From SaaS payments to data infrastructure, I focus on systems where reliability, automation, and customer trust matter. The goal is not more process. The goal is better operating leverage.

Evidence: Built a payments-enabled SaaS from zero to $10M in annual booking volume. Designed the architecture, shipped the code reviews, handled the support tickets, negotiated the payment processor contract. Full stack of ownership.
04

I know when to automate, when to simplify, and when to hold the line.

Not every problem needs AI. Not every risk needs a meeting. I calibrate the right operating model based on impact, reversibility, customer trust, and execution speed.

Evidence: Try the simulation below — it's built on real decisions. I've shipped features with manual workarounds to hit a window. I've also delayed launches that "felt ready" because the failure mode was catastrophic. Knowing which is which is the job.

I build tools, not just process

When I see repeated friction, I treat it like a product problem. I design workflows, prompts, templates, automations, and operating systems that help teams move faster with less manual overhead.

AI-Assisted PRD & Planning Workflows

Structured prompts that turn rough ideas into complete product requirements in minutes. Consistent format, right questions asked, ready for engineering review.

Planning → Execution

Automated Bug & Context Capture

Captures context, reproduces steps, and formats bug reports automatically. Engineers get what they need to fix it. No back-and-forth, no lost detail.

Friction → Flow

Customer & Stakeholder Response Systems

Templated and AI-assisted responses for common customer scenarios, stakeholder updates, and cross-team communications. Consistency without the cognitive load.

Repetition → Automation

Program & Launch Operating Systems

Frameworks for spinning up new programs and launches: stakeholder maps, risk registers, dependency tracking, status templates, workflow automation for internal operations. Start structured, not from scratch.

Chaos → Structure

The pattern: I treat my own workflow like a product. If I'm doing something twice, I'm building a system the third time. This is how small teams operate at scale — and how I bring founder discipline and AI-native operating leverage to any role.

Stories about building things that matter

MongoDB Technical Program Manager

How do you sunset a product that thousands of customers depend on — without a single disruption?

Ops Manager was legacy. Everyone knew it needed to go. But "legacy" doesn't mean "unimportant" — it means customers built their operations around it. Their alerts. Their workflows. Their trust.

The easy path was a hard cutover with a migration guide. The right path was understanding that for infrastructure products, reliability is the product. You can't ask customers to trust your new platform if you break their trust getting there.

I spent months in the ambiguity — mapping dependencies across four orgs, finding the customers who'd be hardest hit, building a transition that felt invisible. Not because invisible is impressive, but because invisible means we did our job.

We shipped a company-wide platform transition. Zero outages. Zero escalations. Most customers didn't even notice — which was exactly the point.

SquadTrip Founder

What happens when you can't hide behind process — because you have to build the process while building the product?

At big companies, program management often means inheriting systems that work. Your job is optimization. Coordination. Making the trains run on time.

When I started SquadTrip, there were no trains. No tracks. Just a problem I understood deeply — group travel is operationally brutal — and a belief that software could fix it.

I learned things you can't learn inside an enterprise: how to make decisions when you don't have data, how to ship when you're not ready, how to talk to customers who are angry because your product is their livelihood.

I also learned that most of what makes programs successful at scale — clarity, sequencing, knowing when to cut scope — matters even more when you have no margin for error.

Techstars NYC '22. Scaled to ~$10M in annual booking volume across 5,000+ travelers and 1,000+ trips.

MongoDB Platform Infrastructure

The metric that actually mattered wasn't on anyone's dashboard.

Backup systems are strange. When they work, nobody thinks about them. When they fail, it's the only thing anyone thinks about.

We had good backup metrics. Completion rates. Storage efficiency. The numbers looked healthy. But when I started talking to customers and support teams, I kept hearing the same thing: "Restores take forever."

Restore time wasn't a KPI anyone owned. It fell between teams — backup owned the data, infrastructure owned the pipes, nobody owned the experience of a customer watching a progress bar at 2am during an incident.

The fix wasn't technical. The fix was getting three teams to care about a metric that wasn't in their OKRs, then finding the infrastructure investments that would move it.

40% reduction in restore time. More importantly: a team that now thinks about customer experience, not just system performance.

Think you can ship it?

A real scenario from SquadTrip. Make the calls. See what happens.

SquadTrip — May 2023

The Summer Rush

Summer travel season starts in 3 weeks. You're about to launch Group Payment Splitting — the most requested feature from your biggest customers. Trip organizers can finally split costs automatically instead of chasing Venmo payments.

Engineering says it's ready. Marketing has already teased it. Your largest customer — a travel agency doing $400K/year on your platform — is planning their entire summer around this feature.

Then three things happen at once.

Monday Morning

The QA Flag

Your lead engineer pulls you aside. "The refund flow has edge cases we haven't fully tested. If someone partially pays, then requests a refund, then the trip gets canceled... I'm not 100% sure what happens to the money."

She estimates 4-5 days to properly test and fix. But that pushes you past the marketing launch date, and your big customer's first summer trip is in 18 days.

What's your call?

You chose: Delay the launch

Reasonable, but...

Marketing is frustrated — they've already sent the teaser email. Your big customer calls you directly, concerned. "We already told our travelers this was coming."

You spend the week managing expectations instead of shipping. The feature launches clean, but you've burned some trust and lost momentum.

The lesson: Delays have costs beyond the timeline. Sometimes the right call is scoping down, not pushing back.

You chose: Ship without refunds

Smart scope cut.

You ship on time. The 90% case works perfectly. You're transparent with customers: "Split payment refunds require a support ticket for now — full automation coming in 2 weeks."

Three refund requests come in that first week. Support handles them manually. No drama. The feature lands.

The lesson: Perfect is the enemy of shipped. Scoping down beats delaying when the core value still works.

You chose: Ship and hope

This will cost you.

Week two. A trip organizer cancels a trip mid-payment. The system creates a negative balance. Their bank flags it as fraud. They're locked out of their account for 3 days during their busiest booking period.

You spend the next week in damage control. The customer is furious. You fix the bug under pressure instead of properly.

The lesson: "It probably won't happen" is not a risk mitigation strategy. Edge cases in payments always find you.

Wednesday

The Compliance Surprise

Your payment processor sends an email: new money transmission regulations require additional disclosures for "payment facilitation services" — which is exactly what split payments are.

Legal review will take 5-7 business days. Without it, you could be operating in a gray area. Your processor has flagged accounts for less.

What's your call?

You chose: Full pause

Safe, but slow.

Legal takes the full 7 days. Turns out the regulation applies to a different payment model — you were fine all along. You lost a week to uncertainty that a single phone call could have resolved.

The lesson: "Wait for legal" isn't always the responsible choice. Understanding the actual risk often takes less time than waiting for formal review.

You chose: Limited rollout

Creative, but complicated.

You now have two launch tracks: existing customers get the feature, new customers don't. Your support team is confused. Your docs say one thing, your app says another.

Legal clears you on day 4. But you've created operational complexity that takes another week to unwind.

The lesson: Partial solutions often create more work than they save. Sometimes it's better to wait or push forward — but not both.

You chose: Pick up the phone

This is the move.

Your contact at the processor explains it in 10 minutes: the regulation targets platforms holding funds in escrow. You don't do that — money goes directly to trip organizers. You're fine. They confirm via email.

You share the email with legal, they confirm in 24 hours, and you're unblocked.

The lesson: Process isn't always the answer. Relationships and direct communication often resolve ambiguity faster than formal review.

Thursday

The Customer Call

Your biggest customer calls. They've already told their 200+ summer travelers that split payments are coming. Their first trip departs in 16 days.

"We've been partners for two years. I need to know — can we count on this, or should I tell my travelers to use Venmo again?"

You're 80% confident you'll ship on time. But it's not certain.

What do you tell them?

You chose: Promise delivery

Confidence without certainty is a liability.

You ship 3 days late. The customer already told their travelers. Now they look bad, and they blame you.

The relationship survives, but there's a crack in the trust. Next time they'll wait to see it live before they believe you.

The lesson: Promising certainty you don't have erodes trust faster than admitting uncertainty ever would.

You chose: Honest uncertainty

Trust is built in moments like this.

You tell them: "I can't promise the exact date. What I can promise is that I'll tell you the moment I know more, and if there's any risk to your June 15th trip, you'll hear from me by Monday."

They appreciate the honesty. They have a backup plan ready. You ship on time anyway — and now they trust you more because you didn't oversell.

The lesson: Customers don't need certainty. They need honesty and a partner who manages risk with them, not for them.

You chose: Buy time

Reasonable, but you're avoiding the conversation.

You call back with more information, but you've signaled that you didn't know your own status. They're slightly less confident in you.

The delay wasn't necessary — you had enough information to have a real conversation. You just didn't want to have it.

The lesson: "Let me get back to you" is sometimes just avoidance in professional clothing. Know when you're ready to have the conversation.

The Result

You shipped it.

Group Payment Splitting launched 2 days before your biggest customer's first summer trip. 847 travelers used it in the first month. Support tickets for "how do I collect money from my group?" dropped by 60%.

The feature became SquadTrip's most-used functionality. Three enterprise customers signed specifically because of it.

What this scenario is really about:

Program management isn't about having the right answers. It's about making decisions with incomplete information, communicating honestly under pressure, and knowing when to scope down versus when to hold the line.

Every choice in this simulation was one I actually faced — or something close to it.

Let's talk

What I'm working on

I'm building, advising, and thinking about what operations look like when AI stops being a feature bolted onto a product and starts being how the work actually gets done.

At SquadTrip, I'm rebuilding internal operations around AI-assisted workflows — replacing the meetings, docs, and manual coordination that used to be the cost of running a SaaS. The thesis is simple: most companies are still spending human time on work that no longer needs human attention. The companies that figure out how to remove that drag don't just save money — they outpace everyone still operating the old way.

I want to do that work at scale. That could be a full-time leadership role (AI Operations, Platform Product, Technical Operations, Platform TPM for infrastructure or data) — or a consulting engagement: an AI workflow audit, an operations design sprint, or fractional leadership embedded with your team.

Who I want to hear from:

  • Companies where complexity is slowing teams down and someone needs to turn ambiguity into execution
  • Founders rebuilding their operations layer around AI and want a sounding board (or a partner)
  • Operators thinking about the same problems — even if there's no engagement attached

Email me directly. I read everything.