For a long time, technology was a real differentiator.

Whoever could afford a big Oracle database, big servers, serious infrastructure and the teams to run all of it had a genuine competitive advantage. The price of entry was high. The technology itself was part of the moat.

Then the cloud arrived.

With AWS, Google Cloud, Azure and the rest, the same technological building blocks became available to everyone. You no longer needed to invest heavily upfront: you could rent on demand. You no longer needed to already be big to equip yourself like a big player.

The result: technology has largely become a commodity.

Of course, gaps in execution still exist. Some build better than others. Some operate better, secure better, architect better. But simply having "the technology" is no longer, on its own, a lasting differentiator.

And with AI, we're about to cross another threshold.

We'll be able to produce faster:

• more features,
• more screens,
• more variants,
• more content,
• more code.

The cost of producing software will keep falling. And so the number of players able to attack a market will keep rising.

But if everyone can build fast and well, then building fast and well is no longer enough.

Churning out features by the yard will no longer be an advantage. It will just be table stakes.

That's why I'm increasingly convinced that, for software vendors, the real differentiator is going to shift somewhere else: toward understanding the context.

What will matter is understanding before building

When technology becomes a commodity, and when production capacity becomes abundant, scarcity moves.

It's no longer in the "doing." It's in the "understanding."

Understanding the context isn't just listening to two customers, running three interviews and writing a scoping note. It's understanding, in depth, everything that surrounds a product opportunity.

For example:

• the business,
• the users,
• the customers,
• the technical constraints,
• the standards,
• the culture on the ground,
• the competition.

Put differently: the best vendors won't win because they produce more. They'll win because they understand better.

Understanding the business, for real

Many software teams still build features without understanding:

• the customer's business model,
• their trade-offs,
• their margins,
• their operational constraints,
• their real priorities,
• and their culture.

And this cultural dimension is far from secondary. It's often decisive, particularly in:

• large groups,
• international companies,
• certain highly codified verticals.

Two companies can have the same apparent need on paper and actually expect two very different things, simply because they don't share:

• the same decision-making culture,
• the same relationship to risk,
• the same degree of centralization,
• the same relationship between headquarters and the field,
• the same expectation of standardization.

When you don't understand this, you can build something perfectly fine… but beside the point.

In a world where everyone will be able to build, the real question will no longer be: "can we develop this feature?" but rather: "do we understand the situation well enough to build the right thing?"

Understanding the users, not the imaginary users

There's often a gulf between the user you imagine in a workshop and the one who actually works on the ground.

What you need to understand is:

• their constraints,
• their habits,
• their shortcuts,
• their resistances,
• their mental load,
• their workarounds.

With AI, we'll be able to generate interfaces very quickly. But quickly generating a bad answer to a real problem is still… a bad answer.

So the difference will come down to the quality of understanding:

• do we know how people actually work?
• do we understand what they tolerate, what they reject, what they don't dare say?
• do we grasp the differences by role, by sector, by digital maturity, or by company size?

Understanding the customer, not just the user

In B2B, the customer isn't just "the user."

The customer is often also:

• the one who pays,
• the one who arbitrates,
• the one who champions the project,
• the one who has to reassure their management,
• the one who's afraid of risk,
• the one who wonders whether the rollout will be manageable.

A product can:

• be loved by users and still not sell,
• solve a real problem and still get blocked at purchase time,
• be good, but incompatible with the organization's decision criteria.

Here again, understanding the context becomes central.

Understanding the technical side, but differently

Saying that technology is no longer the main differentiator doesn't mean it no longer matters.

It still matters, but differently.

What will make the difference isn't just having access to the right stack. It's understanding what it is reasonable, robust and sustainable to build in a given context.

With AI, we'll be able to produce more code. But we won't automatically get:

• more architectural coherence,
• more reliability,
• more security,
• or better integrations.

So the question becomes less "can we code this?" than:

• can we integrate it cleanly?
• can we maintain it?
• can we secure it?
• can we make it hold up in the real world?

Understanding the competition, the weak signals, the blind spots

The other trap is thinking about your product in a vacuum.

The market moves while you build. Competitors change, expectations shift, some usages become standard, others disappear, new entrants show up faster than before.

With AI, this pressure will increase further. More players will be capable of launching something credible.

So you'll need to understand:

• what competitors are doing,
• what they promise,
• what they can't do,
• where the market is standardizing,
• where genuine blind spots still remain.

Standards, regulation, traceability: an increasingly central topic

I also think we still underestimate just how much value the regulatory and normative context is going to take on in the years to come.

We often think of:

• ISO standards,
• industry frameworks,
• audit requirements,
• cybersecurity,
• data protection,
• sector compliance.

But there's also a whole very concrete, very ground-level layer that's becoming more and more important:

• traceability,
• archiving,
• standardization,
• data comparability,
• justifying discrepancies,
• readability for finance or controlling.

Very often, this shows up as plain, simple sentences:

• "the financial controller is asking me for this,"
• "we need to be able to justify this figure,"
• "we need to trace who did what, when, and why,"
• "it has to be comparable across sites,"
• "we need data that's usable for the audit."

In other words, it's no longer just about building a useful tool. You also have to build a tool that:

• leaves a trail,
• structures the information,
• makes decisions legible,
• holds up against an audit logic,
• holds up against a steering logic,
• holds up against a standardization logic.

And that isn't just technical. It's a fine-grained understanding of the customer's context.

What will gain value: the context document

Concretely, I think one of the deliverables that will gain the most value in the years ahead isn't just the spec, or even the roadmap.

It will be a real context document for a given opportunity.

A document that forces you to spell out, in black and white:

• the business context,
• the product context,
• the customer context,
• the user context,
• the technical context,
• the business rules,
• the standards and regulation,
• the culture and practices on the ground,
• the competition and the alternatives,
• the history and the decisions already made.

And a good context document isn't there just to pile up facts. It's also there to distinguish:

• what I know,
• what I believe,
• what makes me doubt,
• what goes unsaid.

Because tomorrow, when producing becomes easier for everyone, what will have value won't just be the ability to ship a solution.

It will be the ability to:

• frame the problem correctly,
• document the context,
• surface the areas of risk,
• align the team on a deeper understanding of the opportunity.

In fact, this context document almost becomes a strategic asset.

Fundamentally, the competitive edge is shifting

I believe we're entering a period in which the competitive advantage of software vendors is going to shift very clearly.

Yesterday, it lay largely in access to technology. Today, it's already less there. Tomorrow, with AI, it will lie even less in production itself.

The real advantage will lie in the quality of understanding.

Understanding better than others:

• the business,
• the users,
• the customers,
• the technical constraints,
• the standards,
• the culture on the ground,
• the competition,
• and all the weak signals that change the very nature of an opportunity.

When everyone can build, the winner isn't the one who produces the most.

It's the one who best understands what to build, for whom, in what environment, under what constraints, and to create what value.

A concrete example

• 00-context.md

**Status** : Draft / In review / Validated
**Owner** : PM
**Last updated** : YYYY-MM-DD

# Context

## Business context
_What are the business stakes behind this topic? Why does it exist? What known business constraints? Does this opportunity work for our business model, our go-to-market, our strategy?_
_(→ business viability risk)_



## Product context
_How does it work today? What are the current limits? What has already been tried or considered?_



## Customer context
_Who is the customer (the one who pays, who decides on the purchase)? What are their stakes, their decision criteria, their constraints? What motivates or blocks the purchase? Does this topic address a need the customer is willing to pay for?_
_(→ value risk on the buyer side)_



## User context
_Who uses the product day to day? What usages today? What known pain points? Will the user understand and adopt the solution? Any differences across segments or roles?_
_(→ value risk + usability risk)_



## Technical context
_Technical elements worth knowing? Can we build what we're envisioning with our skills, our stack and our timelines? Data or tracking constraints? Significant dependencies?_
_(→ feasibility risk)_



## Business rules
_What business rules already exist in our CMMS on this topic? How do our customers handle this today in their processes? Logics of validation, calculation, permissions, workflow already in place?_



## Standards and regulation
_What standards (ISO, EN, NF…) or regulatory obligations apply? What impacts on what we can or must build? Any traceability, compliance or audit requirements?_



## Culture and field practices
_How do the field teams actually work? What habits by sector (industry, services, healthcare…) or company size? What perceptions, resistances or specific expectations to take into account?_



## Competition and current alternatives
_How do customers solve this problem today? Which competitor, which in-house tool, which manual process (Excel, paper…)? What works or doesn't work in these alternatives?_



## History and decisions
_Decisions already made on this topic? Useful historical trade-offs? Elements not to reopen without reason?_

To go further

The PM as Architect of Context Competitive intelligence: copying your competitors is not a strategy AI Wiki: why I built a knowledge base maintained by an AI