Software Is the Least Static It Has Ever Been. Your CS Operating Model Was Built for a Different World.

Jason Lemkin closed SaaStr AI Annual 2026 with a framing that deserves more attention than a conference recap usually gets.

His thesis from the final-day deep dive AMA: software is the least static it has ever been.

The companies that showed up at SaaStr AI this year - as sponsors, speakers, and attendees - were disproportionately the ones that had figured out how to operate in a market where the tools, the models, and the competitive landscape change faster than annual planning cycles. The companies that did not figure this out were not there, because many of them are no longer growing.

That is not a product statement. It is an operating model statement.

The Konur Consulting take: SaaS CS and operations teams built their processes for a world where the product evolves on an annual release cycle and the competitive environment shifts on a multi-year horizon. That world is gone. The teams winning NRR in 2026 are not the ones with better tools - they are the ones that redesigned their operating cadence to match the speed of the market.

What "least static" means for the CS team running a renewal

Consider the specific problem a CS team faces in 2026 that did not exist in 2022.

The customer who signed in January is using a materially different product in July. Not because of a major version release they were briefed on and trained for. Because AI models update in weeks. Features ship continuously. The competitive landscape around the product shifts with every new model release and every acquisition announcement.

The CS team is running a quarterly QBR cycle. The health score refreshes monthly. The renewal motion starts 60 days before contract end. The operating cadence was designed for a market where significant change happened on an annual or longer horizon.

In a market where software is least static, that cadence is slow motion. The customer's understanding of the product - its current capabilities, its current competitive position, its current pricing model - is potentially several months behind reality by the time the QBR happens. The renewal conversation is starting from a gap.

The teams that closed this gap did not do it by adding more people to the CS function. They did it by redesigning the cadence. More frequent lightweight touchpoints instead of quarterly deep dives. Health score inputs that update on a shorter cycle and include signal from product usage patterns, not just relationship metrics. Renewal conversations that start 90-120 days out - not 60 - to give time to rebuild the customer's picture of the product before the commercial discussion begins.

The QBR problem is a measurement problem

The traditional QBR is designed around a stable product. You review what the customer has done with the product over the quarter, confirm it is delivering value, and set goals for the next quarter. That structure assumes the product the customer was using at the start of the quarter is substantially the same as the product at the end of it.

When software is least static, that assumption fails. The product has changed. New capabilities are available that the customer may not know about. Capabilities the customer relied on may have been modified. The competitive context for the product's value proposition may have shifted because of announcements the customer read but did not fully process.

A QBR that reviews past usage without addressing current product state and current competitive context is answering the wrong question. It is telling the customer what they got from a product that may no longer exist in exactly the form they got it.

The teams redesigning the QBR for a least-static environment are building a different structure. The first part of the QBR covers current product state - what is new, what changed, what the customer should be doing differently than they were 90 days ago. The second part covers value delivered. The third part covers the renewal and expansion opportunity given the current state of the product and the customer's current priorities.

That is a fundamentally different conversation than the standard QBR, and it requires CS leaders to have a current, not historical, picture of the product at all times.

The health score problem is a signal problem

Most SaaS health scores are built on lagging indicators: logins over the last 30 days, feature adoption over the last quarter, support ticket volume, NPS from the last survey.

Lagging indicators tell you where the customer was. In a least-static market, what you need is where the customer is going.

The signal inputs that matter in 2026 are different from the ones that powered health scores in 2022. Product adoption of the most recently released capabilities - not just overall feature depth - tells you whether the customer is keeping pace with the product or falling behind it. Executive sponsor engagement frequency tells you whether the relationship is going up or down the org chart. Competitive mentions in customer interactions tell you whether the customer's internal evaluation of the product is being influenced by alternatives they are actively looking at.

None of those signals require new technology to collect. They require a decision to collect them and a review cadence short enough to act on them before the renewal conversation starts.

The renewal motion problem is a timing problem

The 60-day renewal motion was designed for a world where the customer's decision was essentially made by the time the CS team initiated the commercial conversation. The last 60 days were for closing, not for influencing.

In a market where software is least static, 60 days is not enough runway to change a customer's assessment of the product. If the customer has formed a view - accurate or not - about the product's current capabilities, current competitive position, and current value relative to alternatives, 60 days is not enough time to correct a misperception, demonstrate a new capability, or rebuild an executive relationship that has drifted.

The teams winning renewals in this environment are starting the renewal motion at 90-120 days. Not to rush the commercial conversation, but to create the runway to do the operating work before it. Confirming the customer's current picture of the product. Identifying where that picture is out of date. Getting new capabilities in front of the right people before the commercial pressure creates a defensive posture.

What to do Monday

Start by auditing the lag in your current operating model. How old is your health score data by the time a CSM acts on it? How many weeks between a significant product change and the moment the relevant customer accounts are informed? How many days before renewal does your CS team typically initiate the commercial conversation?

For most SaaS CS organizations, the honest answer to all three questions will reveal a significant gap between the speed of the market and the speed of the operating model. That gap is where renewals are being lost - not to competitors, and not because the product failed, but because the customer's mental model of the product drifted and the CS team did not close the gap before the renewal conversation started.

FAQ

Is this only relevant for companies whose products are changing rapidly?

No. Even if your core product is relatively stable, the competitive environment around it is not. The customer's reference point - what alternatives exist, what AI-native tools are emerging, what they read about your category - is shifting whether or not your product roadmap is moving fast. The operating cadence needs to account for the speed of the customer's market context, not just the speed of your product releases.

What if our CS team does not have enough bandwidth to run shorter-cycle touchpoints?

The least-static operating model does not require more touchpoints - it requires different ones. Shorter, more focused check-ins on specific product updates replace longer, broader QBRs. The goal is not more contact hours but faster signal-to-action cycles. Most CS teams can redesign the touchpoint structure without adding headcount if the motion is designed correctly.

How do you update a health score more frequently without creating noise?

The answer is choosing the right inputs. High-frequency signals - daily active usage, support interaction sentiment, competitive mention tracking - can update a health score continuously without manual effort if the data collection is automated. The lagging indicators that require manual input (NPS surveys, QBR outcomes) are the ones that slow down the refresh cycle. Shifting weight toward automated signals makes the score fresher without increasing CSM workload.

The operating cadence that worked when software was stable is a liability when software is least static. The teams that redesigned for the speed of the current market will hold NRR. The teams that did not will discover the gap in the next renewal cycle.

Konur Consulting helps SaaS CS organizations redesign their operating model for a market that moves faster than annual planning cycles - from QBR structure to health score redesign to renewal motion timing. Reach out at info@konurconsulting.com.

---

Source - SaaStr closing AMA thesis: Jason Lemkin, "We Closed Out SaaStr AI 2026 with Our Deep Dive AMA, and the Theme This Year: Software Is the Least Static It Has Ever Been," SaaStr, July 8, 2026. saastr.com

Source - ICONIQ corroboration: ICONIQ Growth, "2026 State of AI: The Builder's Economy," July 2026. High-growth companies stand up new AI tools in 2.5 months vs. 3.5 for typical companies - the speed differential that makes the least-static operating model necessary. iconiq.com/growth/reports/state-of-ai-2026