The questions that turn a wishlist into a shippable epic.

An epic is a bet, not a wish. Before anyone commits engineering cycles, you have to be able to pitch it in a sentence and defend the scope in a paragraph. If you cannot, it is not an epic, it is a theme.

1. Q01What is the key feature or functionality being proposed?
2. Q02In one sentence, what does shipping this mean for a real user?
3. Q03Is this a single epic, or three epics wearing a trench coat?
4. Q04Which product theme, portfolio, or strategic bet does it roll up into?
5. Q05Is the epic name memorable, specific, and free of internal jargon?
6. Q06Is there a parent initiative, or is this the top of the tree?

Question B from your intake sheet lives here.

Epics are where personas stop being decorative. Name the audience with specificity, because the word "users" does not buy you anything.

1. Q01Who are the primary users or consumers of this feature or functionality?
2. Q02Which persona or segment, and how do we know they exist at scale?
3. Q03What is the job they are trying to get done (Jobs-to-be-Done)?
4. Q04What interviews, surveys, or analytics support the audience choice?
5. Q05Which customer segments are explicitly out of scope, and why?
6. Q06How would the audience describe the problem in their own words?

Question C from your intake sheet lives here.

An epic without a clock becomes a graveyard. Say why it matters now, not in general, because "in general" loses to the next fire-drill every week.

1. Q01Why is this feature or functionality important to implement?
2. Q02Which strategic theme, OKR, or annual goal does this serve?
3. Q03Why now rather than next quarter or next year?
4. Q04Is this reactive (regulatory, competitive, incident) or proactive?
5. Q05What is the cost of deferring this by one quarter, in money or momentum?
6. Q06Is there a window of opportunity, a launch event, or an external deadline?

Question D from your intake sheet lives here.

Every weak epic starts with a solution hunting for a problem. Start with the problem, and only describe the solution once the problem is defensible.

1. Q01What specific problem does this feature or functionality solve?
2. Q02Whose problem is it, and do they agree it is a problem?
3. Q03Is there quantitative evidence? Tickets, churn, support volume, analytics?
4. Q04Run the 5 Whys. What is the root cause, not the symptom?
5. Q05What does the user do today when they hit this problem, and does it work?
6. Q06Would the problem disappear on its own, given a different workflow or doc?

Question E from your intake sheet lives here.

If you cannot measure the epic, you cannot finish it, you can only stop working on it. Commit to a North Star, a leading indicator, and a counter-metric.

1. Q01What measurable benefits are expected if this feature or functionality is successful?
2. Q02What is the one North Star metric this epic moves?
3. Q03Which leading indicators will we watch week-to-week during rollout?
4. Q04Which lagging indicators define success at 30, 60, and 90 days?
5. Q05What is the counter-metric we must not degrade (latency, churn, CSAT)?
6. Q06What is the decision threshold where we double down, pivot, or kill?

Question F from your intake sheet lives here.

Two audiences read an epic: the board, who wants business value, and the user, who wants their problem solved. Speak to both. If you can only describe one, the epic is half-formed.

1. Q01How will this feature or functionality add value to the business or users?
2. Q02What is the expected revenue, retention, or cost impact?
3. Q03Which board, exec, or customer commitment does this satisfy?
4. Q04What does a user gain in the first session after this ships?
5. Q05Is the value realisation leading or lagging the investment, and by how long?
6. Q06Is the value reversible if we decide to sunset it, or is this a one-way door?

Question G from your intake sheet lives here.

Epics that ignore the market ship into one. Know the alternatives, pick a differentiator, and write it down before the sales team asks.

1. Q01How does this feature or functionality compare to competitor solutions or the current system?
2. Q02What are the two or three closest alternatives, and what do they do well?
3. Q03What is our differentiator, in one sentence a customer would remember?
4. Q04What does the current workaround (spreadsheet, script, rival tool) cost users?
5. Q05Which adjacent categories might we be encroaching on, intentionally or not?
6. Q06If a competitor ships this first, what is our story and what changes?

Question H from your intake sheet lives here.

Gap analysis is the fastest way to turn an epic from abstract into buildable. Describe today, describe the day after launch, and the delta is the work.

1. Q01What is the current (as is) state after implementation?
2. Q02What is the desired (to be) state after implementation?
3. Q03Which workflows, surfaces, or systems change materially?
4. Q04What gets deprecated, removed, or simplified?
5. Q05What does the user see, click, or receive on day one that is different?
6. Q06What transitional behaviour do we need during migration or rollout?

Question I from your intake sheet lives here.

Epics die on invisible dependencies and absent stakeholders. Name them all, name them early, and assign them roles so nobody is surprised in week six.

1. Q01What dependencies or constraints have been identified for this feature or functionality?
2. Q02Who are the stakeholders involved, and what are their roles?
3. Q03Who is the single accountable epic owner? One name, not a committee.
4. Q04Which teams contribute? Who is informed but not involved?
5. Q05Which regulatory, legal, privacy, or accessibility constraints apply?
6. Q06Which upstream migrations, platform readiness, or vendor contracts must land first?
7. Q07Which assumptions carry the most risk if they turn out to be wrong?
8. Q08What is the budget, headcount, or time-box this epic is operating inside?

Questions J and K from your intake sheet live here.

An epic you cannot split is an epic you cannot ship. The slicing is the work, not an afterthought. Define the minimum that unlocks learning, not the minimum that feels safe.

1. Q01What is the thinnest vertical slice we could ship and learn from?
2. Q02What is the MVP (minimum viable product) vs the MLP (minimum lovable product)?
3. Q03Which stories are required for the first release, and which are optional?
4. Q04What is the rollout sequence: internal, beta, percentage, general availability?
5. Q05What do we deliberately not ship in v1, and is that written down?
6. Q06What are the first three stories the team could pull next sprint?
7. Q07What is our definition of done for the epic itself, not just the stories?