November 22, 2025
My Chief of Staff (agent role) was curious about what drove a dramatic velocity spike in late November: fifteen simultaneous sessions, security epic completed in hours, 26% throughput improvement. Was it better process? More discipline? Heroic effort?
The answer we came up with: "Natural oscillation. Discovery and build. Consolidation and growth. Not forcing things into an artificial steady state. Follow the project's natural rhythms."
The oscillation
Projects breathe. They inhale (discovery, exploration, uncertainty) and exhale (building, execution, shipping). Neither phase can be sustained indefinitely.
Trying to always be in build mode leads to building the wrong things. You're executing without knowing what should be executed. The code ships but the product drifts.
Trying to always be in discovery mode leads to analysis paralysis. You're learning without applying. The insights accumulate but nothing ships.
Healthy projects oscillate between these modes. The rhythm varies — sometimes days, sometimes weeks — but the pattern persists.
What drove November's peak
The late November velocity spike wasn't random. It followed a specific pattern:
Alpha milestone created momentum. External deadline: first real user arriving. The project wanted to converge.
E2E testing discoveries created issues needing attention. Exploration phase (testing) generated work for build phase (fixing).
Alpha setup work revealed configuration gaps. Using the system as a real user would exposed what was missing.
Ted Nadeau's strategic ideas catalyzed breakthroughs. External perspective triggered internal clarity.
Each of these created energy that the project was ready to use. The velocity spike was released, not forced. The project had accumulated potential during earlier phases and spent it during the peak.
The consolidation phase
After the peak comes consolidation, and not because the energy has run out but because the project needs to integrate what was built.
November 25–27 was that consolidation period. The CXO role's sessions explored UX vision, object model decisions. This sort of philosophical work can feel less productive, at least in terms of velocity metrics, but it's key to establishing foundations for the next build phase.
After peak delivery, this kind of deliberation can read as a slowdown, a loss of pace, but the digestion is critical. The build phase created capabilities. The consolidation phase determines how those capabilities become coherent.
Teams that don't consolidate accumulate coherence debt. Features exist but don't fit together. The product has capabilities but not identity. Eventually, the debt comes due as major refactoring or strategic confusion.
Recognizing the rhythm
The project signals what mode it's in:
Discovery mode signals:
- Questions multiplying faster than answers
- Uncertainty about what to build next
- External inputs creating new directions
- Existing approaches feeling inadequate
Build mode signals:
- Clear completion criteria
- Known patterns ready to apply
- Decisions already made
- External deadline creating focus
Consolidation signals:
- Recent build phase completed
- Integration questions emerging
- Need for coherence across new capabilities
- Space for reflection available
The discipline isn't forcing one mode — it's recognizing which mode the project is in and working with it.
Fighting the rhythm
Teams fight project rhythms in predictable ways:
Forcing build during discovery: "We need to ship something." This results in shipping the wrong thing. The discovery phase exists because what to build isn't clear yet.
Forcing discovery during build: "Let's reconsider the approach." This leads to thrashing. The build phase exists because decisions have been made. Revisiting them mid-execution destroys momentum.
Skipping consolidation: "We shipped — what's next on the list?" This sort of heedless frenetic pace creates fragmented products. The consolidation phase exists because building creates integration needs.
Extending consolidation indefinitely: "We're not ready yet." This leads to stagnation. Consolidation should integrate and prepare, not defer indefinitely.
I've worked with human teams that had trouble establishing a healthy work rhythm because we kept trying to go against the grain, fight the tide, ignore the signal about what was important and what was required.
The steady-state myth
Some methodologies promise steady-state productivity. Consistent velocity. Predictable output. The same number of story points every sprint.
This may work for some cases of maintenance and well-understood domains. It fails for creative work, new products, and genuine uncertainty.
Creative work has phases because creativity has phases. Exploration can't be scheduled. Breakthrough moments don't arrive on cadence. Integration needs vary based on what was built.
Attempting steady-state for work that isn't steady-state produces theater. Teams hit their velocity numbers by adjusting what counts as work. The metric is satisfied while the product suffers.
Following the rhythm
Following project biorhythms means:
In discovery mode: Explore. Don't force premature decisions. Let questions multiply. Seek external inputs. Accept uncertainty.
In build mode: Execute. Don't revisit settled decisions. Apply established patterns. Meet external deadlines. Trust previous exploration.
In consolidation mode: Integrate. Connect new capabilities. Establish coherence. Prepare foundations. Allow reflection.
The skill is recognizing transitions. When has discovery done its work? When is build momentum exhausted? When has consolidation created readiness for the next cycle? It can be hard to tell at times and cultivating your instincts about this really pays off over time.
The PM's role
Product managers often feel pressure to maintain constant forward motion. Every week should show progress. Every sprint should ship features. Every month should hit targets. For a PM, success is sometimes reduced to shipping.
The idea of project biorhythms suggests a different responsibility: recognizing which mode the project needs and creating conditions for that mode.
In discovery, the PM creates space for exploration. In build, the PM clears obstacles to execution. In consolidation, the PM protects time for integration.
The sprint velocity metrics don't capture this. They measure build-mode output. Discovery and consolidation look like slowdown even when they're essential.
Wise PMs know that apparent slowdowns often precede velocity spikes. The late November peak didn't come out of nowhere: it came from October's exploration and early November's preparation.
Getting in the groove
The velocity spike happened when the project was ready for build mode. The foundations supported it. The patterns were established. The decisions were made. The team could execute because preparation had been done.
Forcing that velocity in October would have failed. The project wasn't ready. Trying would have produced rushed decisions and rework.
Following the rhythm meant building when building was right. Not sooner, not later. Right timing produced right outcomes.
Next on Piper Morgan: Five Whys for Design Decisions — Sunday's insight on the diagnostic discipline that surfaces the real question underneath a feature ask.
Have you felt your projects' natural rhythms? When has forcing wrong-mode work backfired? How do you recognize when a project is ready to shift phases?