Marcus runs a B2B SaaS company with two co-founders and no full-time employees. At the start of Q2, he had three goals he was genuinely committed to: ship a major product update, close four paying customers, and hire a first engineer.
By week six, he had made partial progress on all three and meaningful progress on none.
This is not an unusual situation for early-stage founders. It is, in some ways, the defining situation: too many genuinely important goals, not enough hours to pursue all of them simultaneously, and a workday that is structurally hostile to sustained focus on any single priority.
What Marcus did over the following seven weeks — using a Goal-Hour Budget and Beyond Time — is the subject of this case study.
The Starting Point: No Visibility
Before setting up the budget, Marcus ran a retrospective on weeks one through six of the quarter. He estimated how many hours he had actually spent on each goal.
The estimates:
| Goal | Target (if spread evenly) | Estimated Actual |
|---|---|---|
| Ship product update | 8 hrs/week | ~3 hrs/week |
| Close 4 paying customers | 6 hrs/week | ~2 hrs/week |
| Hire first engineer | 4 hrs/week | ~1 hr/week |
| Unbudgeted/reactive | — | ~8 hrs/week |
Total discretionary hours per week: approximately 18–20.
The retrospective was uncomfortable. Marcus’s stated first priority — the product update — was receiving roughly 37% of the hours it needed. His stated third priority — hiring — was nearly a phantom goal. And nearly half of his discretionary time was going to work that was not in his quarterly plan at all.
He knew, in the abstract, that this was happening. Seeing the numbers made it undeniable.
Building the Budget: The First Honest Conversation
Marcus used Beyond Time to structure the initial budget-building conversation. The key input was his actual discretionary hours — a more careful calculation than most founders do.
His week looked like this:
- Total hours worked: ~52
- Co-founder syncs and investor calls: 6 hours
- Customer support and operational tasks: 8 hours
- Email and Slack: 6 hours
- Other recurring admin: 4 hours
Discretionary hours: approximately 28.
This was higher than his original estimate of 18–20, because he had been unconsciously including time that was partly discretionary but often consumed by reactive work. The more accurate number was closer to 22–25 genuinely discretionary hours on a good week, 15–18 on a bad one.
He built his budget around 20 hours as the baseline, with the following allocation:
| Goal | Weekly Target | Rationale |
|---|---|---|
| Ship product update | 9 hours | Primary deliverable; directly drives customer conversations |
| Close 4 paying customers | 8 hours | Revenue; cannot defer — investors are watching |
| Hire first engineer | 3 hours | Critically important but longer horizon; protect minimum |
Total: 20 hours. Nothing left over for unbudgeted work in the ideal week.
The honest acknowledgment embedded in this budget: he could not give the product update and customer development equal time and do either well. The hiring goal was being deliberately deprioritized — 3 hours per week was a holding pattern, not a serious push.
Weeks 7–9: Building the Tracking Habit
The first two weeks of the budget were about establishing the daily log habit, not about optimization. Marcus logged each evening using Beyond Time’s input interface: goal, hours, brief description of what was worked on.
The first pattern appeared quickly: his actual product update hours were closer to 6–7 per week, not 9. The gap was not reactive work — it was scope creep within the goal itself.
He had been pulled into infrastructure work that felt necessary but was not on the critical path to the product update milestone. Two hours of database optimization. An hour on deployment configuration. These were real tasks, but they were not what the product update goal required.
The daily log description field caught this. “Worked on product update — 2 hours” became, in practice, “Worked on deployment config — 2 hours, which I tagged to product update but is actually infrastructure maintenance.”
At the week 8 review, Beyond Time surfaced the pattern: of the hours logged to the product update goal, approximately 30% were infrastructure tasks that were not advancing the actual feature milestone. Marcus had been double-counting: these hours felt like product work and were logged as such, but they were closer to maintenance.
This is a version of goal-adjacent busy work. The fix was a scope decision: explicitly exclude infrastructure from the product update goal and either budget it separately or handle it in administrative time.
Weeks 9–11: The Hiring Phantom
The hiring goal was the more difficult conversation.
In week 9, Marcus had a candidate conversation that went nowhere, spending approximately 45 minutes on a call that he had already privately decided was not the right fit. In week 10, he spent an hour rewriting the job description. In week 11, he spent 90 minutes on a sourcing conversation with a recruiter he was not sure he wanted to use.
Total hours in these three weeks: approximately 3.5 — just above his weekly target of 3, but spread over three weeks.
More importantly, none of these activities were on his defined critical path. His milestone for the hiring goal was: “extend an offer to a qualified candidate.” That required specific actions — defining the role clearly, sourcing candidates who matched, running structured interviews. He was doing activity in the vicinity of the goal, not activity that advanced the milestone.
In week 11, his Beyond Time weekly review generated a pointed question: “Your hiring goal has logged 3.5 hours over three weeks, and your milestone (extend offer) appears unchanged. What specifically needs to happen between now and the offer stage, and when will it happen?”
Marcus answered honestly: he was avoiding the parts of the hiring process he found most uncomfortable — the outbound sourcing and the structured interview design. The goal-adjacent activity was real procrastination wearing the costume of work.
The structural fix was task decomposition: break the hiring goal into specific sub-tasks with individual hour estimates, and track against those sub-tasks rather than against the vague “hiring” bucket. The most avoided tasks got scheduled first in the week, not last.
Weeks 11–13: Closing the Quarter
The final three weeks of the quarter showed measurably different patterns than weeks 1–6.
The product update shipped in week 12. The final two weeks saw Marcus averaging 8.5 hours per week on the goal — close to target — and the work was more clearly milestone-focused than in the earlier weeks.
Customer development had a strong final push. Weeks 11–13 averaged 9 hours per week on sales activity, slightly above the 8-hour target. One customer signed in week 12; a second was in late-stage conversations that would close in week 2 of Q3.
Hiring ended the quarter incomplete. One offer was extended but declined. Marcus had a second candidate in late-stage interviews. More importantly, the process was now well-defined and moving — which was a genuine advance on the phantom-goal status of weeks 1–8.
The final quarter accounting:
| Goal | Target (hrs over quarter) | Actual (hrs over quarter) | Status |
|---|---|---|---|
| Ship product update | ~117 hrs | ~98 hrs | Shipped (week 12) |
| Close 4 paying customers | ~104 hrs | ~112 hrs | 1 closed, 1 pending |
| Hire first engineer | ~52 hrs | ~29 hrs | Offer extended, process defined |
What Changed and Why
The Before/After is not primarily about discipline. Marcus did not become more motivated or more productive in some generalized sense. What changed was structural:
Visibility replaced assumption. Before the budget, Marcus had a general sense of his priorities but no mechanism for tracking alignment. After six weeks of logging, he knew — precisely, not approximately — where his time was going.
Log descriptions caught substitution. The requirement to describe what he actually worked on surfaced goal-adjacent work (infrastructure logged as product development, avoidance-activity logged as hiring work) that the category tag alone would have missed.
Weekly reviews converted data into decisions. The most important structural change was the Friday 20-minute review. Without it, the tracking data would have been informative but inert. The review created the moment where variance became a decision, not just a number.
Scope was documented and change-controlled. Explicitly separating infrastructure work from the product update goal — and acknowledging the hiring goal’s real status — removed the cognitive overhead of phantom progress.
The Takeaway for Other Founders
The recurring pattern across founders who try goal-hour budgeting is not that they lack discipline. It is that they have no mechanism for making the gap between stated priorities and actual behavior visible in near-real-time.
Quarterly goal reviews are too infrequent to catch allocation drift before it compounds. Daily task management is too granular to surface strategic misalignment. The weekly budget review is the right frequency for the right level of abstraction — strategic enough to see goal-level patterns, frequent enough to course-correct before significant damage is done.
The tool matters less than the practice. Marcus used Beyond Time. The same practice can be run with a spreadsheet and any AI chat interface. The non-negotiable elements are: a stated budget, honest daily logs, and a weekly review with a genuine commitment to acting on what the data shows.
Start with one goal and three weeks of data. That is enough to see whether the gap is real and what is causing it.
Frequently Asked Questions
-
Is this case study from a real person?
The patterns, numbers, and outcomes in this case study are drawn from typical experiences reported by founders and knowledge workers who have implemented goal-hour budgeting. The details are composited to protect privacy while representing realistic, common scenarios. The structural challenges described — meeting creep, phantom goals, scope expansion — are patterns we see consistently across users.
-
How long does it take to see results from goal-hour budgeting?
Most people notice behavior changes within the first two weeks simply from the act of tracking. Meaningful outcome changes — goals that were previously stalling begin to advance — typically appear in weeks three through six, once the pattern analysis starts producing actionable insights. Full calibration of the system, where weekly estimates are reliably accurate and review habits are stable, usually takes six to eight weeks.
-
What if I don't have a startup? Does this still apply?
Completely. The founder context makes the stakes vivid, but the structural challenge — limited discretionary hours, too many competing priorities, the tendency for reactive work to displace strategic work — applies equally to engineering managers, independent consultants, researchers, and anyone managing multiple significant objectives simultaneously.