Product Conditioning

When I was a freshman in college, I started exercising regularly. I learned from my uncle, a bodybuilder who owned a custom motorcycle shop at the time. It was important to learn how to exercise the right way: muscle movements, training splits, proper form. I played sports growing up, but I never lifted weights seriously. I was 130 pounds soaking wet coming out of high school. So when I started working out, my body responded. I remember being so sore I could barely put my backpack on. Walking up the stairs to class on the third floor felt like scaling Mount Everest with a pack of monkeys punching my back. But it was a good kind of pain. My body was adjusting to a new normal; it was adapting and stabilizing; it was growing.

That’s the thing about discomfort: it leads to growth. You venture into the unknown, wrestle with the tension, and come out the other side a little bit stronger. Done repeatedly, growth compounds. And, as you mature, you respect the process of growth so much that you take more risks, seek out more tension, and expand your potential in new and novel ways.

I’ve tried countless exercises: strength training, high intensity interval training (HIIT), running, sprinting, biking, yoga, Pilates, core, cycling, rowing, boxing, jump rope. I apply principles to everything in life, so I naturally developed a system for exercise.

What is the core foundation of exercise and physical fitness?

Asking myself this while experimenting with different methods, I came to the conclusion that I need to work on three (surprise!) key areas of physical fitness:

1. Strength to build muscle centered on functional movements in training.
2. Endurance to improve my heart rate and conditioning levels at various speeds.
3. Mobility to condition my joints and flexibility to stay nimble as I age.

One of my favorite quips in the show Seinfeld is when Jerry responds to the wannabe-comedian Kenny Bania’s question about lifting weights:

Kenny: “You work out with weights?”

Jerry: “No, I don’t.”

Kenny: “You should!”

Jerry: “Why?”

Getting older, muscles matter to the extent they can make everyday life more comfortable. I don’t want to groan picking up my kid’s toys; or pull something every time we play outside; or not be able to walk when I’m much older. Balance is necessary to not over-index on one component to the exclusion of all others, like lifting weights and ignoring cardio and mobility. Being adaptable and responsive to life’s challenges requires a broad base of conditioning.

Can we apply this same line of thinking to products and building software? Absolutely.

The same tenets of conditioning—strength, endurance, and mobility—apply to building software. In order to create resilience in your product and team, you need the same principles as physical conditioning. The human body is a complex system riddled with unknowns, uncertainty, and integrated parts forming a coherent whole. Software, too, is a complex system with the same composition. If you focus on one aspect of your product or team without balancing the others, you risk creating fragility and undesirable outcomes.

This idea is called Product Conditioning, which lives in the Clarity Current of the Claritorium and Strategic Momentum of Equilio.

The three pillars are:

1. Stability through integration and the strength of strong foundations.
2. Cadence through iteration and matching the pace to the needs of the product.
3. Adaptability through intuition to stay nimble and strategic in your efforts.

Stability

Stability is the foundation everything builds from. This applies to both your team and product, which feed into one another. Great teams make great products, and you need a stable system to support and empower them.

When you think of stability, what words come to mind? Fixed? Rigid? Unchanging?

Stability is the state of being stable, which is defined as firmly established, fixed, steadfast, not changing or fluctuating, permanent, enduring. I want to highlight the words “firmly established” and “enduring” because they fit my definition of stability:

Stability is a firmly established, enduring foundational core.

I don’t think of stability as rigidity. I think of it as structural integrity. It’s not about stopping movement; it’s about allowing motion without risk of injury, like building strength in your muscles and core to make motion safe.

When you think about stability, apply it to:

1. The product you create.
2. The team who creates it.
3. The systems that drive both.

If great teams make great products—and great systems enable both—then we need to view each of the pillars of Product Conditioning through a holistic lens.

The product is the artifact.

The team is the human system.

The system is the operating environment.

Product Stability

Stability in a product isn’t about staying static or the absence of bugs. Every piece of software has bugs. It’s normal. A stable product provides a surface to push against.

A stable product has:

1. Clear interfaces that don’t make users guess, empowering them to use the product to solve problems.
2. Reliable integrations with external sources to seamlessly combine multiple data points into a coherent solution.
3. Predictable behavior under normal and stressed conditions so the product can be relied on for critical work.

These attributes are dynamic. They change over time because software changes over time. Every feature, fix, or improvement introduces changes that can make the interface more or less clear, the integrations more or less reliable, and the behavior more or less predictable. It’s a balance driven by a tension all work moves through.

Team Stability

Stability on your team is how everyone can stay focused on their work without distraction. There is a trust cultivated when everyone knows their role and does their part. And when someone is on vacation or indisposed, the rest of the team can pick up the workload without skipping a beat. Domain knowledge is dispersed evenly, skills are uniquely integrated, and teamwork thrives.

A stable team has:

1. Clear roles and ownership to create clear expectations across the team.
2. Shared language and mental models so everyone knows the landscape.
3. Collective trust so everyone is aware, capable, and willing to do great work.

The best teams I’ve worked on make every problem their own. They care deeply about the craft, and leave every area of the product they work on better than they found it. They work with high agency, high urgency, and high adaptability. Teams that think this way can weather anything.

System Stability

Stability in the system is about predictability to maintain forward progress. Building software is an uncertain endeavor. Technology changes rapidly as the market and economy shifts without warning or predictability.

A stable system has:

1. A clear way to make decisions and decisively move priorities forward.
2. A consistent process to track work and route tasks and assign priorities.
3. A deliberate method to reassess priorities without chaos and distraction.

Great systems support. They shouldn’t impede progress or risk negatively affecting the unique composition and emergent environment of the team. A system should be an enabler, an empower, a cultivator. System stability is where trust compounds.

Principles

1. Clarity over cleverness. A clear structure will always outperform over-engineered shortcuts. Clear interfaces map to user expectations.
2. Reliability over heroics. Stable teams don’t depend on acts of heroics because they know what’s expected of them and disperse their knowledge intentionally.
3. Durability over fragility. Like the bamboo, create systems that bend under pressure without breaking. An overly rigid system is a fragile one.

Practices

1. Harden the Interfaces: Regularly review the seams of your product. Document and simplify core user flows, add guardrails around integrations (timeouts, fallbacks), and reduce implicit behavior by making expectations explicit in the UI.
2. Anchor Ownership: Make responsibility visible. Assign a clear owner to all the meaningful areas of the product, make decision-making powers clear (distributed!), and actively spread domain knowledge through pairing, reviews, and walkthroughs.
3. Normalize the Operating Rhythm: Establish a predictable cycle for thinking about and delivering the work. Never over-index on planning, especially in the AI agent world of rapid prototyping and living in the real context. Make your rhythms clear and consistent.

Cadence

Cadence is the first element that emerges once stability exists. I’ve seen too many teams adopt a process, framework, or predetermined “playbook” only to discover it doesn’t work for them. If you don’t understand the unique nuances of your product and team, you can’t design an effective cadence. No off-the-shelf solution will ever be the silver bullet. You use it as a starting point to see what works, what doesn’t, and how to make it your own. Just because two-week sprints or six-week cycles worked at one company, it doesn’t mean it will work for you. There’s never a one-to-one comparison when thinking about the combination of teams and products.

I’ve used two-weeks sprints, then six-week cycles, and now I’m experimenting with a more fluid approach that maps to the current nature of the work. Context matters.

I ran a 5K this past weekend. As we were huddled together at the starting line, I talked to another runner in the race. It was their first 5K, but they recently ran a marathon. We talked about the differences in approaching and running each type of race. A 5K requires a steady pace from start to finish. A marathon, on the other hand, requires more strategic planning and alterations in your cadence throughout. Everyone approaches it differently; and that’s the point!

Don’t adopt a cadence without considering whether the rhythms actually match:

• The product’s maturity.
• The team’s capacity.
• The organizations toleration for change.

Product Cadence

The product cadence is the rate at which the product can meaningfully change. Early products learn fast, ship small, and adjust constantly. Mature products change more deliberately, protect existing value, and optimize more often than reinventing.

When we started making a lot of changes to our product, the stability shifted. One of my teammates suggested we look at rebuilding instead of making sweeping changes that highlight areas of instability. But here’s the thing: making a lot of changes in a working codebase will surface problems. You generate friction, identify the tension, and use that to build momentum. A rebuild will just introduce a new set of problems.

A healthy product cadence:

1. Matches the learning surface of the product and adjusts the cadence.
2. Avoids both thrash and stagnation to keep the product in the right balance.
3. Respects that not all changes are equal in cost or risk.

Team Cadence

The team cadence is the pace of work. While non-human entities—AI and AI agents—are now involved, the cadence of the team is still predicated on the human operators.

A team’s pace should be directly aligned with the expected output and cadence of the product cadence. They work together. You’ll know when you’re moving too fast or too slow. Too fast and you end up shipping work that tips the stability scales in the wrong direction; too slow and your product stagnates and limits adoption. High-intensity workouts don’t stay at the peak intensity the entire time. Periods of rest bring your heart rate down before the next round. It’s a balance.

A healthy team cadence:

1. Balances intensity with recovery to make sure, like physical conditioning, you don’t burn yourself out by running too hard without proper cool-down periods.
2. Leaves room for thinking, not just executing by empowering engineers with AI tools to think more deeply in order to execute more quickly.
3. Feels energizing, not draining by constantly shifting speeds without creating unnecessary distractions and cognitive overhead for the team.

System Cadence

The system cadence is the operating rhythm of the product and team: the organization. It’s how you plan, review, make decisions, communicate, and deliver the work. The system can support or undermine everything you do. A stable system makes cadence predictable, which makes the system feel alive. The cadence is like the current of electricity feeding the system the energy it needs to operate effectively.

A healthy system cadence:

1. Let’s work enter cleanly into a predictable and centralized environment.
2. Shows progress transparently so anyone can see where work stands.
3. Surfaces key decisions and unblocks them to keep work moving forward.

Principles

1. Pace over speed. Find a pace that’s sustainable and doesn’t burn you out.
2. Sustainability over intensity. Short bursts of speed need to be balanced.
3. Flow over control. If you try to control the process, you lose the natural flow.

Practices

1. Measure Time-to-Learning: Track how much time it takes to learn something meaningful after shipping. Focus on what you can learn to inform the next body of work. Don’t just build what’s on the roadmap blindly; respond to everything as value is delivered.
2. Set Explicit Pace Agreements: When you define the cadence, make sure the team agrees to it. Move forward with alignment. When you have the shared mental model, you can revisit it and adapt the pacing as necessary.
3. Align Planning Windows to Reality: If you’re learning a lot, then you need to work in shorter cycles. Allow for longer execution only when knowns are higher. But don’t paralyze yourself by getting stuck planning longer than is necessary.

Adaptability

Adaptability is the result of a stable foundation and a predictable cadence. It’s the end product that sets up your product, team, and systems for the most critical element: resilience. If you don’t have stability, then adaptability becomes chaos; if you don’t have cadence, then adaptability becomes noise. With both in place, adaptability is your strategic advantage, especially in a world with technology shifting so quickly with AI. Building software is under a radical transformation—one that can, if you let it, completely change how software is built and what it’s capable of doing. But it begins with staying adaptable.

Product Adaptability

A product’s adaptability stems from the ability to experiment without breaking things. You don’t want to constantly change the product without reason because then stability suffers. But you also don’t want to avoid changing for fear of breakage. Resilience emerges from growth, so sometimes you need to introduce the tension to make the product better.

An adaptable product:

• Changes key areas of the product without regressions to other areas.
• Can evolve without constant rewrites because the product can respond to it.
• Allows direction changes without eroding user trust in the product.

Team Adaptability

Team adaptability is about handling direction changes. Startups are highly volatile environments because they’re constantly shifting and pivoting as they learn. But the same mindset is beneficial in more stable environments. Even if you’re not fighting for every user, every dollar, every minute, you should still think like you are.

Assumptions are useful up until they are validated or invalidated. Once you learn, then you change and reorient your thinking. Adaptable teams don’t sweat it when they learn something different than they anticipated. They adapt, and move forward as a team.

Adaptable teams:

• Notice when assumptions are no longer valid and update their thinking.
• Shift focus without blame or defensiveness when priorities change.
• Treat change as information, not failure, and move forward.

Teams need psychological safety and shared context to stay adaptable to the inevitable changes working in layers of complex systems. In our team’s weekly meeting, I share all context, even when it doesn’t seem relevant. Transparency disseminates knowledge across the team, making it easier to stay adaptable as you work through uncertainty.

System Adaptability

System adaptability allows you to absorb new signals without breaking the system. Without the right level of adaptability, signals are lost in a sea of noise.

Adaptable systems:

• Can reprioritize without stopping everything because change is expected.
• Has clear mechanisms for incorporating new information in a seamless way.
• Makes space for judgement alongside process because intuition is critical.

For our team, everything flows into Linear. If it’s something we need to work on, it lives there. The system surfaces queued issues for each engineer. They know the priorities. And when the priorities change, they know what to expect in the system. It doesn’t fall apart because of a priority change.

We needed to focus on key changes in the anonymous-to-trial funnel. Instead of the usual resourcing ceremony, I just queued up issues for one engineer in Linear. They finished their project and shipped a set of small experiments. That’s adaptability.

Principles

1. Optionality over optimization. When you get caught in indecision or going too deep into unnecessary details, focus on leaving your options open. Don’t micro-optimize when you can get something in user’s hands and learn more.
2. Awareness over certainty. It’s all guesswork until you do the work. You can’t predict the unknowns, so your only choice is to be aware of information as it shows up. Watch carefully and pick up the signals.
3. Responsiveness over rigidity. Systems exist to support judgement, not replace it. When the information changes, so should your response. A rigid system protects a process and ignores the value. Responsiveness is the anecdote to rigidity.

Practices

1. Design for Reversible Decisions: When making decisions, it’s helpful to call out early how reversible the decision is. When the risk is high, tread carefully. But when the risk is low, take a chance. Build around reversible decisions.
2. Run Assumption Checks: Regularly surface and challenge assumptions. They are always there, lurking in the shadows. You have to be diligent about checking your assumptions. It’s a good practice to do this regularly in the work.
3. Create Intentional Slack: In order to identify the right decisions and spot assumptions, you need to create slack in the system to notice it. Build space for reviewing work, checking assumptions, and sensing signals to help you readjust.

The Throughline

To create resilient products, teams, and systems, you need to build strength, set a cadence, and stay adaptable.

Product Conditioning is like physical fitness.

Stability is like strength training to build muscle and increase your foundation.

Cadence is like endurance training to alter your pace and improve your sustainability.

Adaptability is like mobility training to build your tolerance for change and uncertainty.

Together, they condition your team, your product, and your systems for resiliency. You won’t feel threatened by new technologies or new competitors because you’re built for change. The biggest mistake you can make is to assume a fixed, rigid world. And you can’t expect to operate successfully with a fixed, rigid environment. You need conditioning to build resilience, growth, and momentum.