Run a Monthly Client Web App Release

Plan a client web app release with evidence, budget control, and bug triage.

Introduction

30 Second Summary

A long-running client often brings several urgent demands into the same meeting. The hardest part is choosing what moves now while keeping the client confident in the decision.

In this project, you will take over the fictional CivicPath portal and run one monthly release from an uncertain backlog to a defensible client decision. You will build the case in Google Sheets and present it through Google Docs.

What You'll Build

You will open your finished CivicPath case and lead a client-ready walkthrough from ranked evidence to a revised 116-hour release decision.

By the end of this project, you'll have:

A ranked backlog that makes autosave draft recovery the evidence-backed choice. You can show why the dashboard redesign waits.
A roadmap-to-ticket chain from the quarterly objective through the feature specification. It finishes with acceptance criteria plus provided estimates.
A client-ready release plan that absorbs a late upload bug while staying at 116 of 120 hours. Your two-minute update makes the resulting tradeoff easy to explain.
Secret Mission: Hold your evidence-backed recommendation when the executive sponsor insists that the dashboard redesign must ship first.

Are there any prerequisites?

You will get the most value from this case if you have 5+ years of agency product or project management experience. You also need a Google Account with access to Google Docs and Google Sheets.

Before We Start

This opening checkpoint locks in the fictional CivicPath monthly release you are about to manage. It also helps you choose the senior product-management skill you want an interviewer to remember.

Set Up the Release Case Workspace

A strong client case needs one decision source. It also needs a client narrative that stays tied to the evidence.

Google Sheets holds the release evidence plus the operational plan. Google Docs carries the recommendation you present to the client.

In this step, get ready to:

Create the release decision workbook structure in Google Sheets.
Create the client release brief structure in Google Docs.
Add the quarterly objective as the case guardrail.

Create the decision workbook

The workbook becomes your decision source for the rest of the case. Each sheet gives one type of release input a clear home.

Enter https://sheets.google.com/create in your browser's address bar.
Complete Google's sign-in flow with your existing Google Account if your browser asks.

You'll see a new blank spreadsheet. This confirms that your Google Sheets access is working.

Click the file name at the top of the spreadsheet.
Replace the current name with CivicPath Release Decision.
Press Enter.

The workbook title now reads CivicPath Release Decision.

Double-click the first sheet tab at the bottom of the workbook.
Type Evidence.
Press Enter.

The first sheet tab now reads Evidence.

Select the add-sheet control at the bottom of the workbook to create a second sheet.

You'll see a second blank sheet tab at the bottom of the workbook.

Double-click the second sheet tab.
Type Release Plan.
Press Enter.

The second sheet tab now reads Release Plan.

Select the add-sheet control at the bottom of the workbook to create a third sheet.

You'll see a third blank sheet tab at the bottom of the workbook.

Double-click the third sheet tab.
Type Budget & Bugs.
Press Enter.

Your workbook now has three named sheets. The sheets contain no case data yet.

Create the client brief

The brief turns your evidence into a client-facing decision story. Its four sections create space for the recommendation, scope, meeting update, plus interview reflection.

Open a new browser tab.
Enter https://docs.google.com/create in the address bar.

You'll see a new blank document in the same signed-in Google Account.

Click the document name at the top of the page.
Replace the current name with CivicPath Client Release Brief.
Press Enter.

The document title now reads CivicPath Client Release Brief.

Type Decision on the first line.
Type Feature Spec on a new line.
Type Client Update on a new line.
Type Interview Debrief on a new line.

The brief now has four named sections ready for the decisions you make later.

Your Changes Save Automatically

Google saves online changes as you type. You do not need to find a save button.

Add the objective and verify the workspace

The objective is the guardrail for every later tradeoff. It connects the user problem to the fixed release budget.

Place your cursor before the first character in Decision.
Paste Reduce incomplete applications and related support demand this quarter without exceeding 120 hours in the monthly release..
Press Enter twice.

The objective now sits at the top of the brief. The Decision section begins below it.

Before you check, consider whether you can recall all three sheet names plus all four brief sections.

Switch back to the Google Sheets browser tab.
Confirm the workbook title shows CivicPath Release Decision.
Confirm the sheet tabs show Evidence, Release Plan, plus Budget & Bugs.
Confirm the workbook contains no case data.
Switch back to the Google Docs browser tab.
Confirm the document title shows CivicPath Client Release Brief.
Confirm the objective appears above the four named sections.

You should see Decision, Feature Spec, Client Update, plus Interview Debrief in the brief.

Missing a Sheet or Section?

Compare the workbook title plus each sheet name with the labels above.
Compare the document title plus each section name with the labels above.
Check for extra spaces if a label looks different.
Ask for help checking the workspace structure.

Your case backbone is ready with one evidence workspace plus one client narrative. Next, you'll add the fictional backlog and test the client-preferred release choice.

Expose the Priority Gap

Your CivicPath workspace now keeps the quarterly objective in a Google Docs brief. The matching Google Sheets workbook is ready to hold the decision evidence.

Client pressure can make Dashboard redesign feel urgent before its expected benefit is tested. In this step, you will preserve that first reaction before testing it against the fictional user evidence.

In this step, get ready to:

Load the five fictional candidates into the Evidence sheet.
Capture Dashboard redesign as your first-pass release choice.
Name the unsupported assumption behind that choice.

Add the fictional backlog

This backlog gives five competing investments the same structure. Every score plus metric belongs to this fictional practice case.

Switch back to the CivicPath Release Decision workbook from earlier.
Select the Evidence sheet.
Click cell A1.
Populate the eight columns plus five candidate rows by pasting this tab-separated case packet:

Candidate	Client priority (1-5)	Reach (1-5)	User impact (1-5)	Evidence confidence (1-5)	Estimated effort hours	Decision score	Evidence note
Dashboard redesign	5	5	2	2	40		Executive sponsor request; 6 related tickets; 78% of active users visit the dashboard
Autosave draft recovery	3	5	5	5	28		620 incomplete applications and 84 related support tickets last month
Mobile upload reliability	4	4	4	5	20		310 failed upload sessions and 47 related support tickets last month
Accessible error summaries	2	3	5	4	16		180 repeated validation failures and 21 related support tickets last month
CSV export	3	2	3	3	12		80 export attempts and 12 related support tickets last month

What Does This Case Packet Capture?

Columns B through F hold the decision inputs for each candidate.
Column G remains blank so the first-pass choice stays unscored.
Column H preserves the fictional evidence behind each candidate.
Rows 2 through 6 hold one candidate per row.

Confirm that all eight headers occupy separate columns.
Confirm that five candidate rows appear beneath the headers.
Confirm that cells G2:G6 remain blank.

Good. Your workbook now holds the complete case packet while preserving the unscored decision moment.

Did Everything Land in One Column?

Undo the paste if every value landed in column A.
Select cell A1 again.
Paste the tab-separated case packet again.
Help me split the case packet into eight columns.

Commit to the first-pass choice

Before you commit, do client priority plus broad reach make Dashboard redesign feel like the strongest first-pass choice? Keep your prediction in mind.

Select cells A2:H2 in the Evidence sheet.
Choose a pale background color from the spreadsheet toolbar.

The highlighted row now preserves the choice that feels most obvious under client pressure.

Switch back to the CivicPath Client Release Brief document from earlier.
Place your cursor beneath the Decision heading.
Add the three-line first-pass hypothesis by pasting this block:

Requested change: Dashboard redesign.
Expected benefit: Improve the experience for the 78% of active users who visit the dashboard.
Why it appears urgent: The executive sponsor requested it. Six related tickets reinforce the pressure.

What Does This Hypothesis Capture?

The requested change makes the first-pass choice explicit.
The expected benefit turns dashboard traffic into a plausible release outcome.
The urgency line captures the client pressure behind the choice.

Read the three-line hypothesis aloud.
Confirm that the first line names the requested change.
Confirm that the second line states the expected benefit.
Confirm that the third line explains the apparent urgency.

You now have a credible first-pass story for Dashboard redesign. The next comparison tests whether that story supports the quarterly objective.

Is the First-Pass Choice Hard to See?

Check that only cells A2:H2 carry the background color.
Keep cells G2:G6 blank for the later scoring step.
Help me preserve the first-pass Dashboard redesign choice.

Compare the hypothesis with the evidence

Before you compare the rows, do you expect Dashboard redesign to have the strongest evidence for reducing incomplete applications or support demand? Keep your prediction in mind.

Switch back to the Evidence sheet from earlier.
Read the Dashboard redesign evidence note.
Compare it with the Autosave draft recovery evidence note.
Compare it with the Mobile upload reliability evidence note.

Autosave draft recovery connects directly to 620 incomplete applications. It also connects to 84 related support tickets.

Mobile upload reliability connects directly to 310 failed sessions. It also connects to 47 related support tickets.

Dashboard redesign shows broad traffic plus executive urgency. It does not connect dashboard activity to fewer incomplete applications or lower support demand.

Why Does the Gap Matter?

Evidence-led prioritization keeps the decision tied to signals that support the stated objective. This makes disagreement about the choice easier to explain without making it personal.

Return to the Decision section in the client brief.
Place your cursor beneath the three-line hypothesis.
Add the priority gap by pasting this line:

Priority gap: Executive demand and dashboard visits do not establish that a redesign will reduce incomplete applications or support demand.

What Does the Priority Gap Do?

The statement separates urgency from outcome evidence. It gives the next scoring step a clear problem to solve.

Before you check both artifacts, do you expect the highlighted first-pass choice to survive the objective test? Keep your prediction in mind.

Switch back to the Evidence sheet.
Confirm that cells A2:H2 remain highlighted.
Confirm that cells G2:G6 remain blank.
Point to the Autosave draft recovery evidence row.
Point to the Mobile upload reliability evidence row.
Return to the Decision section.
Read the Priority gap statement aloud.

You should be able to show that executive urgency plus dashboard traffic do not prove a redesign will reduce incomplete applications or support demand.

✔️ My priority gap is exposed

Your workbook shows Dashboard redesign as the highlighted first-pass choice. Your brief now explains why that choice does not support the quarterly objective yet.

ⓧ I'd like to double check the case

Your Evidence sheet should match this tab-separated reference. The Dashboard redesign row should also be highlighted.

Candidate	Client priority (1-5)	Reach (1-5)	User impact (1-5)	Evidence confidence (1-5)	Estimated effort hours	Decision score	Evidence note
Dashboard redesign	5	5	2	2	40		Executive sponsor request; 6 related tickets; 78% of active users visit the dashboard
Autosave draft recovery	3	5	5	5	28		620 incomplete applications and 84 related support tickets last month
Mobile upload reliability	4	4	4	5	20		310 failed upload sessions and 47 related support tickets last month
Accessible error summaries	2	3	5	4	16		180 repeated validation failures and 21 related support tickets last month
CSV export	3	2	3	3	12		80 export attempts and 12 related support tickets last month

Your CivicPath Client Release Brief should contain this cumulative structure:

Reduce incomplete applications and related support demand this quarter without exceeding 120 hours in the monthly release.

Decision
Requested change: Dashboard redesign.
Expected benefit: Improve the experience for the 78% of active users who visit the dashboard.
Why it appears urgent: The executive sponsor requested it. Six related tickets reinforce the pressure.
Priority gap: Executive demand and dashboard visits do not establish that a redesign will reduce incomplete applications or support demand.

Feature Spec

Client Update

Interview Debrief

That is the key shift complete. Next, you will turn the exposed assumption into a defensible roadmap decision.

Make the Evidence-Backed Roadmap Decision

Your first-pass Dashboard redesign hypothesis has done its job. It exposed a specific gap between executive urgency and the quarterly outcome.

Now you need a decision the client can inspect without feeling dismissed. A transparent evidence-led prioritization model turns the backlog into a defensible roadmap sequence.

In this step, get ready to:

Calculate a custom score for every backlog candidate.
Turn the highest score into a roadmap recommendation.
Scope Autosave draft recovery from the problem through the ticket estimates.

Calculate the decision scores

The Evidence sheet in Google Sheets holds the reach, impact, confidence, and effort inputs for each candidate. The custom score makes the tradeoff visible across the full backlog.

Switch back to the CivicPath Release Decision workbook from earlier.
Select the Evidence sheet tab at the bottom of the workbook.
Select cell G2 in the Decision score column.
Enter =C2*D2*E2/F2 in the cell.
Confirm the formula with Enter.

Before you calculate the remaining rows, consider which candidate you expect to lead once estimated effort is included.

Select cell G2 again.
Drag the small blue square at the lower-right corner of the cell down to G6.

What should you see?

Dashboard redesign should show 0.5.
Autosave draft recovery should show approximately 4.46.
Mobile upload reliability should show 4.
Accessible error summaries should show 3.75.
CSV export should show 1.5.

This custom case score multiplies reach, user impact, and evidence confidence. It divides that result by the supplied effort estimate.

The model supports this decision exercise. It is not a universal prioritization framework.

That priority gap is now resolved with visible evidence. Autosave draft recovery leads despite Dashboard redesign remaining highlighted as the first-pass choice.

Scores not filling correctly?

Confirm that the formula in G2 starts with an equals sign.
Check that the formula references C2, D2, E2, and F2.
Check that the cells from C2 through F6 contain numbers.
Help me check my decision score formulas.

Record the roadmap decision

A roadmap decision connects the quarterly objective to a release order. This chain keeps the recommendation focused on outcomes instead of stakeholder preference.

Switch back to the CivicPath Client Release Brief in Google Docs.
Place your cursor below the existing Priority gap statement in the Decision section.
Add the evidence-backed decision by pasting this block:

Quarterly objective: Reduce incomplete applications and related support demand.
Release recommendation: Ship Autosave draft recovery before Dashboard redesign.
Evidence summary: Autosave has the highest score because it combines broad reach, severe user impact, strong evidence, and a manageable estimate.
Roadmap sequence: Autosave draft recovery now.
Mobile upload reliability next.
Dashboard discovery later.

How does this decision chain work?

The quarterly objective anchors the choice to a measurable client outcome.
The release recommendation names the current priority.
The evidence summary makes the disagreement impersonal.
The roadmap sequence protects space for later dashboard discovery.

Wait for Google Docs to finish saving the online changes.
Read the new decision block from the quarterly objective through the roadmap sequence.

You should see one continuous path from reducing incomplete applications to shipping Autosave draft recovery first.

Does the recommendation feel disconnected?

Check that the decision block sits directly below the existing priority gap.
Confirm that the evidence summary names the four score inputs.
Confirm that the roadmap sequence gives Dashboard discovery a later place.
Help me strengthen my roadmap decision chain.

Scope Autosave draft recovery

A feature specification turns the roadmap choice into boundaries the team can estimate and test. The supplied ticket estimates remain inputs from the fictional technical lead.

Move to the Feature Spec section in the client brief.
Place your cursor on the blank line below the section heading.
Build the compact specification by pasting this block:

Problem: Applicants lose progress during long forms, contributing to 620 incomplete applications and 84 related support tickets in the fictional case month.

Outcome: More applicants can resume and submit without support help.

In scope:
- Preserve the latest draft.
- Show Saving, Saved, or Offline status.
- Recover the latest saved draft.
- Offer a manual prior-version restore.

Acceptance criteria:
- A refresh retains the latest saved values.
- A connection loss leaves typed values visible and shows Offline.
- Reconnection saves pending changes and shows Saved.

Tickets:
- UX and status design, 8 hours.
- Autosave core development, 28 hours.
- Prior-version restore, 12 hours.
- Feature QA, 12 hours.

Out of scope:
- Dashboard redesign.
- Mobile upload remediation.
- Notification emails.

What does this specification protect?

The problem ties the feature to incomplete applications and support demand.
The outcome defines the change applicants should experience.
The scope creates a boundary around the release commitment.
The acceptance criteria make the expected behavior testable.
The tickets preserve the technical lead's estimates.
The exclusions prevent adjacent requests from silently entering the release.

Wait for Google Docs to finish saving the online changes.
Compare the ticket estimates with the supplied fictional case packet.

You should see a complete feature specification covering the problem, outcome, scope, acceptance criteria, tickets, and exclusions.

Missing a specification boundary?

Confirm that manual prior-version restore appears under In scope.
Confirm that all three status values appear in the specification.
Confirm that Dashboard redesign appears under Out of scope.
Help me check my Autosave feature specification.

Before you check the completed chain, decide in your head whether the first-pass highlight or the calculated evidence now carries more decision weight.

Switch back to the Evidence sheet.
Confirm that Autosave draft recovery has the highest score.
Confirm that Dashboard redesign remains highlighted as the first-pass choice.
Return to the CivicPath Client Release Brief.
Read the complete chain from the quarterly objective to the three acceptance criteria.

You should see Autosave draft recovery leading at approximately 4.46. Dashboard redesign should remain highlighted at 0.5.

Your brief should carry the quarterly objective through the recommendation, roadmap sequence, and testable feature scope.

You have the hardest part locked down: your roadmap now connects evidence to a scoped release feature. Next, you will test that plan against a late production bug and a fixed budget.

Rescue the Release from the Late Bug

Your evidence now supports Autosave draft recovery as the strongest roadmap choice. The next test is whether that choice can survive real release pressure.

A production upload failure discovered after the code freeze makes the original monthly plan unsafe. You need to expose the shortfall before choosing scope that protects users within the fixed 120-hour budget.

In this step, get ready to:

Build a baseline monthly budget showing 104 planned hours.
Triage the post-freeze Safari upload failure as a release blocker.
Publish a four-week release plan within the fixed 120-hour budget.

Build the baseline budget

A baseline separates the original commitment from the decisions triggered by the bug. The planned column in Google Sheets establishes that starting point.

Switch back to the CivicPath Release Decision workbook from earlier.
Select the Budget & Bugs sheet tab.
Select cell A1.
Paste the baseline table into the selected cell by copying the block below:

Workstream	Planned hours
Discovery and specification	6
UX and status design	8
Autosave core development	28
Prior-version restore	12
Feature QA	12
Release management	6
Maintenance	20
Support reserve	12
Safari upload bug	0
Total	=SUM(B2:B10)

How Does the Baseline Work?

Rows 2 to 10 separate feature work from release operations and support capacity.
The =SUM(B2:B10) formula adds the original planned hours without including the total row itself.
The Safari upload bug starts at 0 because the original plan did not include it.

Before you check the total, predict whether the original plan stays below the 120-hour limit.

Select cell B11 to check the calculated total.

You should see 104. Good, your original release now has a visible budget baseline.

Total Not Showing 104?

Confirm that you started the paste in cell A1.
Check that the formula in B11 is exactly =SUM(B2:B10).
Make sure each hour from rows 2 to 10 appears as a number in column B.
Help me find why my planned-hours total is not 104.

Triage the post-freeze bug

QA now reports that 14% of Safari attachment uploads fail when a signed-in session is more than 30 minutes old. The technical lead estimates 24 hours for a patch and regression test.

Before you add the estimate, predict whether the full original scope plus the blocker still fits within 120 hours.

Select cell C1 in Budget & Bugs.
Paste the first revised-hours column into the selected cell by copying the block below:

Revised hours
6
8
28
12
12
6
20
12
24
=SUM(C2:C10)

What Does This First Revision Test?

Cells C2:C9 preserve every item from the original release scope.
Cell C10 adds the technical lead's 24-hour estimate for the blocker.
The =SUM(C2:C10) formula tests the naive response of adding the urgent work without changing scope.

Select cell C11 to inspect the first revised total.

You should see 128. This is the intended shortfall because the unchanged release now exceeds the budget by 8 hours.

Total Not Showing 128?

Confirm that C5 still contains 12 for prior-version restore.
Confirm that C10 contains 24 for the Safari upload bug.
Check that C11 contains =SUM(C2:C10).
Help me find why my unchanged-scope total is not 128.

A bug triage record captures why this defect takes priority over planned scope. It also preserves the evidence behind the release decision.

Select cell E1 in Budget & Bugs.
Paste the blocker record into the selected cell by copying the block below:

Field	Record
Timing	After the original code freeze.
Failure	14% of Safari attachment uploads fail for signed-in sessions older than 30 minutes.
Estimate	24 hours for a patch and regression test.
Triage	Release blocker.
Reason	Prevents a core submission task, reopens frozen code, and requires broader regression testing.

Why Does This Count as a Blocker?

The failure prevents applicants from completing a core submission task.
The patch reopens code after the original freeze.
The change requires broader regression testing before the monthly release.

Confirm that all five blocker fields appear beneath the header in columns E and F.

Blocker Record Pasted Into One Column?

Undo the paste if every value appears in column E.
Select only cell E1 before pasting the tab-separated block again.
Help me separate my blocker record into two columns.

Protect the release outcome

The 128-hour version breaks the fixed budget. Deferring manual prior-version restore protects core autosave while creating room for the release blocker.

Select cell C5 in the Prior-version restore row.
Replace 12 with 0.
Select cell C11 to check the revised total.

You should now see 116. That brings the release back within budget while preserving the core autosave outcome.

The budget decision now needs a delivery sequence. The new freeze must happen before regression and release testing.

Select the Release Plan sheet tab.
Select cell A1.
Paste the revised release plan into the selected cell by copying the block below:

Period	Plan
Week 1	Discovery, specification, and UX status design.
Week 2	Autosave core development.
Week 3	Complete the core feature, remove prior-version restore, patch the Safari upload bug, and set a new code freeze.
Week 4	Feature QA, upload regression, client release testing, release decision, and monthly release.
Decision note	Removing the 12-hour prior-version restore absorbs the 24-hour blocker while preserving autosave's core outcome and keeping the revised plan at 116 of 120 hours.

How Does the Revised Plan Control Risk?

Week 3 completes core autosave before the team patches the blocker and establishes a new code freeze.
Week 4 places feature QA, upload regression, client release testing, and the release decision after the new freeze.
The decision note connects the deferred scope to the blocker estimate and the fixed budget.

Before the final check, predict which figures and release controls prove that the plan is safe again.

Return to the Budget & Bugs sheet tab.

Cell B11 should show 104. Cell C11 should show 116.

Return to the Release Plan sheet tab.

Week 3 should include the new code freeze. Week 4 should include feature QA, upload regression, client release testing, the release decision, and the monthly release.

Revised Plan Missing a Release Control?

Check that Week 3 ends with a new code freeze after the Safari upload patch.
Check that Week 4 includes upload regression after the new freeze.
Confirm that the decision note states 116 of 120 hours.
Help me check my revised CivicPath release plan.

Your release now absorbs a late blocker without hiding its scope or budget impact. Next, you will turn this decision into a clear client update.

Lead the Client Conversation

Your revised Google Sheets plan protects core autosave while absorbing the late Safari blocker within 116 hours. Your next goal is to turn that decision into a client conversation you can lead with confidence.

The release is only truly managed when the client understands the recommendation, technical risk, budget effect, and decision required from them. Your Google Docs brief brings those points together in plain language.

In this step, get ready to:

Write a five-part weekly update that explains the recommendation, evidence, tradeoff, budget position, and client ask.
Build a 15-minute client agenda that leads the conversation toward a clear decision.
Write and rehearse a four-part interview story about the release decision.

Write the weekly client update

A client-ready update connects the product recommendation to the evidence behind it. It also makes the consequence of the late bug clear without burying the decision in technical detail.

Return to the browser tab containing your CivicPath Client Release Brief.
Add a Recommendation entry under Client Update that continues core autosave while moving prior-version restore to a later release.
Add an Evidence entry that cites 620 incomplete applications, 84 related support tickets, and the ranked backlog.
Add a Tradeoff entry explaining that reopening code after freeze can affect work already tested. State that the team needs another regression pass.
Add a Budget entry stating that the revised plan uses 116 of 120 hours. Include the 4-hour buffer. Confirm that the release avoids an overage.
Add an Ask entry requesting confirmation of the scope change plus revised code freeze.

Your five-part update now gives the client one connected decision story. The recommendation stays tied to user evidence, release risk, and commercial control.

Build the 15-minute client agenda

A short agenda keeps the meeting focused on the decision the team needs. Each topic prepares the client for the confirmation at the end.

Add a 15-minute client agenda subheading below the weekly update.
List Decision and evidence as the first agenda topic.
List Bug impact as the second agenda topic.
List Revised scope and budget as the third agenda topic.
List Risks and owners as the fourth agenda topic.
List Confirmation of next actions as the final agenda topic.

You should now see five agenda topics beneath the client update. The sequence moves from evidence to impact before closing on ownership.

Write and rehearse the interview debrief

An interview answer needs a clear arc from the situation to the result. This structure shows how you connected product evidence, technical input, release risk, and budget control.

Write a Situation entry under Interview Debrief that introduces the uncertain backlog, fixed 120-hour budget, and monthly release.
Write a Decision entry that explains why autosave draft recovery ranked above the dashboard redesign.
Write a Tradeoff entry that explains why the Safari blocker displaced prior-version restore after code freeze.
Write a Result entry that states the release moved from 104 planned hours to 116 revised hours without exceeding the limit.
End the debrief with post-release monitoring for incomplete applications, autosave-related support tickets, upload failures, and hours against budget.

Before you rehearse, do you expect your client update to fit inside two minutes without losing any of its five required points?

Start a two-minute timer on your phone or computer.
Read the Client Update aloud once.

You should finish before the timer ends. Your spoken update should name the recommendation, evidence, tradeoff, budget position, and client ask.

Read the four-part Interview Debrief aloud once.
Confirm that your ending names incomplete applications, autosave-related support tickets, upload failures, and hours against budget.

That is the hard part done: you can now defend the release decision as a product choice, delivery tradeoff, and client commitment.

Secret mission

Hold the Recommendation Under Executive Pushback

The executive sponsor has promised the dashboard redesign to the board. Write a five-sentence response that protects the evidence-backed release outcome while giving the sponsor a credible path forward.

Clean Up Your Resources

Keeping this case in your Google Account creates no ongoing project cost because the project uses no paid features. Your options are to retain the files, close their browser tabs for now, or move them to Google Drive trash.

Resources you used:

The CivicPath Release Decision Google Sheets workbook. It contains Evidence, Release Plan, and Budget & Bugs.
The CivicPath Client Release Brief Google Docs document. It contains your release decision, feature specification, client update, interview debrief, and executive-pushback response.

Keep everything running

No action is needed. This option keeps your completed case ready for interview rehearsal or feedback.

Retain CivicPath Release Decision as your evidence and release-planning case.
Retain CivicPath Client Release Brief as your client-meeting and interview rehearsal script.
Share view-only copies if you want feedback without giving edit access.

Pause - I'll come back to this later

Pausing leaves both case files in your Google Account without keeping their browser tabs open. Google saves online changes automatically as you type.

Close the browser tab containing CivicPath Release Decision.
Close the browser tab containing CivicPath Client Release Brief.
Resume later by opening the saved files from Google Drive.

Delete - I don't want to use this again

Moving these practice files to Google Drive trash clears them from your active files. Your other Google Account files stay untouched.

Switch back to the CivicPath Release Decision workbook from earlier.
Move the open workbook to Google Drive trash from its file menu.
Switch back to the CivicPath Client Release Brief document from earlier.
Move the open document to Google Drive trash from its file menu.
Open the trash area in Google Drive.
Confirm that CivicPath Release Decision appears there.
Confirm that CivicPath Client Release Brief appears there.

You should see both file names in Google Drive trash. Your active case workspace is now cleared.

Nice Work!

You did it! You turned an uncertain CivicPath backlog into a client-ready release decision that protects the user outcome and stays within budget.

What you learned:

Use an evidence model to expose the weakness in a client-preferred feature. You showed why autosave draft recovery deserves priority over the dashboard redesign.
Build a roadmap-to-ticket chain from a quarterly objective. Your chain includes a feature specification with acceptance criteria and technical-lead estimates.
Rescue a monthly release after a late Safari upload bug reopened frozen code. You revised the plan from 104 hours to 116 hours while preserving the core autosave outcome.
Complete the Secret Mission by answering executive pushback in exactly five sentences. You defended the evidence while offering a clear path for dashboard discovery.

Ready to quiz yourself?