Software development lifecycle (SDLC) models are standardized frameworks for planning, organizing, and running a development project. They provide a fixed generic structure that gets adapted to specific project parameters: size, budget, duration, and risk tolerance.
As a PM, you do not need to implement the SDLC — that is the engineering manager's job. But you need to understand it well enough to have informed conversations about trade-offs, timelines, and what "done" means at each stage.
The three core phases
Every lifecycle model covers three fundamental phases:
Design: Define what will be built and how. Requirements, architecture, system design.
Build: Write the code, create the components, implement the design.
Maintain: After launch, update, fix, extend, and eventually deprecate.
These phases exist in every model. The models differ in how they sequence and overlap these phases, and how much they allow iteration within and between them.
Major SDLC models
Waterfall: Sequential. Design is completed before build begins. Build is completed before testing begins. Testing is completed before launch. Each stage is a gate — you do not move forward until the previous stage is done.
When it works: Large-scale projects with stable, well-understood requirements where changes mid-build are very expensive. Government projects, hardware-software integration. Not common in modern consumer software.
The problem: Requirements are almost never stable. By the time you finish a six-month waterfall build, the market has changed and users want something different.
Iterative (Agile): Work is divided into short cycles (sprints, typically 1-2 weeks). Each sprint produces a working increment. Requirements evolve based on feedback. The team adjusts direction each cycle.
When it works: Most modern consumer and B2B software products. Allows the product to evolve in response to user feedback. Supports the MVP mindset — ship something working, measure, improve.
The challenge: Without good product discipline, iterative becomes "make whatever is loudest this sprint." Agile needs clear product direction from the PM to avoid becoming reactive churn.
Evolutionary/Prototyping: Start with a rough approximation of the product. Put it in front of users. Refine based on what you learn. Repeat. The prototype evolves into the final product through successive iterations.
When it works: Novel products where you genuinely do not know what the right solution looks like. Early-stage startups. Design-heavy products where user behavior cannot be predicted from requirements alone.
Combined models: These are not mutually exclusive. A waterfall structure can contain Agile sprints within stages. An iterative product can use waterfall-style gating for major architectural decisions. Many teams use rapid prototyping for the discovery phase and switch to iterative delivery once direction is established.
What changes when you change the model
The SDLC model is not a technicality. It affects:
Development speed and time to market: Agile gets working software in front of users faster. Waterfall has higher upfront investment before anything is visible.
Product quality: More iteration usually means better quality because defects are caught earlier. But "quality" in this sense means fitness for user needs — not absence of bugs. Waterfall systems may have fewer code bugs but solve the wrong problem.
Project visibility: Agile has higher visibility — progress is visible every sprint. Waterfall systems are opaque for long stretches, then visible at delivery.
Administrative overhead: Agile requires continuous PM involvement — sprint planning, backlog grooming, retrospectives, reviews. Waterfall front-loads the specification work and has less ongoing overhead.
Risk exposure: Waterfall concentrates risk at the end (you discover misalignment late). Agile distributes risk across sprints (you discover misalignment early and course-correct).
Software engineering project constraints
Every project operates within constraints. Understanding these helps PMs have realistic conversations with engineering:
Budget: SE projects almost always have a fixed financial budget. Every feature added or changed has a cost.
Time: Time-to-market is a real constraint, not just a preference. Competitors are moving. User expectations are evolving.
Staff: The team has a fixed capacity. More engineers do not linearly reduce time — coordination overhead grows.
Visibility: Software projects are inherently less visible than physical construction. Progress is not apparent from looking at a screen of code. This is why teams produce artifacts — design documents, prototypes, reports, demos — that make progress tangible and reviewable. PMs should welcome these artifacts; they are not bureaucratic overhead, they are the evidence that work is actually happening.
Think about the last major feature or product you shipped.
- Which lifecycle model did your team actually use — waterfall, iterative, or something hybrid?
- Where did risk concentrate — upfront in unclear requirements, or mid-flight in changing direction?
- If you could change one thing about how the work was sequenced, what would it be?
Most teams think they are doing Agile but are actually doing waterfall with shorter stages. The signal: if requirements are set in stone at the start of a sprint and never revisited, it is not really iterative.
What Google does differently
Google stores billions of lines of code in a single repository — a practice called a monorepo — shared across tens of thousands of engineers globally. This is unusual and deliberately architectural: it enables instant dependency management, code reuse across teams, and systematic testing at scale.
The point is not to recommend monorepos for your startup. The point is that companies at sufficient scale can make non-standard SDLC choices that create competitive advantages impossible for smaller competitors to replicate. Lifecycle model is a strategic decision, not just a technical one.