The SDLC is changing under our feet

The software development lifecycle was built around scarcity.

Scarce engineering time. Scarce prototyping fidelity. Scarce access to data. Scarce research bandwidth. Scarce ability to test an idea before asking a whole team to believe in it. Scarce capacity to polish the last mile once the first version finally made it into production.

That scarcity shaped everything: roadmaps, handoffs, discovery rituals, design artifacts, sprint planning, MVP definitions, backlog hygiene, and the amount of compromise everyone learned to treat as normal.

But the scarcity is changing. Unevenly, with risk, no magic. Enough to make the old operating beliefs look suspicious.

Five months ago, a serious MVP still felt like a six-month undertaking in many teams. Not because everyone was slow. Because the path had so many gates: clarify the problem, align stakeholders, map the journey, design the flows, define the data needs, negotiate scope, wait for implementation, discover the edge cases, cut the delight, cut the polish, ship the thing, then live with the half-baked version longer than anyone wanted because the team had already moved on.

In my own recent work, I have watched something that once felt like a six-month MVP become a six-day first product slice. Not because the work got easy. Because the cost of learning from something real collapsed.

Every product should not be built in six days. The old MVP was often the smallest version the team could afford to build. The new MVP can be the smallest version honest enough to learn from.

That is a higher standard. It is permission to stop pretending that a brittle, ugly, under-instrumented product is the natural price of moving quickly.

One of the biggest changes is that designers can get closer to the data schema. That sounds dry until you have watched an entire product get distorted because the interface had to inherit a data model nobody questioned early enough.

A designer does not need to become the database architect to have useful influence here. But we can now inspect fields, sketch object relationships, prototype with real API responses, notice when the system is missing a concept users clearly need, and ask sharper questions before the schema hardens around the wrong nouns.

Journey maps used to stop at emotions, touchpoints, pain points, and opportunities. Those are still useful. But now a good journey map can also become a first draft of the product's object model. What has to be remembered? What changes state? What needs a source attached? What belongs to the user, the team, the system, the model, the source, the review gate?

This is where design becomes more consequential. The schema is one of the forces shaping the user's experience.

For all the new machinery, I keep coming back to one very manual first step: map the user journey.

It almost never fails as an anchor. Not because journey maps are sacred. Because they force the team to name the sequence of lived experience before the tools start producing artifacts at inhuman speed.

Who is trying to do what? What do they know at each moment? What are they afraid of? What proof do they need? What does the system know that the user does not? Where does trust get earned or lost? Where is the handoff? Where does the product need to remember something on the user's behalf?

Once that map exists, the rest of the work can flow from it: data objects, API needs, copy, permissions, states, empty states, AI prompts, eval criteria, analytics events, onboarding, support patterns, and backlog items. The journey map becomes the manual human first pass before the machine starts helping with scale.

The backlog used to be where ideas went to wait. Sometimes patiently. Sometimes forever.

With AI in the workflow, the backlog can become more alive. Not a junk drawer. Not a graveyard. A product intelligence system that keeps changing as research, data, product usage, technical constraints, design-system patterns, and customer evidence change.

A good backlog item should be able to carry more than a title and a priority. It can carry the user journey moment, the evidence, the source, the confidence level, the related schema object, the design-system implication, the AI risk, the measurement plan, and the reason it matters now.

That changes planning. If the backlog is alive and trustworthy, planning no longer has to cosplay certainty six months to a year in advance. The team can hold a stronger 1-2 month planning horizon, keep the longer-term direction visible, and let the work respond to what the product is actually teaching them.

A vestigial belief is something that used to be adaptive and now quietly gets in the way.

One belief is that design should stay out of implementation details. That made sense when touching implementation meant derailing engineers or pretending designers were experts in systems they could not inspect. It makes less sense when a designer can use AI tools to explore the system, build a prototype, understand the shape of the data, and bring a better question to engineering.

Another belief is that MVP means ugly, thin, and temporary. That was often a resource compromise disguised as product wisdom. If production-quality UI, real data, instrumentation, accessibility checks, and thoughtful copy are more accessible, the minimum bar should move.

Another belief is that roadmaps become safer when they stretch farther into the future. Sometimes they do. But often they just make everyone defend guesses for longer. If the team can build and learn faster, the more responsible move may be a shorter planning loop with better evidence and clearer decision gates.

This might be the part I feel most strongly as a designer. Teams have tolerated half-baked live products because the alternative was not available. Fixing the awkward flow, polishing the empty state, instrumenting the event, improving the data view, adding the missing review step, tightening the copy, making the prototype production-ready: all of that competed for scarce time.

When resources become more available to more builders on the team, the moral math changes. The product can get better sooner. The awkward thing does not have to sit there for three quarters while everyone apologizes for it in sales calls and customer conversations.

That does not mean every builder should ship whatever they want. It means teams need better guardrails. Design systems, review gates, source-of-truth docs, test routines, observability, and clear ownership become more important because more people can now move the product.

Abundance needs stronger quality practice.

The old lifecycle was a relay race: discovery hands to design, design hands to engineering, engineering hands to QA, QA hands to launch, launch hands to learning. Every handoff leaked context.

The new loop is tighter. A designer maps the journey, sketches the objects, builds a prototype against real or representative data, tests the interaction, identifies schema gaps, ships a small production slice, watches the evidence, updates the backlog, and does it again.

Engineering still matters enormously. Product still matters. Research still matters. Quality still matters. The difference is that the borders are more permeable. More of the team can work closer to the product reality, and the artifacts can be alive instead of ceremonial.

The SDLC becomes less like a factory line and more like a human-legible system.

It asks us to get braver about the parts of product development we used to stand beside.

Brave enough to ask what the schema assumes about the user. Brave enough to prototype with real data even when the first pass is messy. Brave enough to ship a small feature and measure it. Brave enough to say the MVP bar is higher now because the tools changed. Brave enough to make the journey map the anchor, then let the backlog, prototype, data model, and release plan evolve from it.

It also asks us to protect taste. When everyone can generate something, the scarce thing becomes judgment. What should exist? What should wait? What is true? What is overfit? What is humane? What is shippable? What needs one more review gate before it touches a user's real workflow?

I want product development with AI in the workflow to become a way for teams to stop accepting mediocre software as the inevitable first step.

The promise is that more builders can get closer to what the product is actually doing sooner.

When that happens, planning gets shorter and sharper. Backlogs get more alive. MVPs get more honest. User journeys become operational artifacts. The live product improves before everyone has learned to route around its flaws.

I want the shift to mean less wasted time living with work we already know how to make better.