How a B2B SaaS Founder Uses Claude AI for Planning (Case Study)

This is a case study about Rohan — a founder of a seven-person B2B SaaS company in the legal tech space. He’s at Series A conversations, managing a small team, and personally covering sales, product, and investor relations simultaneously.

It’s a composite portrait drawn from patterns we see repeatedly among founders at this stage: the specific company details are illustrative, but the planning failures and fixes are real.

The Baseline: What Planning Looked Like Before

Rohan’s planning approach before Claude was a combination of a task manager (Linear for product, a personal Notion page for everything else), a weekly team standup, and ad-hoc calendar blocking.

It mostly worked for execution. What it didn’t do was help him reason about allocation.

“I knew what was on my list,” he says. “I had no reliable way of figuring out whether I was working on the right things. I’d end a week having done a lot and still feel like I’d missed something important.”

The pattern he recognized in retrospect: he was optimizing for completion of individual tasks rather than progress on the things that actually moved the company forward. His planning system tracked what he was doing but didn’t challenge whether he was doing the right things.

A second problem: reactive drift. Every week started with a plan. By Wednesday, the plan was irrelevant. A customer issue, an investor query, an unexpected engineering problem — each one reasonable, collectively devastating to the week’s original intent.

He tried several approaches: time-boxing, the Eisenhower matrix, a daily “big three” ritual. Each helped temporarily and then faded as company complexity increased.

Version 1: The Generic AI Planning Attempt

Rohan’s first attempt at AI planning was conversational, undirected, and not very useful.

He would open a chat with Claude or ChatGPT and describe his situation. The output was well-organized advice — structured thinking about prioritization, frameworks for deciding what to delegate, questions to help him reflect.

Valuable, occasionally. But not a planning system.

“It felt like talking to a smart productivity coach. Useful for a session, but nothing carried forward. I’d get to the next week and start from scratch.”

Two problems were compounding: no persistent context (every conversation started blank) and no structured output (plans came out as prose, not actionable documents).

He recognized that the tool wasn’t the problem. The setup was.

The Rebuild: Setting Up the Planning Project

Rohan built a dedicated Claude Project. He spent about 90 minutes on the initial setup — writing system instructions, uploading two reference documents, and running a verification conversation.

His system instructions included:

You are my planning partner. Context about my situation:

Role: Co-founder and CEO of a 7-person B2B SaaS company (legal tech, Series A conversations in progress)
My function split: ~40% product/engineering, ~35% sales, ~25% investor/admin

Current quarter goals:
1. Close 3 new enterprise accounts (currently at 1 signed, 2 in late stages)
2. Ship the document automation feature by [date]
3. Get to 85% NRR from current customer base

Standing constraints:
- Team standup: Monday/Wednesday/Friday 9:30am (30 min)
- Board update prep: first Sunday of each month
- Weekly 1:1s: Tuesday and Thursday afternoons (3 × 30 min each)
- Investor calls: ~3 hours/week, unpredictable timing

My planning failure patterns:
- I consistently pull focus toward product work when under stress, even when sales is the actual priority
- I underestimate how much context-switching costs me — assume 30 min of lost productivity per transition
- I say yes to introduction calls that don't lead anywhere

When planning, always:
- Ask me what the 3 most important things for company progress are BEFORE suggesting task priorities
- Flag when I'm trying to split deep work across more than 2 major work streams in a single week
- Tell me when I'm over-scheduled. I am almost always over-scheduled.

The specificity matters. The “planning failure patterns” section is the most important addition — it encodes self-awareness about recurring mistakes directly into the planning conversation.

He uploaded two documents: his current company one-pager and a short “decisions log” he’d been keeping — a running list of major choices made in the last six months and the reasoning behind them.

The Weekly Rhythm That Stuck

Rohan settled on three recurring planning conversations, each with a specific trigger and prompt structure.

Sunday evening: Weekly Plan

He runs this in about 20 minutes. He pastes his calendar for the week, lists his carry-over items, and gives an honest energy forecast. Claude produces a weekly Artifact — a table with each day’s focus block, priority tasks, and admin window.

The adjustment he made after the first few weeks: he added a “Flags” column to the Artifact format. This forces Claude to surface its concerns visibly rather than embedding them in prose.

“That column is the most useful part. It tells me where the week is fragile before it starts.”

Each morning: Daily Check-in

A five-minute conversation. He pastes today’s row from the weekly Artifact, notes what’s changed, and gives his energy level. Claude confirms or adjusts the priority order.

He was initially skeptical that a five-minute conversation adds value. After six weeks, he stopped skipping them.

“It’s not that Claude tells me anything I don’t already know. It’s that saying it out loud to something that responds makes it harder to ignore.”

Friday afternoon: Retrospective

The hardest conversation to maintain consistently, and the most valuable one.

His prompt includes the original weekly plan, a brief honest account of what happened, and the list of items that got pushed. He asks Claude to diagnose specifically — not “be more realistic” but “where exactly was my estimate wrong and does this reflect a pattern.”

After the first month, the retrospectives identified two clear patterns: he was systematically underestimating sales activity by about 40% in his weekly plan, and he was scheduling deep product work on Fridays despite consistently low focus on Fridays.

Both findings went back into his Project instructions as calibration notes. The next month of planning was noticeably more accurate.

The Priority Triage: Handling Chaos

The planning system didn’t eliminate reactive chaos. It gave him a faster way to recover from it.

When a customer escalation, investor query, or team emergency arrived mid-week and disrupted his plan, he’d run a quick triage:

My plan got disrupted. Here's the situation: [2-sentence description of what happened]

Here's what's left undone from this week: [list]
Here's what just got added: [the new thing]
I have [X] hours left today and tomorrow.

Triage this. Tell me the 3 things to do, the 2 things to defer to next week, and whether anything can be delegated. Be direct.

The “be direct” instruction reduced the hedge in Claude’s triage responses. The explicit “can anything be delegated” question forced him to surface that option, which he says he otherwise wouldn’t naturally consider in a reactive moment.

Where the System Created Friction

The planning system didn’t solve everything, and it created some friction of its own.

The biggest frustration: Claude’s plans don’t automatically sync to his calendar or task manager. The Artifact exists in Claude’s interface. Getting it into his actual workflow required manual transfer — copying tasks into Linear, blocking time in Google Calendar by hand.

This friction was real enough that he started using Beyond Time as the bridge layer — taking the Claude-generated plan and turning it into a structured, calendar-aware schedule. The combination reduced the copy-paste burden significantly.

A second friction: the system requires discipline on bad weeks. When a week went badly, the Friday retrospective felt exposing. He’d find himself skipping it or running it perfunctorily.

His fix was structural: he scheduled the retrospective as a non-negotiable calendar event, 4:30–5pm Friday, with a reminder that fired regardless of how the week went. “I treat it like a board meeting. I don’t skip board meetings because they’re uncomfortable.”

Six Months In: What Changed

Rohan has been running this system for six months. The outcomes he reports aren’t dramatic transformation narratives — they’re more specific than that.

His planning accuracy improved. He now estimates his sales work within roughly 20% of actual (down from 40% off). He recognizes the Friday focus problem and no longer schedules creative work on Friday mornings.

More concretely: he stopped ending weeks surprised by what hadn’t gotten done. The weekly retrospectives built enough pattern recognition that the surprises became smaller.

“I still have chaotic weeks. The difference is I recover from them faster. The planning system gives me a way back in.”

What This Case Study Actually Shows

The outcomes above are modest by the standards of productivity writing. No breakthrough. No 10x output.

What the case study actually demonstrates is something more useful: that a planning system built around Claude’s architecture — Projects for persistence, Artifacts for structured output, typed conversations for different planning needs — can survive contact with real work conditions.

That’s the relevant test. A planning system that works perfectly in a calm week and collapses on a chaotic one isn’t a planning system. It’s a planning ritual.

Your action: If you’re a founder or solo operator, look at your last three weeks of work and identify the two most common categories of items you consistently pushed. Write those as “planning failure patterns” and add them to your Claude Project instructions today.

Related: The Complete Guide to Planning with Claude AI · The Claude AI Planning Framework · How to Plan with Claude AI Step by Step · Complete Guide: Setting Goals with AI

Tags: founder planning AI, Claude AI case study, B2B SaaS productivity, Claude Projects planning, startup planning system