The problem
AegisShield wanted to test a new web application security product without putting a real customer or live booking flow at risk.
Junior Technical Project Manager · Fictional product case
AegisShield Web Application Firewall
A new web application firewall product for AegisShield, taken from the first idea through product definition, safe testing and a controlled pilot decision.
My role
I turned the idea into a clear pilot, organized the work, connected risks to tests, and kept the decision points visible.
How I worked
Hybrid: a simple plan for scope, approvals, risks, and dates, with short build-and-test loops for the product work.
What happened
A simulated false positive was found, corrected, and retested. The pilot was accepted; production stayed outside the approved release.
Project timeline and documents
From sponsor handoff to product decision
Follow the AegisShield Web Application Firewall case from product definition and validation into launch execution. The Launch phase puts the approved marketing strategy into motion across five channels.
Phase 1
Initiation
- 01Before project planning
Sponsor Handoff and Scenario
The sponsor frames the customer problem and asks the PM to coordinate discovery for a new web application firewall product.
Details - 02Discovery stage
Product Discovery and Business Case
The PM turns the initial request into a testable product opportunity and an investment decision framework.
Details - 03Discovery decision gate
Discovery Findings and Sponsor Decision
The team records simulated findings and recommends a limited product-definition and technical-validation stage.
Details - 04Product definition and technical validation
Project Brief
The PM turns the discovery recommendation into a small, testable product stage.
Details - 05Stage authorization
Project Charter
The CTO authorizes the product-definition and technical-validation stage and sets its limits.
Details - 06Week 1; updated through the stage
Stakeholder Register and Communication Plan
The PM identifies who must shape, review, approve and receive updates about the AegisShield Firewall product stage.
Details - 07End of Initiation
Kickoff Meeting Notes
The team confirms the authorized product stage, working agreements, first planning actions and the gate into Planning.
Details
Phase 2
Planning
- 01Weeks 2–3
Product Scope and Requirements
The team converts the approved product boundary into requirements and acceptance criteria for the first AegisShield Firewall version.
Details - 02Weeks 2–4
Product Experience and Prototype
Design defines the administrator journey for setup, event review, rule management and safe exceptions.
Details - 03Weeks 3–4
Technical Approach and Delivery Plan
Engineering and Security compare technical paths and define a safe delivery sequence.
Details - 04Week 4 baseline
Work Breakdown Structure
The approved product-definition work is organized into deliverables and work packages.
Details - 05Week 4
RACI and Team Responsibilities
The team agrees who is responsible, accountable, consulted and informed for each product deliverable.
Details - 06Weeks 4–5
Product Backlog and Estimates
The work packages become prioritized product and technical backlog items with estimates and dependencies.
Details - 07Week 5
Budget and Capacity Plan
The PM makes the simulated capacity, licensing and operating-cost assumptions visible before pilot-build authorization.
Details - 08Week 5 baseline
Project Schedule
The PM maps the planning activities, dependencies and decision gates for the AegisShield Firewall.
Details - 09Weeks 5–7
Test and Validation Plan
QA, Security and Operations define how the AegisShield Firewall will be tested without risking a legitimate booking flow.
Details - 10Week 5 baseline; reviewed weekly
Risk Register
The team records the risks specific to launching a new application-protection product.
Details - 11Weeks 6–7
Data Protection and Operational Readiness
Security and Operations define the controls required before the AegisShield Firewall can be evaluated with BookEasy.
Details
Phase 3
Execution
- 01Weeks 6–8
Execution Board and Snapshots
The PM uses a visible execution board to track product-definition work, owners, dependencies and evidence.
Details - 02Week 7; resolved before gate
Issue Log
The team records a false-positive issue that blocks a legitimate booking in controlled testing.
Details - 03Weeks 7–8
Decision and Change Log
The PM records the decision to correct the rule and protect the pilot boundary instead of reducing safety evidence.
Details - 04End of week 8
Project Status Report
The PM reports the execution status, the safety issue, the recovery plan and the next sponsor gate.
Details
Phase 4
Validation and release
- 01Weeks 8–10
Test Results
QA records the safety, access, rule, exception, monitoring and recovery results before pilot acceptance.
Details - 02Week 11
BookEasy Pilot Review and Acceptance
BookEasy reviews the agreed application-protection scenarios and records acceptance of the limited pilot scope.
Details - 03Week 12
Go/No-Go Decision and Release Record
The sponsor reviews the evidence and records whether the AegisShield Firewall may proceed to the approved controlled release stage.
Details - 04Weeks 12–13
Stabilization and Operations Handover
The team monitors the controlled release and transfers support, monitoring, recovery and rule-ownership responsibilities to Operations.
Details - 05Week 13
Project Closure and Lessons Learned
The PM closes the AegisShield Firewall product-definition and pilot project and records outcomes, limitations and improvements for future work.
Details
Phase 5
Launch
- 01Before launch planning
Launch Sponsor Handoff and Readiness Review
The sponsor hands the validated AegisShield Web Application Firewall to the cross-functional launch team and confirms that the product is ready to enter launch planning.
Details
The project story
A clear idea, tested in small steps.
The case shows the work behind a new product: what problem it solves, what belongs in the first release, how the team tests it, and what the sponsor needs to decide before a real launch.
Weeks 1–2
Discovery and direction
Compared build, buy, and integrate options. Defined the first release and the pilot boundary.
Weeks 3–4
Scope and design
Created the requirements, administrator journey, prototype, backlog, budget, and delivery plan.
Weeks 5–6
Test and learn
Ran safe-flow and blocked-request tests. Found a legitimate booking blocked by a broad rule.
Weeks 7–8
Fix and decide
Narrowed the rule, added a controlled exception, retested the flow, and prepared the sponsor decision.
What changed during execution
A legitimate booking was blocked.
The test found a false positive caused by a rule that was too broad. I connected the issue to the requirement, made the correction visible, kept the pilot controlled, and required a retest before moving forward. That gave the sponsor evidence for a pilot decision instead of a guess.
1. DetectA real booking was stopped in testing.
2. CorrectThe rule was narrowed and the exception was controlled.
3. VerifyThe same flow passed the retest before the decision.
Evidence
The work is easy to review.
The boards are public simulated snapshots. They show how the work looked before the issue, during the issue, and after the decision.
What is included
A complete case, not just a slide.
Product
Discovery, business case, scope, requirements, and prototype.
Delivery
Charter, WBS, RACI, backlog, budget, schedule, and technical plan.
Controls
Tests, risks, data protection, issue log, and decision records.
Close-out
Pilot acceptance, release decision, handover, closure, and lessons learned.
About this case
AegisShield and BookEasy are fictional. This case is meant to show how I organize a technical product initiative, make assumptions visible, and use evidence to support decisions. It does not represent a real customer engagement or a live security service.