Why I'm writing about SDLC
This was the single most powerful framework I learned in my first year in software.
It gave me a way to systemize how I think about development. And years later, it's still my go-to lens whenever something feels broken.
Delivery too slow? Look at SDLC. Too many bugs? Look at SDLC. Team burning out? You guessed it.
I ask myself: Are we doing all the steps? How well? How long does each take?
And yet I'm still surprised how many internal PMs have never been taught this. That's not their fault. It just shows how little formal training we get before being dropped into real delivery work that feels like a nightmare.
What is SDLC (and why you should care)
SDLC is a framework that guides software from idea → retirement.
It sets standards for how software should be built to protect quality, speed, and risk, and to make sure you're spending resources on the right things at the right time.
It's used across industries → banking, healthcare, SaaS, logistics, enterprise IT. Basically anywhere software gets built.
One important note → SDLC is a framework, not a methodology.
You can run it inside Agile sprints. Inside Kanban. Even inside waterfall. Whatever your delivery flavor is, SDLC still applies underneath.
Why skipping SDLC quietly hurts you
Here's the uncomfortable part.
If you don't understand SDLC as a PM:
→ You can't guarantee quality. You won't know where bugs are sneaking in.
→ You can't guarantee timelines. You'll miss hidden work (testing, deployment, handoffs) and your estimates will always feel "off."
→ You'll miss risks. Security, compliance, performance → these live inside specific phases, and if you don't see the phases, you don't see the risks.
→ You can't plan resources properly. You'll under-staff testing, forget about DevOps, or surprise your team with a release nobody prepared for.
→ You'll struggle in conversations with engineering. Because you won't have the shared language.
None of this shows up on day one. It shows up six months in, when things start slipping and nobody can explain why.
The SDLC phases (and your job in each)
Here's the PM-friendly breakdown.
1. Planning & Requirements
What happens → Define the problem, goals, scope, and high-level needs.
Your job → Bring the business case. Clarify the "why." Write the PRD. Align stakeholders before a single line of code is written.
Skip it? → Your team will build something. But it will be a surprise what it is.
2. Design
What happens → Architects and senior devs decide how the solution will be built (architecture, data models, integrations).
Your job → Ask questions. Understand trade-offs. Flag anything that affects user experience, scalability, or future roadmap work.
Skip it? → You will create technical debt, no doubt. And worse → you might miss security and compliance items that bring real risk into production.
3. Development
What happens → Engineers build the thing.
Your job → Protect the team from scope creep. Unblock decisions. Keep stakeholders informed without interrupting the team every day.
Skip it? → Nobody skips development. But if you skip doing your job in it, developers burn out from unclarity, increasing scope, and tight deadlines. They deliver something that may not even fit the need.
4. Testing
What happens → QA validates the build against requirements. Bugs get logged and fixed.
Your job → Prioritize bugs ruthlessly. Decide what blocks release vs. what can wait. Make sure test coverage matches real user scenarios.
Skip it? → Do it halfway, and the next months of your life will be spent firefighting incidents in production.
5. Deployment
What happens → The software goes live (staged rollout, full release, or feature flag).
Your job → Coordinate communication. Align with support, training, and stakeholders. Make sure nothing goes out that users aren't ready for.
Skip it? → This phase literally builds your reputation. And it chips away at it fast if done badly.
6. Maintenance
What happens → Monitoring, bug fixes, small improvements, eventually retirement.
Your job → Track incidents. Feed learnings back into the next planning cycle. Decide when something needs a refactor vs. a rebuild vs. a sunset.
Skip it? → You have to take care of the old stuff even more than the new. Otherwise you're not learning → you're just piling up features.
How to use SDLC to drive improvements
This is where SDLC stops being theory and starts being useful.
Whenever something feels off in delivery, walk through the phases and ask → where is this breaking?
A few real examples of how this works:
Example 1 → "We keep missing deadlines." Walk the phases. You might find that Planning is rushed, so Development hits surprises mid-sprint.
Fix → spend more time on requirements, not more time coding.
Example 2 → "We ship bugs to production." Walk the phases. Testing might be squeezed into the last two days of the sprint.
Fix → shift testing earlier, or split stories so QA runs in parallel.
Example 3 → "Stakeholders are always surprised by releases." Walk the phases. Deployment has no communication step.
Fix → add a release comms checklist as part of Deployment, not after it.
The power of SDLC is that it turns vague pain ("things feel slow") into a specific phase with a specific fix.
Using AI across the SDLC (and what NOT to outsource)
AI can help at every phase. But some things you should never hand over.
Here's how I think about it:
Planning & Requirements
Keep → Business judgment. User insights. Stakeholder trade-offs. These need human context.
Outsource → PRD drafting, user story generation, edge case brainstorming, competitor summaries.
What I use → Our internal version of Claude.
Design
Keep → Final architectural decisions. Those belong to your engineers and architects.
Outsource → Summarizing architecture options, generating diagrams, explaining technical concepts in plain language.
What I use → Our internal version of Claude.
Development
Keep → Production code ownership. Security-critical logic. Anything touching sensitive data.
Outsource → Code snippets, boilerplate, documentation drafts.
What my dev team uses → GitHub Copilot.
Testing
Keep → Exploratory testing and judgment on what "good enough" looks like for your users.
Outsource → Test case generation, edge case discovery, bug report drafting.
What my testers use → Our internal version of Claude.
Deployment
Keep → The actual go / no-go decision.
Outsource → Release notes drafts, stakeholder communication templates, rollback checklists.
What I use → Our internal version of Claude.
Maintenance
Keep → Root cause analysis and the call on whether to refactor, rebuild, or retire.
Outsource → Incident summaries, pattern detection across tickets, knowledge base updates.
What I use → Our internal version of Claude.
The rule I follow → AI drafts, humans decide.
