There is a certain way in which technology traditionally arrives inside large law firms. One might almost call it ceremonial.
A partner notices some recurring inconvenience—documents moving about with excessive ceremony, information that seems to vanish precisely when needed, the peculiar sensation that everyone in the room is performing the same small intellectual task again and again. The observation is expressed politely, often over coffee or during the quiet minutes following a meeting.
The idea begins its journey.
It travels through committees, slides gently across technology departments, acquires documentation, occasionally a vendor presentation. One hears phrases such as *requirements gathering* and *stakeholder alignment*. Time passes in a manner both stately and faintly mysterious.
Months later—sometimes longer—a piece of software appears. It is admirably engineered, carefully secured, and occasionally bears only a passing resemblance to the original thought that inspired it.
No one is surprised.
Law firms are cautious places, and understandably so. They operate under conditions that might make even the most confident technologist adopt a slightly conservative posture: client confidentiality, professional risk, regulatory obligations, and institutional systems of impressive complexity.
To build anything within such an environment requires deference to a number of invisible structures.
There are security boundaries, ensuring that one client’s affairs never brush accidentally against another’s. There are risk considerations, the quiet guardians of professional responsibility. There are existing systems—repositories where documents live, platforms where matters are recorded, channels through which communications drift and settle.
All of this forms the quiet architecture within which legal work unfolds.
And yet, rather intriguingly, a small change has begun to occur.
In certain corners of the modern law firm, one now encounters a rather unusual phenomenon: the product manager who can produce a working software prototype.
One now encounters a rather unusual phenomenon: the product manager who can produce a working software prototype.
What once required weeks of engineering coordination can now, in certain circumstances, be explored before the afternoon has entirely disappeared.
This has had an unexpected effect on the role of the product manager.
Traditionally, the product manager has lived in the narrow territory between two languages. Lawyers speak in the vocabulary of practice; technologists speak in the vocabulary of systems. The product manager translates, occasionally with great elegance, occasionally with the faint exhaustion of someone mediating between two spirited dinner guests.
But translation, as every reader of legal technology knows, is a delicate enterprise. Somewhere between one language and the other, meaning tends to wander.
A product manager can now begin with something slightly more ambitious than a list of features. They can begin with a framework—a structured representation of how work actually occurs inside the firm.
Any workflow tool in a law firm, after all, must quietly acknowledge the institution’s underlying grammar.
Security must be respected.
Risk must be accommodated.
Existing systems must be acknowledged with the diplomatic courtesy one extends to long-established residents.
These are not glamorous considerations, but they are decisive ones. A clever interface that ignores them tends to have a brief and unhappy life.
The modern product manager therefore begins by sketching the structural ingredients required for the environment to function: how information flows, where boundaries exist, which systems must be consulted, what forms of institutional caution must be observed.
Once this framework exists, the AI development tools perform their rather agreeable magic.
Interfaces appear. Data structures assemble themselves. A skeletal workflow emerges. Within a surprisingly short period of time, the product manager has something that can be seen, touched, and gently criticized.
This is the essential moment.
Instead of discussing hypothetical systems in conference rooms—an activity that rarely inspires the imagination—partners and technologists can interact with the idea itself. They observe how information moves through the prototype. They see how the institutional constraints have been quietly embedded within the design.
The conversation becomes concrete.
Ideas evolve more rapidly when they are visible.
Only later, once the concept has demonstrated a certain promise, do the technology teams perform the work at which they excel: transforming the prototype into a reliable system. Security is fortified. Integrations are formalized. Infrastructure is made appropriately serious.
Product managers embedded within the practice of law—people who understand the peculiar choreography of institutional work—can now express their insights as software prototypes with surprising speed.
They are, in effect, becoming architects of workflows.
Their real skill lies not in coding but in perception: the ability to see how a complex professional environment actually functions, and to render that understanding into a structured system.
For institutions historically cautious about innovation—not because they lack ideas but because experimentation has been expensive—this is rather liberating.
Ideas can be tested earlier.
Mistakes can be made cheaply.
Possibilities can be explored before they acquire committees.
And over time, one suspects, the law firm may discover that some of its most interesting technological innovations originate not in distant software companies but among the product thinkers already embedded within its walls—people who understand both the elegance and the eccentricities of the institution itself.
AI, one might say, has simply given them a quicker pencil.
