Project Planning Prompt Templates

Project plan: Onboarding Redesign (8 weeks)

Phase 1: Discovery (Weeks 1-2)
Tasks:
- Interview 5 existing customers about onboarding friction (PM)
- Analyze current onboarding funnel data: where do users drop off? (PM + Engineer)
- Audit current flow for unnecessary steps (Designer)
- Document constraints: what can't change? (Engineer)

Milestone: Discovery summary document with top 3-5 problems to solve
Checkpoint: End of Week 2

Phase 2: Design (Weeks 3-4)
Tasks:
- Design new onboarding flow addressing top problems (Designer)
- Create interactive prototype (Designer)
- Test prototype with 3 customers, gather feedback (PM + Designer)
- Technical feasibility review of proposed design (Engineer)
- Iterate based on feedback and technical constraints (Designer)

Milestone: Approved design with customer validation
Checkpoint: End of Week 4
Dependency: Can't start Phase 2 until discovery findings are clear

Phase 3: Build (Weeks 5-7)
Tasks:
- Implement new onboarding UI (Engineer 1)
- Update backend logic for new flow (Engineer 2)
- Build tracking for new metrics (Engineer 1)
- Write automated tests (Both engineers)
- Internal QA and bug fixes (All)

Milestone: Feature complete, passing tests, ready for beta
Checkpoint: End of Week 6 (code complete), End of Week 7 (QA done)
Dependency: Design must be locked by start of Week 5
Risk: If design isn't final, build will slip or require rework

Phase 4: Launch (Week 8)
Tasks:
- Beta test with 5 customers (PM)
- Fix critical issues from beta (Engineers)
- Prepare rollout plan: gradual or all-at-once? (PM)
- Launch to all users (All)
- Monitor metrics for first 48 hours (PM + Engineers)

Milestone: Shipped to 100% of users
Checkpoint: Mid-Week 8 (beta feedback), End of Week 8 (launch)

Risks to watch:
1. Customer feedback in discovery reveals bigger problems than expected. Mitigation: Timebox discovery to 2 weeks regardless. Solve the biggest problems first.
2. Design and engineering disagree on feasibility. Mitigation: Engineer in design reviews starting Week 3, not after.
3. Beta reveals critical bugs. Mitigation: Week 8 has buffer. If needed, push launch by 2-3 days rather than ship broken.

Buffer built in: Week 7 has slack for bug fixes. Week 8 beta is short but gives room to catch issues before full launch.

Task breakdown: User Authentication

Week 1: Foundation

Backend engineer:
1. Research auth approaches (JWT vs. sessions vs. OAuth). Decide on approach. (4 hrs)
 Done when: Decision documented with reasoning

2. Set up auth library/framework in Node.js. (2 hrs)
 Done when: Library installed, basic config working locally
 Depends on: Task 1 decision

3. Create user database schema (users table with email, hashed password, created_at). (2 hrs)
 Done when: Migration written and tested locally

4. Build registration endpoint (POST /auth/register). (4 hrs)
 Done when: Endpoint accepts email/password, creates user, returns success. Tested with Postman.
 Depends on: Tasks 2, 3

5. Build login endpoint (POST /auth/login). (4 hrs)
 Done when: Endpoint validates credentials, returns token/session. Tested.
 Depends on: Tasks 2, 3

6. Build auth middleware to protect routes. (3 hrs)
 Done when: Protected routes return 401 without valid auth. Tested.
 Depends on: Task 5

Frontend engineer:
7. Create registration screen UI. (4 hrs)
 Done when: Form with email, password, confirm password. Validation shown. Navigation works.

8. Create login screen UI. (3 hrs)
 Done when: Form with email, password. Navigation to registration. Forgot password link (placeholder).

9. Build auth state management (store token, check if logged in). (4 hrs)
 Done when: App can store/retrieve auth token, show different UI for logged in vs. not.

Week 2: Integration + Polish

10. Connect registration UI to backend endpoint. (3 hrs)
 Done when: User can register through app, success/error handled.
 Depends on: Tasks 4, 7, 9

11. Connect login UI to backend endpoint. (3 hrs)
 Done when: User can log in through app, token stored, redirected to main app.
 Depends on: Tasks 5, 8, 9

12. Implement logout functionality. (2 hrs)
 Done when: User can log out, token cleared, redirected to login.
 Depends on: Tasks 9, 11

13. Add loading states and error handling to auth flows. (3 hrs)
 Done when: User sees spinner during API calls, clear error messages on failure.

14. Test end-to-end auth flow on device. (3 hrs)
 Done when: New user can register, log in, use app, log out, log back in. Works on iOS and Android.
 Depends on: Tasks 10, 11, 12

15. Code review and documentation. (3 hrs)
 Done when: Both engineers have reviewed each other's code. README updated with auth setup.

Critical path: Tasks 1 > 2 > 4/5 > 6, then 10/11 > 14. Frontend can work in parallel on UI until integration.

Risk: If auth approach decision (Task 1) takes too long, everything slips. Timebox to 4 hours, default to JWT if no clear winner.

Project diagnosis:

The real problem: Resource allocation, not scope or timeline. You had a plan, an engineer got pulled away, now you're behind. This is a classic 'optimistic planning meets reality' situation.

Current math: 70% of engineering work remaining, 2 weeks until deadline, 1 engineer (assuming lead is back). If the first 30% took ~1 week at full capacity, 70% takes ~2.3 weeks. You're short by a few days minimum, more if anything else goes wrong.

Realistic options:

1. Crunch to hit deadline
- Pros: Meets original timeline. Board sees what they expected.
- Cons: Team burns out. Rushed code has bugs. You'll pay for this later.
- Realistic? Maybe, but risky. One more surprise and you miss anyway.

2. Reduce scope to hit deadline
- What to cut: Do you need all planned features for launch? Could you launch with core pricing display and defer the calculator/comparison tool?
- Pros: Hits deadline with less stress. Board sees something live.
- Cons: Might launch something half-baked. Need to manage expectations.
- Realistic? Depends on what's cuttable. Worth exploring.

3. Slip deadline by 1 week
- Pros: Realistic timeline. Quality maintained. Team not burned out.
- Cons: Board meeting is in 3 weeks, so this still works, but barely. Need to communicate proactively.
- Realistic? Most honest option if scope can't be reduced.

4. Add resources
- Pros: Could accelerate if another engineer can ramp quickly.
- Cons: Adding people to a late project often makes it later (onboarding overhead). Only helps if there's parallelizable work.
- Realistic? Only if you have someone who knows the codebase and can be productive immediately.

My recommendation: Combination of options 2 and 3.

1. Review scope with engineering today. What's the minimum viable pricing page? If you can cut 30% of the work, you might hit the deadline.
2. If scope can't be cut enough, communicate the slip now, not later. One week delay communicated proactively is better than missing the deadline by surprise.
3. Don't crunch. You'll need this team for the next project too.

How to communicate to stakeholders:
'We hit a setback when [engineer] was pulled for [critical bug]. The pricing page is on track for [new date], which is before the board meeting. We prioritized the core pricing display and will add [deferred features] in a fast-follow. Do you want me to walk you through what will be live vs. what comes next?'

Own it, give the solution, offer to discuss. Don't just report bad news without a plan.

Milestone framework for Microservices Migration:

Milestone cadence: Monthly for a 6-month high-risk project. Frequent enough to catch problems, not so frequent that milestones become status meetings.

Milestone 1: Architecture Finalized (End of Month 1)

Criteria for done:
- Service boundaries defined and documented
- Data ownership per service decided
- Communication patterns chosen (sync vs. async, protocols)
- Migration sequence determined (which services first, which last)
- CTO and VP Engineering have signed off on architecture

Why this milestone: If architecture isn't right, everything else is wasted effort. This forces alignment before coding starts.

Stakeholder deliverable: Architecture doc + 30-min review with CTO

Milestone 2: First Service Extracted (End of Month 2)

Criteria for done:
- One service (ideally low-risk, well-bounded) running in production
- Monolith still works, now calling the new service
- Deployment pipeline established for microservices
- Monitoring and alerting in place for new service
- No increase in error rates or latency

Why this milestone: Proves the approach works. Surfaces integration problems on a low-risk service before touching critical ones.

Stakeholder deliverable: Demo of service running + metrics dashboard showing health

Milestone 3: 30% Migrated (End of Month 3)

Criteria for done:
- 3-4 services extracted and running
- Patterns established for common problems (auth, logging, data sharing)
- Team velocity understood (how long does a service take?)
- No production incidents caused by migration

Why this milestone: At 30%, you have enough data to forecast the rest. If you're behind here, you know the 6-month timeline is at risk.

Stakeholder deliverable: Progress update with revised timeline if needed

Milestone 4: Critical Services Migrated (End of Month 4)

Criteria for done:
- High-risk, customer-facing services extracted
- Load testing completed at 2x expected traffic
- Rollback plan tested (can we revert if something breaks?)
- On-call team trained on new architecture

Why this milestone: This is the scary part. Critical services migrated successfully means the hardest work is done.

Stakeholder deliverable: Sign-off from affected team leads that their services are production-ready

Milestone 5: Migration Complete (End of Month 5)

Criteria for done:
- All planned services extracted
- Monolith reduced to shell or deprecated
- Documentation complete for new architecture
- Performance meets or exceeds old system

Why this milestone: Feature complete, but not done. Month 6 is for stabilization.

Stakeholder deliverable: Before/after comparison on key metrics

Milestone 6: Stabilization Complete (End of Month 6)

Criteria for done:
- 30 days in production with no migration-related incidents
- Tech debt from migration tracked and prioritized
- Retrospective completed with learnings documented
- Old monolith code archived or removed

Why this milestone: The project isn't done when you ship. It's done when the new system is stable and the team has learned from the process.

Stakeholder deliverable: Final retrospective summary and 'lessons learned' doc

Risk checkpoints: Milestones 2 and 3 are your early warning system. If Milestone 2 slips, the approach may be wrong. If Milestone 3 shows slow velocity, the timeline is wrong. Surface these to stakeholders immediately if they happen.