The moment a team decides to keep growing the product, every feature request that had been sitting on hold shows up at once. Sales pushes for one feature, support pushes for another, and the founder pulls out ideas that got shelved before launch. The list of asks keeps growing while the budget and the development team stay exactly the same size. Every request on that list comes with a real justification, so what to build isn't really the question. What comes first is.
The most common mistake at this point is working through requests in the order they arrived, or handling whoever's voice is loudest first. Running that approach through three or four cycles makes it clear there was never a real standard for what should have come first, or for how long it's safe to keep adding features. A team with a large enough budget can absorb some disorder here without it showing. Most startups don't have that kind of cushion, and one bad priority call early on can derail the whole product cycle.
In the previous part, the case for growing the current product rested on the original hypothesis still holding up. That same case is the starting point for setting priorities now.
What to Strengthen First
Deciding to keep growing the product only means the underlying hypothesis holds. It doesn't mean all four signals, reach, repeat, pay, and request, are equally strong. Usually one or two of them are still weak. Strengthening those weak links before adding anything new is the right order.
- When reach is weak: The first-time experience and the onboarding flow come first. Lowering the friction between signup and the moment someone actually reaches the core value is the priority.
- When repeat is weak: The core value itself needs sharpening. The reason someone has to come back has to be unmistakable.
- When pay is weak: Pricing and the payment flow get fixed before new features do. Piling on more features rarely opens a wallet that was already closed to begin with.
Only once those three signals are solid is it worth turning to the request signal, meaning new features. Reversing that order leaves the weak link untouched while surface features pile on top of it. The next decision point runs into the exact same wall. Settling this order once removes a source of friction that would otherwise resurface every cycle.
This reversal shows up often enough in booking platforms to name. The final step from browsing to a confirmed reservation runs five screens deep, and that structural drag goes unaddressed while the team ships a new review-sharing feature instead. Two cycles later, reach hasn't moved. The carefully built review feature never reaches most users, because most of them dropped off before they got near the step it was meant to improve. Fixing the booking flow first would have made the new review feature land harder too.
The Ratio Between Building and Cleaning Up
Balancing the work of adding new features against the work of tidying up the existing system matters just as much as getting the order right. A single cycle, one pass of planning, building, shipping, and observing, usually runs somewhere between two and six weeks.
About 30% of each cycle's capacity is worth setting aside for cleanup and structural work rather than new development. That covers the code that was written quickly early on, the logic that got connected as a stopgap, and the performance work that kept getting pushed to next time. Ignoring that ratio, development speed tends to visibly slow by the third or fourth cycle. Every feature added on top multiplies the points where it collides with existing code.
This ratio doesn't need elaborate tooling to manage. At the start of each cycle, a list of new features and a list of cleanup items, written side by side, is enough, along with a habit of checking that the second list never sits empty. If the cleanup column comes back empty two cycles in a row, that's a clear warning sign. From that point on, what's accumulating isn't product growth, it's technical debt.
Signals That Say It's Time to Stop
The process of growing the current structure can't continue indefinitely. Once the following four signs start showing up together, the current architecture has reached the limit of what it can reasonably absorb.
| Stop Signal | What It Means |
|---|---|
| Adding one feature takes longer with every cycle | The structure's cost of accepting new work has passed a reasonable level |
| Fixing one thing breaks something else | Modules have tangled to the point that independent changes are no longer possible |
| Onboarding for new users keeps getting more complicated | The features layered on over time have started burying the original core value |
| The development team has said "this needs a structural change" more than once | The people wrestling with the system's structure every cycle are usually the first to see its limits |
These signs rarely arrive on their own. Onboarding gets more complicated, so new-user conversion drops, so the team adds another feature to compensate, and that in turn stretches out the timeline of the next cycle. Each one feeds the next.
The development team's call for a structural change deserves particular weight, treated as evidence rather than opinion. They're the ones wrestling directly with the system's structure every cycle, and hearing it twice is a reasonable signal the architecture has reached its limit. The first time might be a difference in perspective. By the second time, it's solid enough ground to start planning a redesign.
When Improving Is Done
It's easy to assume the improve phase simply doesn't have an end point, but the real finish line isn't a finished feature. It's the next decision. Usually, after three or four cycles, somewhere around six to nine months in, the moment arrives to decide whether to keep the current structure or start planning a rebuild.
That judgment doesn't run on instinct. It draws on what actually got recorded cycle by cycle: what was added, what was cleaned up, and which problems kept coming back, checked against the stop signals above. Without that record, the decision point turns blurry, and the damage is often well underway before anyone notices. Two or more of the stop signals overlapping is generally the point to look seriously at a full rebuild. What to keep and what to let go of when redesigning the structure is the subject of Part 4.
Why We Manage the Roadmap Cycle by Cycle
Integrabbit breaks the product roadmap down cycle by cycle. When a cycle wraps, everything added during that period, everything improved on the existing structure, and everything carried over to the next cycle goes into a single table.
Tracking items in a scattered way leaves the ratio between building and cleanup an abstraction. Putting it on one table instead turns that split into visible data, along with any architecture stop signal. A task that keeps getting pushed to the next cycle shows up immediately in that same table instead of quietly disappearing into the backlog.
Whether that data points toward continuing to scale the current system or moving up the timeline for a structural redesign, the final call rests entirely with the client.
Previous: Improve or Rebuild: How to Decide After Your MVP
Next: If You're Rebuilding: What to Carry Over and What to Leave Behind
Unsure how many of these stop signals apply to what you're running today? A 30-minute consultation is a good way to check.