gstack Office Hours: The AI That Asks Hard Questions

The most valuable hour I've spent at YC wasn't a lecture or a workshop. It was a 20-minute meeting where a partner asked me three questions I couldn't answer well — and I walked out knowing exactly what was wrong with my product strategy.

That kind of critique is rare. Most of the time, the people around you are too polite, too busy, or too invested in your success to push back hard on your assumptions. The result: you build things based on unchallenged premises, and you don't find out you were wrong until a customer tells you.

gstack's Office Hours phase simulates that YC experience systematically. It's not comfortable. It's useful.

What YC Office Hours Actually Does#

To understand why gstack's Office Hours phase is designed the way it is, it helps to understand what YC office hours actually do.

A typical session:

You walk in excited about your new feature. You explain it. The partner listens, asks two questions, and then says: "Okay, but who specifically wants this? Walk me through the last three times a user asked for it."

If you can answer that, you move on. If you can't, the premise of the feature is already in doubt.

The questions aren't random. They're designed to stress-test your assumptions:

• Who specifically has this problem?
• How do you know they have it? What evidence do you have?
• Why is your solution better than what they do today?
• What's the riskiest assumption here?
• What would have to be true for this to be wrong?

These questions are uncomfortable because they expose uncertainty. That's the point.

gstack's Office Hours Phase#

In DenchClaw's gstack workflow, the Office Hours phase is the first step in any significant work.

It produces:

• A clear statement of what you're building and why
• The core assumptions being tested
• The riskiest assumptions that could invalidate the approach
• A design document that captures the thinking before any code is written
• A set of success criteria to know if the work actually achieved its goal

The AI plays the role of the skeptical partner. It asks follow-up questions. It doesn't accept vague answers. If you say "users want a better experience," it asks what specifically that means, based on what evidence.

This sounds straightforward. In practice, it's surprisingly clarifying. Most of the features that feel obvious feel less obvious when you have to explain them from first principles.

A Real Example#

Here's what an Office Hours session might look like for a new DenchClaw feature:

Me: I want to build a calendar integration that syncs meetings from Google Calendar into the CRM automatically.

Office Hours AI: What specifically do you mean by "syncs"? What data moves in which direction?

Me: Meeting records with attendees, timestamps, and notes.

Office Hours AI: What happens to that data in the CRM? What does a user do with it that they can't do today?

Me: They can see meeting history associated with a contact or deal without manually logging calls.

Office Hours AI: How do users currently track meeting history? How often does incomplete meeting logging actually cause problems for them?

Me: ...most users don't log meetings at all because it's too much work.

Office Hours AI: So the real problem isn't "sync Calendar to CRM" — it's "meeting logging is too high friction, so it doesn't happen, so history is lost." Are there other ways to solve that problem that might be simpler than a full Calendar integration?

The feature didn't change immediately. But the conversation sharpened the problem statement significantly, which changed how the feature was scoped and prioritized.

Why This Works#

A few reasons the Office Hours phase is effective:

It forces explicit reasoning: Most product decisions happen through gut feel and discussion, not written reasoning. Office Hours requires you to articulate the reasoning explicitly. Articulation reveals gaps.

It's non-judgmental: You're more willing to admit uncertainty to an AI than to a colleague whose opinion of you matters. This means you get more honest answers.

It's available when you need it: The best time to question your assumptions is before you start building, not after. Office Hours is available at 11pm on Saturday when you're planning Monday's sprint.

It has no agenda: A human advisor might be too invested in a particular direction. The AI asks the same hard questions regardless of where the conversation leads.

When to Run Office Hours#

Not everything needs Office Hours. Here's when it's worth the time:

Run Office Hours when:

• You're about to start a feature that will take more than 1 day
• You're making a significant architectural decision
• You have competing approaches and aren't sure which to take
• You're building something based on an assumption you haven't explicitly validated
• Something feels off but you can't articulate why

Skip Office Hours when:

• You're fixing a known bug with a clear solution
• You're making a small UI change with clear requirements
• You're in the middle of an already-planned sprint

The goal isn't to add process for its own sake. The goal is to catch bad assumptions before you've spent a week building on top of them.

The Design Document Output#

gstack's Office Hours phase doesn't just generate questions — it generates a design document.

The design document captures:

• Problem statement (with evidence)
• Proposed approach and alternatives considered
• Core assumptions and how they'll be tested
• Success metrics
• Edge cases and risks
• Dependencies

For a solo developer or small team, this document is often the entire planning process for a feature. For a larger team, it's the input for the Engineering and Design planning phases.

The document lives in DenchClaw as an entry document linked to the feature or project. When you're done building and need to evaluate whether you achieved what you set out to, it's right there.

The Hard Questions That Matter Most#

If I had to distill Office Hours to five questions that matter most:

1. Who specifically is this for? Not "developers" or "sales teams" — who specifically? With what specific context?

2. What do they do today? The current alternative is your real competition, not the obvious competitor. If users export to Excel, your real competition is Excel.

3. What evidence do you have that they want this? Anecdote, survey, usage data, direct conversation? How strong is the signal?

4. What's the minimum version that tests the hypothesis? Not "what's the MVP we can build fast?" — "what's the smallest thing that tells us if we're right?"

5. What would have to be true for you to stop working on this? Knowing your exit condition in advance makes the decision easier when you get there.

gstack's Office Hours asks these questions systematically. The answers shape everything that comes after.

Frequently Asked Questions#

How long does an Office Hours session take?#

For a small feature: 15-20 minutes. For a significant feature or architectural decision: 30-45 minutes. The time is almost always worth it — catching a bad assumption in 20 minutes beats spending a week building on it.

What happens if I can't answer the Office Hours questions well?#

That's the information. If you can't clearly articulate why you're building something, who it's for, and what success looks like, you're not ready to build it. Go find the answers first — talk to users, review support tickets, check analytics. Then come back.

Is Office Hours AI as good as a real YC partner?#

No. A real YC partner has pattern recognition from hundreds of startups, specific domain expertise, and the ability to connect you with resources. The Office Hours phase provides a systematic questioning process. It's a useful tool, not a replacement for experienced advisors.

Can you run Office Hours on a feature that's already built?#

Yes, as a post-mortem or as a way to evaluate whether to keep it. "We built this three months ago. Let's run Office Hours on it now." The questions often reveal why it's underperforming or why it's working better than expected.

Should every team member be able to run Office Hours, or just technical leadership?#

Everyone who makes product decisions should be able to run it. The questions are relevant to any function — engineering, design, product, even marketing. The process of making assumptions explicit is valuable regardless of role.

Ready to try DenchClaw? Install in one command: npx denchclaw. Full setup guide →