Ask any product forum what the phases of digital product development look like and you'll get the same answer every time: discovery, definition, design, development, launch. Maybe with a double diamond diagram if the person answering has a soft spot for frameworks. The answer is technically correct and, at the same time, nearly useless.
The model of phases isn't wrong. What's wrong is that it describes the process as a clean, sequential funnel—when in practice it's closer to a construction project. There are re-surveys, there are foundations that constrain everything built on top of them, there are moments when reality forces you backwards, and there are decisions made in week two that get paid for—with interest—in production. Nobody tells you this in the first meeting.
This post doesn't rehearse the standard model. It reads the model from the inside, surfacing the real problems that emerge at each phase, and proposes the criteria we apply at Room 714 to make each stage genuinely serve the next one.
- The phases themselves aren't the problem: the illusion that they're watertight and don't feed back into each other is.
- The technical architecture you choose in weeks two and three will follow you for years.
- Launch is not the end: it's the moment the product stops being yours and starts belonging to the user.
Discovery: The Phase That Decides Everything Else (and That Most Teams Rush)
Discovery has a bad reputation in certain circles. Sometimes because it runs too long and produces nothing tangible; sometimes because it runs too short and produces a false map of certainties. Both extremes are expensive, but the second is more so: a rushed discovery is a debt of understanding that gets repaid as redesigns, scope changes mid-sprint, and features built for a user nobody properly researched.
The question that drives a good discovery is not "what does the user want?" That question returns feature lists. The right question, through a Jobs-to-be-Done lens, is "what progress is the user trying to make that they currently can't make well?" The difference seems subtle; in practice it determines whether you build a product that solves something or a well-packaged catalogue of functionality.
The deliverables that matter in this phase are three: a shared definition of the problem (not the product), a clear and falsifiable value hypothesis, and a decision about what will not be built. That last point is the hardest and most valuable. A good discovery ends with explicit constraints, not just open possibilities.
A discovery that ends with "anything is possible" hasn't finished: it has deferred the hard decisions to the most expensive moment, which is when there's already code written.
Architecture and Design: When Decisions Become Expensive to Reverse
Most projects treat design and technical architecture as parallel phases that coordinate at the end. This is a mistake with predictable consequences: design proposes flows that the architecture can't support without rewriting half the service layer, or architecture makes data structure decisions that force design to abandon interactions that were critical to the experience.
At Room 714 we treat these two disciplines as a single conversation, even when different people are having it. The designer needs to know what costs half a sprint and what costs three weeks. The architect needs to understand which flows are critical for the user before deciding how to model the data. When that conversation doesn't happen, the resulting product is technically correct and experientially mediocre—or the reverse.
Architecture: the cost of invisible decisions
Architectural choices on a new digital product rarely get the time they deserve. The team is under pressure to start, there's a deadline someone put on a slide, and structural decisions get made by default—"we use what we know"—or by trend—"everyone's doing microservices." Both criteria are equally poor if they don't first pass through the question of what this specific product actually needs.
A well-structured monolith can be the right answer for a product that doesn't yet know what it will need to scale. A microservices architecture can be the right answer for a large team with well-defined domains. The mistake is applying the pattern without understanding the context. As we've written before on AI tool orchestration, the problem isn't usually the technology choice itself—it's not knowing why you're making it.
Design: what the prototype can't simulate
Design in this phase has a specific trap: prototypes work well in lab conditions and poorly in real ones. In a Figma usability test, the user knows they're evaluating something; in production, the user is in a hurry, their phone is at 12% battery and they just got a notification. Design has to anticipate that context, not the context of the test.
This doesn't mean prototypes are useless—they're indispensable. It means deliberately designing for adverse conditions: error flows, empty states, graceful degradation when something fails. Those screens are the ones users see most often in production and the ones that receive the least attention during the design phase.
Development: Speed, Debt, and the Myth of the Perfect Sprint
Iterative development works. Sprints work. What doesn't work is treating each sprint as an independent unit that optimises its own output without thinking about the structure it's accumulating. Technical debt isn't generated by bugs; it's generated by shortcut decisions that seem reasonable in sprint three and that by sprint fifteen make any change an archaeological excavation.
There are three types of debt we see repeatedly in products that come to us for rescue or modernisation. The first is comprehension debt: code nobody fully understands because it was written fast with no record of the decision behind it. The second is coupling debt: modules that depend on each other in implicit ways, so touching one breaks another. The third—and the most expensive—is architecture debt: a base structure that doesn't support the use cases the product has acquired over time.
This third category is what turns what should be a three-month migration into a year-long rewrite. And it almost always originates in the previous phase: architecture chosen by default, under time pressure, without the conversation we described above. It's worth reading our analysis of how system design decisions get paid for in production when the initial assumptions no longer hold.
Development velocity isn't measured in story points per sprint. It's measured in how long it takes the team to make the tenth significant change, not the first.
The antidote is not going slow. It's going with criteria. Some shortcuts cost little now and cost little later; others cost little now and compound with interest. Distinguishing between them is part of the engineering work that teams usually don't have time to do—or don't have the mandate to do—under delivery pressure.
Launch and Post-Launch: The Phase the Roadmap Always Underestimates
Launching a digital product has a paradox: it's the moment of maximum visibility and, simultaneously, the moment when you have the least information about whether what you've built actually works. Internal tests, closed betas, and pilots with selected users are useful but structurally biased: the users who participate have more patience, more motivation to give feedback, and less representativeness of real production behaviour.
The first month post-launch should be treated as a phase of active observation, not full-velocity development. The team needs sufficient instrumentation to see where the flow breaks, which features get used and which don't, where unexpected friction appears. Without that instrumentation, roadmap decisions get made on internal opinions, which are the most expensive substitute for real data.
This is where the customer experience perspective becomes central again. A product can function technically and have terrible adoption because the activation flow has three steps that seemed reasonable in design and that in production are incomprehensible to 40% of users. Detecting that in week two post-launch and fixing it in week four is the kind of agility that actually matters. Detecting it in month six, when there's already churn from users who never activated, costs far more.
The living product: maintenance as a strategic decision
After launch, digital products enter a phase that roadmaps tend to call "maintenance" with a certain condescension, as if it were minor compared to the initial build. It isn't. Maintenance is the phase in which you decide whether the product improves or slowly degrades while the team chases new features.
A product without continuous investment in its technical health and its experience accumulates debt on both dimensions. Technical debt we've already covered. Experience debt is less visible but equally real: flows that worked well when the product had 500 users start creaking at 5,000—not because the code fails, but because use cases have evolved and the design hasn't kept pace.
The strategic decision in this phase is not how much to invest in maintenance, but how to structure the team and process so that product evolution is continuous and proactive rather than reactive. A team that only acts when something breaks is a team that's always behind its users. And users, when they've waited long enough for improvements, stop waiting.
If you have a product that already exists and you're evaluating how to structure its development from here—which phase to prioritise, which debt to tackle first, how to organise the team—our software product development practice works exactly that: technical diagnosis, architecture prioritisation, and designing the evolution. No methodology dogma, just business judgment.
