Presenting GIST Plans in Stakeholder and Interview Settings
This skill teaches you how to communicate the four-layer GIST hierarchy, from Goals through Tasks, to executives, cross-functional teams, and interviewers so your strategic thinking is visible and persuasive.
Start with the Goal (the measurable business outcome), then present your top 2-3 Ideas ranked by ICE scores, explain the Step-project you would run first as a small experiment, and outline the immediate Tasks. This four-layer narrative demonstrates structured strategic thinking, which is exactly what product manager interview questions about planning are designed to assess. Tailor depth to your audience: executives care about Goals and metrics, cross-functional teams need Step-project details.
Outcome: You can walk any audience through a GIST plan in a way that feels structured, evidence-based, and strategically grounded, whether the audience is a VP of Product, a squad of engineers, or a panel asking product manager interview questions.
Prerequisites
- Understanding of the four GIST layers (Goals, Ideas, Step-projects, Tasks)
- Familiarity with ICE scoring for idea prioritization
- Basic experience writing measurable product goals
- Comfort with narrative presentation structure (situation, complication, resolution)
Overview
Most product managers can fill out a GIST planning framework on a spreadsheet, but far fewer can present that plan in a way that earns trust, secures buy-in, or passes a product manager interview question about strategic thinking. The difference is not the plan itself but how you communicate the logic that connects each layer. A stakeholder who hears "we scored this idea 7-8-6 on ICE" without understanding the Goal it serves will question your judgment. An interviewer who hears a list of features without the experimental reasoning behind them will conclude you are a feature factory manager, not a strategic thinker. This skill closes that gap.
Presenting a GIST plan effectively means translating the GIST Planning Framework into a narrative that matches the audience's altitude. Executives operate at the Goal and Idea layers: they want to know what outcome you are chasing, why it matters to the business now, and which bets you are placing to get there. Cross-functional teams need the Step-project and Task layers: they want to know what they are building this sprint, how the experiment is structured, and what a successful result looks like. Interview panels want the full stack compressed into a 3-5 minute answer that proves you can think from strategy down to execution. In every case, the artifact you produce is a walk-through narrative, not a slide deck, that traces a single thread from one Goal through the Idea, Step-project, and Tasks that bring it to life.
The concrete output of this skill is a prepared GIST presentation narrative. It includes one clearly stated Goal with a metric and time horizon, 2-3 prioritized Ideas with brief ICE rationale, the first Step-project described as an experiment with hypothesis and success criteria, and the immediate Tasks for the next sprint. When done well, this narrative makes product manager interview questions about prioritization, experimentation, and stakeholder alignment feel straightforward because you are answering all three with one coherent story. It also gives executives a repeatable format they can relay upward, which builds trust faster than any slide deck.
How It Works
The reason a GIST presentation works is that it mirrors how strategic decisions actually get made, just in reverse. Decisions flow top-down (company strategy sets Goals), but evidence flows bottom-up (Task execution produces data that validates or kills Ideas). When you present a GIST plan, you are making both flows visible in a single narrative, which is something most planning frameworks fail to do because they separate strategy decks from sprint boards.
The mental model behind an effective GIST presentation is the "zoom lens" metaphor. You start wide (the Goal), zoom in one click (the Ideas), zoom in again (the Step-project), and finish tight (the Tasks). Each zoom level answers one question the audience is silently asking. At the Goal level, the question is "Why does this matter to the business?" At the Idea level, it is "What approaches did you consider and why this one?" At the Step-project level, it is "How will you know if it works before committing fully?" At the Task level, it is "What happens this week?" If you skip a level, the audience fills the gap with their own assumptions, and those assumptions are rarely favorable.
The framework succeeds because it externalizes your reasoning chain. In product manager interview questions about prioritization, interviewers are not looking for the "right" answer. They are looking for a visible decision-making process. GIST gives you that process in four layers, each with its own evidence type: Goals use business metrics, Ideas use ICE scores, Step-projects use experiment hypotheses, and Tasks use acceptance criteria. When you present each layer with its corresponding evidence, you demonstrate structured thinking without needing to memorize a specific framework name. Many candidates who answer product manager interview questions well are implicitly using a hierarchy like GIST. This skill makes it explicit and repeatable.
One important nuance: the zoom lens is not always linear. With executives, you may present Goal, then Ideas, then jump back to Goal to discuss tradeoffs between competing Goals before diving into Step-projects. With engineering teams, you might start at the Step-project level ("here is what we are building"), zoom out briefly to the Idea and Goal ("here is why"), then zoom back in to Tasks. The sequence adapts, but the four layers and their connecting logic stay constant. This adaptability is what makes GIST presentations work across audiences, from boardrooms to interview rooms to sprint planning sessions.
Step-by-Step
Step 1: Identify your audience and their altitude
Before you touch a slide or open a document, write down who will be in the room and what layer of GIST they care about most. Executives and board members operate at the Goal layer. They want to know the measurable outcome, the time horizon, and the business rationale. Cross-functional team leads care about the Step-project layer, specifically what is being built, what the hypothesis is, and what resources are needed.
Interview panels want the full stack but compressed, so they can evaluate your strategic range. Write a single sentence for each audience member describing what they need to walk away believing. This sentence becomes your presentation's success criterion.
Tip: If you are preparing for a product manager interview, treat the panel as a mixed audience: assume one interviewer cares about strategy (Goals), one about execution (Tasks), and one about analytical rigor (ICE scoring on Ideas). Structure your answer to satisfy all three in sequence.
Step 2: Select one Goal as your narrative anchor
Choose a single Goal from your GIST plan to build the presentation around. Do not present all your Goals at once. Pick the one that is most relevant to the audience's current priorities. Write the Goal as a measurable statement: the metric, the target value, and the deadline.
" If you are in an interview and do not have a real Goal, construct one from the case prompt or from a previous role. The Goal must be specific enough that the audience can evaluate whether your Ideas and Step-projects are logically connected to it. Vague Goals like "improve user experience" will undermine everything that follows because any Idea could plausibly connect to a vague Goal, which means your prioritization reasoning becomes invisible.
Tip: For stakeholder meetings, pick the Goal that aligns with the executive's OKR or the initiative they personally sponsor. This creates immediate relevance and makes them an ally during the presentation rather than a skeptic.
Step 3: Prepare your Idea shortlist with ICE rationale
From your Idea bank, select 2-3 Ideas that could serve the Goal you chose. For each Idea, state a one-sentence description, the ICE score (Impact, Confidence, Ease), and a brief rationale for why this Idea scored where it did. Do not present the full Idea bank. Showing 15 Ideas signals that you have not prioritized.
Showing 2-3 signals that you have done the hard work of elimination. For each Idea, prepare one sentence explaining what you considered and rejected, and why. This "rejected alternative" is critical because it proves you explored the solution space rather than latching onto the first thing that came to mind. In interview settings, this is often the difference between a "hire" and "no hire" decision on product manager interview questions about prioritization.
Tip: If an Idea has a low Confidence score, say so explicitly and explain that this is exactly why you are running a Step-project experiment rather than committing to a full build. Low confidence is not a weakness in GIST. It is a reason to experiment.
Step 4: Describe the first Step-project as an experiment
Take the highest-priority Idea and describe the Step-project you would run (or are running) to validate it. Structure the Step-project as an experiment: state the hypothesis ("We believe that [action] will produce [measurable result] for [user segment]"), the method (what you are building or testing), the success criteria (the metric threshold that would confirm the hypothesis), and the timeline (ideally 2-4 weeks). Be specific about what you are not building. A Step-project is scoped small on purpose, and explaining what you excluded demonstrates disciplined scope management.
If you are presenting to engineers, include technical constraints and dependencies.
Tip: Frame the Step-project outcome as a decision, not a deliverable. Executives remember "this experiment will tell us whether to invest $200K in a full build" far better than "we are building a prototype."
Step 5: Outline immediate Tasks to show execution readiness
List 3-5 Tasks that the team will complete in the current or next sprint to begin the Step-project. " This layer is optional for executive audiences but essential for cross-functional teams and surprisingly effective in interviews. When answering product manager interview questions, most candidates stop at the strategy layer. Dropping into specific Tasks signals that you understand what it takes to ship, not just what it takes to plan.
Keep this section brief, just enough to show that the plan connects all the way to daily work.
Tip: In interviews, you do not need real Tasks. Use plausible examples: "The first thing I would do Monday morning is set up the experiment tracking so we have clean data from day one." This grounds your answer in execution reality.
Step 6: Build the connecting narrative between layers
Now connect the four layers into a single narrative thread. The narrative should flow naturally: "Our Goal is X. We considered several approaches and prioritized Idea A because of its ICE score of Y. To validate Idea A before a full commitment, we are running a Step-project that tests [hypothesis].
" Practice this narrative out loud. It should take 3-5 minutes for an interview answer and 10-15 minutes for a stakeholder presentation. The connecting phrases between layers are the most important part. They are where your reasoning is visible.
Weak connectors like "and then we will" suggest a sequence without logic. Strong connectors like "because the confidence score was low, we decided to" show causal reasoning.
Tip: Record yourself delivering the narrative once. Listen for filler words and for moments where you jump between layers without explaining why. Those jumps are exactly where stakeholders and interviewers lose confidence in your reasoning.
Step 7: Prepare for layer-specific questions
Anticipate questions at each layer and prepare concise answers. At the Goal layer, expect: "Why this metric and not another?" "What happens if we miss the target?" "How does this connect to company strategy?" At the Idea layer, expect: "Why not Idea B instead?" "How confident are you in the ICE scores?" "What data informed your Impact estimate?" At the Step-project layer, expect: "What if the experiment is inconclusive?" "Can we shorten the timeline?" "What is the minimum sample size?" At the Task layer, expect: "Who is doing what?" "What are the dependencies?" "What could block us?" Write one-sentence answers for each of these. In interview settings, these questions are often the follow-ups that determine the final rating on product manager interview questions about planning and execution.
Tip: For the question "What if the experiment fails?" always have a ready answer. The best format is: "If the experiment does not hit our success threshold, we will revisit Idea B, which scored second on ICE, and design a new Step-project to test it. The Goal remains the same. Only the approach changes."
Step 8: Tailor the visual format to the setting
Choose the right format for your audience. For executive stakeholder meetings, a single slide with four rows (Goal, Idea, Step-project, Tasks) works well because it fits on one screen and forces brevity. For cross-functional team meetings, a shared document or Notion page with expandable sections lets people drill into the layer they care about. For interviews, use no visuals at all, just the verbal narrative.
If whiteboarding is available in an interview, draw four boxes connected by arrows: Goal at top, Ideas below, one Step-project branching from the chosen Idea, Tasks at the bottom. Label each box. This simple diagram makes your thinking visually traceable and is far more effective than a complex framework diagram.
Tip: In remote interviews, ask if you can share your screen and sketch the four layers in a simple drawing tool. Most interviewers will say yes, and the visual anchors your narrative in their memory far better than words alone.
Examples
Example: Presenting a GIST plan to the VP of Product at a B2B SaaS company
You are a PM at a 200-person B2B SaaS company. Your VP of Product has 30 minutes for your quarterly planning review. She cares about revenue impact and wants to understand your biggest bet for Q3. She has context on the company OKRs but has not seen your specific plan.
" You briefly connect this to the company OKR she owns (net revenue retention above 110%). Then you present two Ideas: a proactive health-score alert system (ICE: 8-6-7) and an enhanced onboarding sequence for mid-market accounts (ICE: 7-4-8). You explain why the health-score alert won: higher impact estimate based on analysis showing that 68% of churned accounts showed declining usage 45 days before cancellation. You note the moderate confidence score and explain that this is why you are running a Step-project first, not a full build.
The Step-project is a 3-week experiment: manually trigger health-score alerts for 50 accounts via email and measure whether CSM outreach within 48 hours reduces cancellation requests by 20% or more. Tasks for this week include segmenting the 50 accounts, writing the alert email templates, and briefing the CSM team. You close with the decision framing: "If the manual experiment hits 20% reduction, we will spec the automated system for Q3 build. " The VP asks about the 4-point confidence score.
You explain the qualitative signals and the absence of quantitative validation, which reinforces why the experiment is necessary. She approves the plan in 18 minutes.
Example: Answering a product manager interview question about strategic planning
You are in a final-round PM interview at a consumer fintech startup. The interviewer asks: "Tell me about a time you had to prioritize between competing product initiatives. How did you decide what to work on?" This is one of the most common product manager interview questions, and you have 5 minutes to answer.
You structure your answer using the GIST hierarchy without naming it initially. " Then you introduce the Ideas: "We brainstormed about a dozen approaches and scored each on expected impact, our confidence in that estimate, and ease of execution. " You move to the Step-project: "We decided to run a two-week experiment. We split new signups into three cohorts, each receiving one of the three approaches, with a control group.
" You share the result: "The simplified payment flow produced an 11-point lift. The onboarding tutorial produced 3 points. " You close with the decision: "Based on this, we committed engineering resources to the simplified payment flow and killed the incentive approach. " If the interviewer asks what framework you used, you name GIST and briefly explain the four layers.
The interviewer rates you highly on structured thinking, data-driven prioritization, and intellectual honesty about the missed target.
Example: Presenting a GIST plan to a cross-functional engineering and design team
You are a PM at a 40-person startup. Your squad of 4 engineers, 1 designer, and 1 data analyst meets weekly for sprint planning. You need to explain a new Step-project that starts next sprint and connect it to the broader strategy so the team understands why they are building what they are building.
" You then zoom out briefly to the Idea: "This is one of three approaches we are considering to improve activation. " Then you zoom back in to Tasks: "Here is how the sprint breaks down. [Engineer A], you are building the progress bar component and the event tracking. [Engineer B], you are setting up the A/B test infrastructure.
[Designer], you are finalizing the progress bar states by Wednesday so engineering can start Thursday. " You define the success criterion: "If the test cohort shows a 5-point lift in onboarding completion with statistical significance, we ship it to 100% of users. " The designer asks whether the progress bar should include step labels. You connect the answer to the hypothesis: "Yes, because the hypothesis is that users abandon because they do not know how many steps remain.
" The team leaves with clear Tasks and clear understanding of why those Tasks matter.
Example: Presenting a GIST plan at a board meeting for a Series B startup
You are VP of Product at a Series B startup with $15M ARR. The board meets quarterly and wants a 10-minute product update. Board members include two VCs, the CEO, and an independent director with an operating background. They have limited context on day-to-day product decisions and care about strategic direction and capital allocation.
You present two Goals, each on a single slide with four rows. " You present the leading Idea: an enterprise admin console with role-based access control, scored highest on ICE because 7 of your 10 largest pipeline deals cited it as a blocker. You describe the Step-project: a 4-week concierge MVP where your team manually configures access controls for 3 pilot enterprise accounts and measures whether it unblocks their procurement process. Tasks are already underway.
" Goal 2 follows the same structure in 3 minutes. You close with the resource ask: "To run both Step-projects simultaneously, I need to delay the mobile app refresh by one sprint. " The independent director asks about the ICE confidence score for Goal 1. You explain that the 7-out-of-10 pipeline data gives you a confidence of 8, which is unusually high and makes this a strong candidate for aggressive investment.
The board approves without requesting additional analysis because the reasoning is transparent and the decision framework is clear.
Best Practices
Start every GIST presentation with the Goal, not the Idea. Audiences anchor on the first thing they hear. If you start with an Idea (a feature or solution), the entire conversation becomes about whether that Idea is correct. If you start with a Goal (a business outcome), the conversation becomes about whether the outcome matters and how to achieve it.
The second conversation is far more productive and positions you as a strategic thinker rather than a feature advocate.
Use exact numbers at every layer. "Increase activation" is a direction, not a Goal. "Increase 30-day activation from 22% to 35%" is a Goal. "We think this will help" is a guess, not an ICE score.
"Impact 8, Confidence 5, Ease 7" is a score. Specificity creates accountability, which executives and interviewers interpret as confidence and rigor. Vague language signals that you have not done the analytical work.
Show the rejected alternatives at the Idea layer. Presenting only your chosen Idea makes it look like you had only one option. Presenting 2-3 alternatives you considered and explaining why you deprioritized them demonstrates thorough exploration of the solution space. This is especially critical for product manager interview questions about prioritization, where the reasoning process matters more than the final answer.
Keep the Step-project description under 90 seconds in verbal delivery. Step-projects are the layer where presenters lose their audience because they over-explain the experiment mechanics. State the hypothesis, the method, the success criteria, and the timeline. Stop. If the audience wants more detail, they will ask. If they do not ask, you saved time and maintained momentum.
Match your language to the audience's vocabulary. With executives, use business language: revenue, retention, market share, competitive advantage. With engineers, use technical language: architecture, latency, data pipeline, edge cases. With interviewers, mirror the language of the job description and the questions they ask.
Language mismatch creates a subtle but powerful impression that you do not understand the audience's world.
Always end with the decision the plan enables, not the plan itself. The last thing your audience should hear is not a Task or a timeline but a decision: "If this experiment succeeds, we commit to a full build in Q3. If it does not, we pivot to Idea B with a new experiment. Either way, we will have data-driven clarity in four weeks." This frames the plan as a decision-making tool, which is what executives and interviewers value most.
Rehearse transitions between layers more than the layers themselves. Most people practice the content of each layer but stumble on the logic that connects them. The transition from Goal to Idea should explain why these Ideas were chosen. The transition from Idea to Step-project should explain why you are experimenting rather than committing.
The transition from Step-project to Tasks should explain how the work starts immediately. These transitions carry your strategic reasoning.
Common Mistakes
Presenting all Goals and all Ideas at once instead of threading one narrative
Correction
This happens because presenters want to show the completeness of their planning. The result is a data dump, not a story. The audience cannot follow the logic because there is no single thread to follow. Pick one Goal, select the 2-3 Ideas most relevant to that Goal, and trace one Step-project down to Tasks.
If stakeholders ask about other Goals, you can address them as follow-up threads. In interviews, a single well-threaded narrative scores higher than a comprehensive but unfocused overview every time.
Skipping the Step-project layer and jumping from Idea to Tasks
Correction
This is the most common mistake in both stakeholder meetings and interviews. It happens because presenters assume the Idea is obviously correct and jump to execution. Without the Step-project layer, you lose the experimental reasoning that makes GIST valuable. " Watch for this by checking your narrative: if there is no hypothesis, no success criteria, and no mention of what happens if the experiment fails, you have skipped the Step-project layer.
Add it back by framing the first piece of work as a time-boxed experiment with a clear pass/fail threshold.
Presenting ICE scores without explaining the reasoning behind them
Correction
Saying "this Idea scored 8-5-7" means nothing to an audience that did not participate in the scoring session. It happens because presenters treat ICE scores as objective facts rather than judgment calls. The fix is to briefly narrate the key score: "We rated Confidence at 5 because we have qualitative signal from 12 user interviews but no quantitative data yet. " This transforms the score from a number into a reasoning artifact.
In product manager interview questions, explaining your confidence calibration is often more impressive than the score itself.
Using GIST jargon without defining it for the audience
Correction
Saying "we ranked Ideas by ICE and scoped a Step-project" in a stakeholder meeting or interview without context makes you sound like you memorized a framework rather than internalized a way of thinking. Many executives have never heard of GIST or ICE. Watch for blank looks or clarifying questions about terminology. Instead of leading with framework names, lead with the concepts: "We scored each approach on its expected impact, our confidence in that estimate, and how easy it is to test.
" If the audience asks what framework you are using, then you can name it. In interviews, name the framework only if asked or if the interviewer uses framework-specific language first.
Treating the GIST presentation as a status update rather than a decision-making tool
Correction
This happens when presenters recite what the team has been doing rather than framing what the team needs to decide. " A decision-oriented presentation says "the prototype results suggest X, which means we should either commit resources to a full build or pivot to Idea B. " The signal to watch for is whether your presentation ends with a clear ask or recommendation. " you are giving a status update.
If it ends with "I recommend we proceed with X because of Y, and I need Z to make it happen," you are using GIST as a decision tool.
Over-preparing slides and under-preparing the verbal narrative
Correction
Presenters spend hours perfecting slide formatting and almost no time rehearsing the spoken narrative. In stakeholder settings, the conversation will deviate from slides within minutes. In interviews, you rarely have slides at all. The verbal narrative, specifically the transitions between GIST layers, is what carries your reasoning.
Spend 70% of your preparation time practicing the spoken walk-through and 30% on visual aids. If you can deliver the full Goal-to-Tasks narrative clearly in 5 minutes without any visual support, you are prepared for any format.
Other Skills in This Method
Designing Step-Projects to Validate Product Ideas
How to break ideas into small, time-boxed experiments (step-projects) of no more than 10 weeks that test assumptions and build evidence iteratively.
Defining Measurable Product Goals in GIST
How to set strategic, outcome-based goals using metrics and timeframes that align the entire GIST hierarchy and replace vague roadmap themes.
Breaking Step-Projects into Actionable Daily Tasks
How to decompose validated step-projects into granular, developer-ready tasks using agile tools like Kanban boards or sprint backlogs.
Replacing Traditional Product Roadmaps with GIST Planning
How to transition a product team from feature-based roadmaps to the GIST framework while maintaining stakeholder alignment and executive buy-in.
Prioritizing Product Ideas Using ICE Confidence Scoring
How to evaluate and rank competing product ideas by scoring them on Impact, Confidence, and Ease to decide which hypotheses to test first.
Managing Different Planning Cadences Across GIST Layers
How to operate goals on quarterly/annual cycles, ideas continuously, step-projects in short sprints, and tasks daily to maintain agile responsiveness.
Building and Managing an Idea Bank for Product Development
How to continuously collect, document, and organize hypothetical solution ideas that map to strategic goals using an always-open idea bank.
Frequently Asked Questions
How do I present a GIST plan when answering product manager interview questions if I have never used GIST formally?
You do not need to have used GIST by name. Most experienced PMs already think in layers of goals, solutions, experiments, and tasks. Structure your interview answer using those four layers naturally: state the business outcome you were chasing, describe the approaches you considered and how you chose between them, explain the first small experiment you ran to validate your choice, and mention the immediate actions you took. If the interviewer asks what framework you use, you can name GIST and explain the four layers. The structure matters more than the label.
How long should a GIST presentation take for different audiences?
For executive stakeholders, aim for 10-15 minutes of presentation with 15-20 minutes of discussion. For cross-functional team meetings, 5-10 minutes of context-setting followed by detailed Task discussion. For product manager interview questions, 3-5 minutes for your initial answer and 2-3 minutes for follow-up questions. The most common mistake is going too long. Brevity signals confidence. If your GIST narrative takes more than 5 minutes to deliver verbally end-to-end, you are including too much detail at one or more layers.
Should I present the GIST plan before or after I have experiment results?
Present the plan before results when you need alignment or resources to run the experiment. Present after results when you need a decision on whether to commit to a full build. Both are valid and common. Before-results presentations focus on the Goal, the Idea rationale, and the Step-project design. After-results presentations focus on what the experiment revealed, how it changes your confidence in the Idea, and what decision you recommend. Many PMs present twice: once to get approval to run the experiment, once to share results and recommend next steps.
How do I handle pushback when a stakeholder disagrees with my ICE scoring?
Treat the disagreement as useful new information, not a challenge to defend against. Ask which score they disagree with (Impact, Confidence, or Ease) and what evidence informs their view. Often, a stakeholder has context you lacked, such as a market signal that changes your Impact estimate or a technical constraint that changes Ease. Adjust the score in real time if their reasoning is sound. This demonstrates intellectual flexibility, which builds trust faster than winning an argument. If you disagree with their input, explain your evidence and propose running a Step-project specifically to resolve the uncertainty.
Why does my GIST presentation keep turning into a feature debate?
This happens when you start with the Idea (the feature or solution) instead of the Goal (the business outcome). When the audience hears a feature first, they evaluate it based on their personal preferences and assumptions. When they hear a Goal first, they evaluate Ideas based on whether they serve the Goal. Restructure your narrative to spend the first 60-90 seconds on the Goal and its metric before mentioning any Idea. Also check whether your Goal is specific enough. Vague Goals like "improve the user experience" invite feature debates because any feature could plausibly serve a vague Goal.
How do I present GIST plans when my company does not use GIST and stakeholders expect a traditional roadmap?
You do not need to convert the organization to GIST. Present using GIST structure but with familiar language. " The structure is the same, but the vocabulary matches what your stakeholders expect. Over time, as they see the clarity this structure provides, you can introduce the GIST terminology if it adds value. The framework's power is in the hierarchy and the experimental reasoning, not in the specific labels.
How do I handle product manager interview questions that ask about roadmaps when I want to present using GIST?
Acknowledge the question directly, then pivot: "In my experience, traditional roadmaps with fixed feature timelines create false precision. I prefer a goal-oriented approach where we define measurable outcomes, generate multiple solution options, and validate the best ones through small experiments before committing to a full build. " Then deliver your GIST narrative. This reframes the question without ignoring it and positions you as someone who thinks critically about planning methodology. Most interviewers respond positively because the question is really about your planning rigor, not about whether you can draw a Gantt chart. For more on this approach, see [Replacing Traditional Roadmaps with GIST](/skills/replacing-traditional-roadmaps-with-gist).