The questions you ask before you commit
What to do instead of inventing the context you were not given — and how to find the one question whose answer would change the whole plan.
Lesson one ended with an instruction and no method: draft the one-pager using only the raw Slack message, and resist the urge to invent extra context you don’t have yet. Good discipline. It also leaves you standing in front of a half-filled page, which is an uncomfortable place to be and a tempting one to guess your way out of.
This lesson is what to do instead. The gap you are closing is between “I don’t have enough information” and “here are four questions, and here is the one that actually matters.” The first is a complaint. The second is a plan.
Asking is the senior move, not the junior one
Most engineers under-ask, and they under-ask for a reason that feels like professionalism at the time: questions look like ignorance, and answering your own questions looks like initiative. So you pick the interpretation that seems most likely, build against it, and find out in review that you guessed wrong about something nobody thought to say out loud because it was obvious to them.
Invert it. Guessing to look competent optimises for how you appear this week. Asking optimises for whether the plan survives the quarter. The engineer who says “before I scope this, I need to know whether Okta specifically or any identity provider” is not admitting a gap in their knowledge — they are pointing at a gap in the ask, and that is a different thing entirely.
Four things that go missing
Under-specified asks fail in predictable directions. These four categories generate almost every useful question, and they map onto the four sections you drafted in lesson one:
1. The unstated user
“Their employees” is doing enormous work in that Slack message. All employees, or a pilot department? Do contractors count? Is there an admin who needs to manage the rest, and is that a different product surface? “Users” that turn out to be two distinct populations with different needs is one of the most expensive discoveries you can make late.
2. The unstated scale
How many people, by when, and growing how fast. “Next quarter” is a deadline someone typed, not a constraint anyone validated — ask what happens on the day after it passes. Sometimes the honest answer is “nothing, that was aspirational,” and you have just bought a month.
3. The unstated constraint
What genuinely cannot change, versus what merely hasn’t been questioned. This is where the money usually is, and it is the category the SSO ask fails hardest.
4. The unstated success
Who decides this is done, and what would they need to see? Lesson one had you write success criteria. If you invented them rather than received them, they are hypotheses — and hypotheses belong on this list.
The load-bearing question
Four categories will get you eight or ten questions, and you cannot send ten questions to a VP of Sales without looking like you are stalling. So you rank them, and the ranking is not by how curious you are.
A question is load-bearing when different answers lead to different plans. Everything else is nice-to-know: interesting, sometimes clarifying, but the work is the same either way. Ask the load-bearing ones first, because they are the only ones whose answers can invalidate work you have already done.
On the SSO project, the load-bearing question is this one:
Is Okta specifically the requirement, or is “Okta” this prospect’s shorthand for “our identity provider”?
Look at what turns on the answer. If it is Okta and only Okta, you build one integration against one vendor’s documentation and you are plausibly done next quarter. If “Okta” is shorthand — and the two other deals in the pipeline suggest it might be — then the real requirement is generic SAML or OIDC, which is a different architecture, a different test matrix, and a different number. Same Slack message, two projects, and every estimate you produce is worthless until you know which one you are in.
Contrast that with “how many employees does the prospect have?” Worth knowing. But you build the same thing for 400 seats as for 4,000, so it does not change the plan and it does not go first.
Retrieval check
Without scrolling up: what property makes a question load-bearing, and why does that property mean it has to be asked first rather than eventually?
Check your answer
Different answers produce different plans. That is the whole test. It has to go first because it is the only kind of question whose answer can invalidate work already done — ask it late and you pay for the guess twice, once building and once rebuilding. Nice-to-know questions can be answered at any point precisely because nothing downstream branches on them.
Asking without sounding like you are stalling
Here is the part nobody teaches, and it is the reason good engineers ask fewer questions than they should. A question sent up the chain reads as a blocker. You have handed the work back and stopped, and the person on the other end now owes you something before anything can move. Do that twice and you acquire a reputation for friction.
The technique that fixes this is to convert the question into an assumption with an expiry date:
“I’m scoping this as generic SAML rather than Okta-specific, which is the larger of the two options. If the prospect genuinely only needs Okta, tell me by Friday and the estimate comes down.”
Three things happen at once. You are not blocked, because you have a default and you have started. The decision is visibly still theirs, and the cost of ignoring you is stated rather than implied. And you have created a record — if Friday passes in silence and the assumption turns out wrong, that is a conversation about their reply, not about your guess.
Where people get burned
Assume in the direction of the larger scope, not the smaller one. An estimate that comes down when someone corrects you is a good day. An estimate that doubles in week three is the one that costs you the room’s trust.
Now apply it: interrogate the SSO ask
Back to your one-pager. You wrote it deliberately starved of context; this is where you find out which of the gaps actually matter.
Hands on
Find your load-bearing question
Done when: You can name the single question whose answer would most change your plan, written as an assumption someone can correct.
- Re-read the Problem and Why now sections of your lesson-one draft. Didn’t write one? Use this and carry on: enterprise buyers require identity-provider login and won’t sign contracts without it; one $400K deal is blocked today and two more are asking.
- Write five questions, aiming for at least one from each of the four categories — unstated user, scale, constraint, success. Five is the constraint; if you have twelve, you are listing rather than choosing.
- Mark each one load-bearing or nice-to-know. The test is a sentence you should be able to finish out loud: “if the answer were X instead of Y, I would build ______ differently.” If you can’t finish it, it’s nice-to-know.
- Pick the single most load-bearing question. If two feel tied, ask which one, answered wrongly, would waste more weeks.
- Rewrite it as an assumption with an expiry date and a named direction: what you are assuming, why you chose that direction, and by when someone must correct you.
- Bring the five questions and your rewritten assumption into the chat. I’ll push back the way the VP would — including on any question you marked load-bearing that isn’t, which is the most common mistake on a first attempt.
What this does not cover
You now have a framed problem and a defensible set of assumptions. What you do not have is a proposal anyone can review — the document that says how you intend to build it and invites people to disagree before you start. That is the design doc, and it is where this course goes next.
The terms it will assume — RFC, design doc, ADR — are pinned down on the glossary page, and this is a good moment to skim it if you haven’t.
Read this next — primary source
The Mom Test — Rob Fitzpatrickmomtestbook.com
It is written for founders interviewing customers, not engineers reading Slack, and it is worth your evening anyway. The whole book is about one thing: what people say they want is not data, and there is a specific way of asking that gets you facts instead. Your VP of Sales reporting what a prospect said is exactly that problem, one hop removed. Read it for the questioning technique and translate the context as you go.
Stuck, curious, or think this lesson is wrong? Ask your teaching agent. The lessons are the scaffold; the conversation is where the learning gets unstuck.