How One Founder Used AI to Run Her Annual Planning Session: A Case Study

What follows is a composite case study based on how knowledge workers and founders have applied the Annual Architecture framework. The details are representative, not drawn from a single individual.

Meet Chiara

Chiara Voss is the founder of a B2B SaaS company that helps operations teams at mid-market manufacturers track compliance documentation. She started the company three years ago, brought on her first two employees in year two, and ended year three with fourteen paying customers and enough revenue to run comfortably for another eighteen months.

By most measures, year three was good. By her own assessment, it was scattered.

“I felt like I was always reacting,” she said. “Product decisions, sales conversations, team issues — I handled them well in the moment, but I never felt like I was building toward something specific. The year happened to me more than I made it happen.”

This is the experience that the Annual Architecture framework is designed to address. Not a failing year — a reactive one.

The Retrospective: Two Hours of Honesty

Chiara set aside a Sunday morning in mid-December for her retrospective. She had been keeping a weekly log — a brief Friday note capturing what she accomplished, what got stuck, and one observation about the business — for most of the year. She also had her time data from Beyond Time, which she had been using since August.

The combination gave her two views of the year: a qualitative, narrative view from her weekly logs and a quantitative view from her tracked time. Before AI, reconciling these would have required hours of manual synthesis. Instead, she pasted both into a planning conversation and ran the retrospective synthesis prompt from the Annual Architecture framework:

“Here is my weekly log from the past year [pasted] and my time distribution summary by category [pasted from Beyond Time]. Please help me identify: (1) my three biggest actual accomplishments, (2) where I overinvested relative to my stated priorities, (3) patterns in what derailed my plans, and (4) one sentence that captures what kind of year this was overall.”

The response surfaced three things Chiara had sensed but not articulated clearly.

First, her most meaningful accomplishment was not the revenue number or the customer count — it was building a sales process that worked without her direct involvement. She had hired a part-time account executive in Q3, and the first three deals that person closed independently were the year’s clearest evidence of leverage.

Second, her time data showed she had spent approximately 35% of her working hours in reactive customer support — handling issues that her documentation and onboarding process should have prevented. She knew this was a problem but had not seen the magnitude.

Third, her weekly logs showed a recurring pattern: the weeks that felt most productive were weeks with a clear, single priority stated at the start. The scattered weeks — and there were many — had no stated priority at all.

That last observation would become the seed of her annual theme.

Setting the Theme: “Signal”

After the retrospective, Chiara ran the theme generation prompt with her retrospective insights as context. She received five candidates:

1. Signal — emphasizing clarity over noise, cutting through reactive work to focus on what matters most
2. Foundation — building the systems and processes that would reduce the reactive burden
3. Leverage — doubling down on what was already working rather than adding new initiatives
4. Depth — going deeper with existing customers rather than chasing new ones
5. Readiness — preparing the company to scale without her being the bottleneck

She sat with the list for twenty minutes. Foundation, Leverage, and Readiness all described tactics. Signal described something closer to an orientation — a way of filtering decisions, not just a category of work.

“Signal felt like it had a cost,” she said. “Choosing signal meant accepting that I would drop things that were not signal. That felt right. The year had too much noise.”

Her theme: Signal.

The Three BHAGs: Calibration in Real Time

With her theme set, Chiara drafted three BHAGs:

1. Launch version 2.0 of the product with full compliance automation — the feature her most important customers had been requesting for two years
2. Reach twenty-five active paying customers by December
3. Work fewer than forty-five hours per week for at least forty weeks of the year

She ran the calibration prompt:

“I am considering these three annual goals: [list]. For each, tell me: (1) Is this achievable in 12 months with serious but sustainable effort? (2) Does it require new capability or just more of what I already do? (3) Are these three goals coherent — do they reinforce each other, or do they compete for the same resources? (4) What is the most likely failure mode for each?”

The coherence analysis produced the most useful insight of the entire session.

The AI flagged that BHAG 1 (product launch) and BHAG 3 (working hours cap) were likely to conflict in Q2 and Q3, when a product launch of this scope would naturally generate a spike in engineering coordination, customer communication, and bug triage. Building the hours cap as a year-round commitment without accounting for the launch intensity was either going to break the hours goal or compromise the launch quality.

The suggested resolution: treat Q1 as the period to aggressively build the systems and documentation that would prevent reactive work from spiking during the launch. Front-load the Foundation work to protect both goals simultaneously.

Chiara revised her BHAGs slightly — the hours goal became a Q1 priority rather than a year-round commitment from day one — and added a Q1 explicit milestone: reduce reactive support time from 35% of her hours to below 20%.

The Quarterly Arcs: Four Chapters of the Same Story

With three BHAGs calibrated, Chiara ran the quarterly arc design prompt for each. Rather than reproducing all twelve arcs here, the logic is clearest in her first BHAG.

BHAG 1: Launch version 2.0 with full compliance automation

• Q1 arc: Internal systems and documentation rebuilt so that onboarding and support no longer require founder involvement; engineering team has completed the architecture design for v2.0 and is ready to build
• Q2 arc: Core v2.0 features are in private beta with three existing customers; first feedback incorporated; customer success can handle support independently
• Q3 arc: v2.0 is in limited general availability; two new customers acquired on v2.0 specifically; launch go-to-market materials complete
• Q4 arc: Full v2.0 launch complete; at least five customers on the new version; post-launch support volume has stabilized; retrospective on launch process documented

What Chiara noticed when reading her four arcs: they told a story. Q1 was preparation. Q2 was testing. Q3 was limited launch. Q4 was full launch and consolidation. The narrative made the plan easier to hold in mind — she could recall “Q2 is testing” without consulting a document.

The First Sprint: Getting Specific

With Q1’s arc defined, Chiara built her first 12-week sprint for each BHAG. For BHAG 1:

Sprint goal: Systems rebuilt, support time reduced, v2.0 architecture complete and approved by engineering team

Lead indicator: Number of support tickets resolved without founder involvement (target: 90% by week 8)

Weekly milestone sequence (abbreviated):

• Weeks 1–3: Document all recurring support scenarios; build self-serve knowledge base
• Weeks 4–6: Train account executive on support handling; hand off first-tier tickets
• Weeks 7–9: Validate architecture design with engineering team; finalize v2.0 scope
• Weeks 10–12: Engineering team begins first sprint on v2.0; Chiara transitions to review and unblock role

The specificity of the weekly milestones meant that at the start of any given week in January, February, or March, Chiara knew exactly what “on track” looked like.

What Happened: The February Test

By the second week of February — the point at which most resolutions have collapsed — Chiara was on week six of her first sprint.

Her support ticket handoff was ahead of schedule. Her account executive was handling first-tier support independently by week five, and the knowledge base had already reduced incoming ticket volume by roughly a third. The engineering team was two weeks into v2.0 architecture work.

The hours goal was harder. There were two weeks in January when she worked over fifty hours, both driven by customer issues that the new support process had not yet fully absorbed. But the trajectory was right: the reactive work was decreasing, not increasing, and she had a lead indicator to show it.

More importantly, she knew what she was doing and why. The week that felt scattered in the previous year now had a shape: BHAG 1, Q1, Week 6, milestone on track.

What the Case Study Demonstrates

A few observations worth naming explicitly.

The retrospective was not optional. Without the time data and the weekly log synthesis, Chiara would have entered annual planning with approximate impressions rather than actual data. The specific insight — that reactive support consumed 35% of her time — was not something she had consciously quantified before running the retrospective prompt.

The coherence check earned its place. The conflict between the product launch and the hours goal was not obvious until the AI surfaced the shared capacity dependency. Discovering that in December is far less costly than discovering it in June.

The theme did work. By late January, Chiara had declined two partnership conversations and one investor meeting on the grounds that they were “not signal” — they required reactive attention that would have added noise without advancing any of her three BHAGs.

The One Action for Founders Reading This

Block two hours this week — not “sometime in January,” specifically this week.

Run the retrospective synthesis prompt with whatever data you have: a calendar export, a project list, your own memory if that is all you have. The data quality improves the output, but the process works even with rough inputs.

The Annual Architecture takes less time than a half-day offsite and produces a plan specific enough to answer the question “what should I be doing right now?” on any given Tuesday in March.

Related reading:

• The Complete Guide to Annual Planning with AI
• The Annual Architecture: A Step-by-Step AI Planning Framework
• The Complete Guide to Quarterly Planning Frameworks

Tags: annual planning, founder productivity, case study, AI planning, goal setting