One of the coolest parts of my job is the diversity of the work. One day I could be launching a scrappy prototype intended to learn; the next day I could be helping an organization complete 3rd-round testing on a new account sign-in process. One took 2 days to design and will be live for two months. The other took 6 months to design and will be live for years, maybe forever now that they're implementing continual improvement principles.
The point is, I've been on both sides of this tension and I've learned that how fast you ship isn't a question of principle. It's a question of rhythm.
"It's better to get into the market as quickly as possible and have short feedback loops." is a common sentiment but it's not the only one. I often hear the other side "It's better to design something that people actually like; that won't need to be redesigned anytime soon."
Well, this a valid tension that could be framed by acknowledging both sides bring value. An over-reliance on either side can create problems. "Learning velocity" is a strengths-based way of framing shipping fast; "solution maturity" is a way of framing shipping slow and these two concepts are not enemies, they're partners. Like any great duo, these partners play off each other; knowing when to hand the mic from one to the other is part of the craft. Lean too hard into learning velocity and you risk a trail of half-baked ideas and exhausted teams. Cling too tightly to solution maturity and you might miss the window where your idea was most needed. The work isn’t about choosing sides it’s about listening closely to what the moment demands. Sometimes you need momentum. Sometimes you need stability. Most of the time, you need both, just not at the same time.
When Fast Is Fantastic
Prioritizing learning velocity makes sense when:
- You’re working in ambiguity.
- You need fast feedback to know if you're even in the right space.
- You’re exploring needs that are evolving or still being revealed.
This is especially powerful early in a product lifecycle or when you're developing something novel. Fast cycles allow us to experiment, uncover hidden patterns, and respond in real time to lived experience. You don’t need a perfect prototype to find out if you’re asking the right question, you just need something.
But shipping fast all the time has costs.
When Fast Starts to Fail
Without intentional boundaries, fast becomes frantic:
- The team burns out.
- The user experience fragments.
- Technical or systemic debt piles up.
You may find yourself solving the same problem over and over, never quite getting to the root of it.
This is where solution maturity plays a vital role. It’s the shift from learning to refining, from what’s possible? to what’s sustainable?
When Slow is Safer
Prioritizing solution maturity helps when:
- Stability matters more than novelty.
- People depend on the reliability of your solution: patients, clinicians, frontline staff, families.
- You’re designing within systems that need coherence, not just responsiveness.
Mature solutions build trust. They scale. They integrate. They let people rely on something.
But if we only aim for polish and permanence, we risk building beautiful answers to the wrong questions.
When Slow Becomes Stuck
Continually slow delivery can create its own kind of risk.
- Feedback arrives too late to meaningfully influence design
- Teams overinvest in unproven solutions
- Momentum and morale quietly erode
You get thoughtful work that no one uses or uses too late. The polish is there, but the purpose gets fuzzy.
This is why the polarity matters. It's not about choosing fast or slow it's about sensing what the situation calls for.
This Requires Judgment Not Just Process
What makes polarity management hard is that it’s not procedural. There’s no simple heuristic for when to speed up or slow down. It takes experience. And frankly, it takes some human intuition.
AI can optimize iterations. It can suggest next steps. But it doesn’t (yet) hold the context of organizational dynamics, emotional readiness, or the deep wisdom that comes from watching a team or system stretch over time. It can accelerate loops but not necessarily help you sense when to exit one.
Knowing when to lean into learning velocity vs. when to invest in maturity is a skill. And it’s one that gets better with reflection, with pattern recognition, and with exposure to failure and resilience alike. It's a kind of leadership that can’t be rushed and shouldn’t be.
Rhythm Over Routine
My first introduction to non-linear systems was at the dinner table. I remember my grandmother asking the same question, "How was your day?", and noticing how it landed completely differently depending on my mood, the moment, or her tone. Sometimes it opened up a deep conversation, sometimes it got a grunt. Same input, very different output. It didn't take long to realize that context mattered... a lot.
That lesson stuck with me, and I see it all time time in the work I do now. Designing within complex systems, whether a product, service or systemic change initiative, doing the same thing... the same way... won't always get you the same results. Many of these systems have memory. They shift. They flex and respond. What worked last time might not work this time. What felt slow before might be the exact pace you need now.
I've been encouraging my clients to stop searching for the right "way" to work and start searching for the right "rhythm" to work.
Rhythm is something you feel. You build it through experience, not just instruction. Through paying attention, not just performing the steps. And when you get it right, it’s not just more effective, it’s more human. Progress isn’t a process. It’s a pulse.
Jordan Julien
Jordan (he/him) is passionate about making products better for people, especially those who are often overlooked or underserved. He believes great design should be accessible, inclusive, and built with real people in mind.