My role: economics and competition
Our team redesigned how Ruler turns new legal publications into client alerts: AI drafts each update, and a legal expert checks and approves it. My role was economics and competition. I started out as I do with every project by proposing the first division of roles and the structure of our working document. Afterwards, I wrote the disruption rationale, economics, pricing and value-capture, and defensibility and envelopment sections. Later during the creation of the slides I also helped with the business-model slide and the route choice, and made sure the course material was properly used. Looking back, setting up the plan was a strength, but keeping it together over time was not, which is where I learned most of the lessons stated below.
The key decision between Route A and B
The decision I learned most from was how the company should capture the time the AI saves. Route A banks it as lower editorial cost, while Route B spends the released hours on extra coverage that clients buy as add-ons. We first leaned towards B because we thought that reducing the hours consultants worked would create a moral hazard.
However, a teammate questioned that choice, and after discussing it we switched to A. Under A the AI pays for itself once it saves about 9% of preparation time, while B depended on whether clients wanted add-ons, of which the demand was untested. Of Session 2s 3 lenses, B passed desirability, but its viability was unproven. Route A was tangible, easier to explain and had the opportunity to be visually more appealing and understandable.
A brought its own problem: moral hazard. Adverse selection is about what one side hides before a deal: moral hazard is opportunistic behaviour after it (Dimoka et al., 2012). Once AI drafts are in place, the company cannot see whether the saved time really shows up as fewer billed hours, or if each draft is carefully checked. Saved time could turn into slack, and reviewers could rubber-stamp the AI’s output.
Borrowing the tracking-and-verification remedies from Session 7, we built in output per billed hour to expose slack and quality audits to catch rubber-stamping. I learned from choosing route A that problems like moral hazard can be managed and do not have to be a reason to avoid them. Additionally, the measurable option decides whose behaviour you must watch.
What backfired: the document grew too big
On the other hand, I also created an approach that backfired. I had proposed to write everything in one shared document first and turn it into slides later in order to use the document as a clear base. At first it worked fine, we had one central place to fall back on and an overview of the whole argument, but we were all working on different parts at once. As a result, the document changed constantly and sections started contradicting each other. We were still deciding the overall direction like the choice between the two different routes and parts that were finished late made it even harder. At one point the document ran past thirty pages.
In hindsight we should have made the slides our central document once the prototype worked, and started the evaluation there. With less text it would have been easier to keep the overview. The fact that many sections relied on each other made it hard to create a clear overview and direction. After we started with the presentation slides we cut a lot, making it much clearer. Most of my disruption rationale was cut, rightly I think, because it added little to the slides or the rest of the project. What I learned is to create a clear direction and that you need a clear document to help you with that when you are already too far gone it is sometimes better to start over using a clean slate rather than cleaning the previous one.
How evidence changed the work
The cost model shaped the evidence of my cost model the most. Tripling the token price moved the break-even only from 8.9%% to 9.4%, while one extra minute of expert review per package pushed it to about 10.6%. The real cost was the consultants checking time. Our success measure counted the total consultant time per package, review included, because that was the most costly. The limiting factor was that our test only covered 5 cases and there were few scenarios. This also became the reasoning as to why we decided to recommend a pilot before scaling. I learned that in an AI workflow, the cost to watch is the human check, not the model.
Working together
We all worked in parallel and reviewed each other’s sections. Everyone had a part in giving feedback, but each change triggered other changes, and consistency became hard to keep. The amount of feedback given differed too, some were more perfectionist, while others were satisfied sooner. I felt like everyone was very respectful in giving feedback and all responded to feedback accordingly, fixing it often quickly. But because some of us weren’t as concerned with getting the perfect score as others, I think we left some quality on the table.
Generally, we divided the tasks well, but nobody led or kept the overview. Next time I would agree that at the start we would need one owner of consistency and one place for all the numbers. This way we avoid losing control over our own document and it allows for more efficient teamwork.
How my view of AI and strategy changed
My biggest surprise about AI and strategy was how easy it is to build a working app with Lovable. Before the project I assumed an AI application required understanding of coding or tools like n8n, not that a few prompts in the right tool would do most of the work.
Session 1 named technology that lowers the cost of entering as a sign that a market is becoming newly easy to enter, that was also part of my cut disruption rationale. During the session I still was a little skeptical about the point Barney and Reeves (2024) make from the firm’s side: generative AI offers similar savings to every company, so value is created but not captured for long, and a proprietary AI platform can usually be imitated. I was skeptical because I thought creating the proprietary AI platform was somewhat difficult and time consuming for smaller firms. Often they do not have the time to focus on smaller gains from generative AI and I felt like they should rather keep focusing on their core functions. But the ease of creating our own prototype made me realize it does not take a lot of expertise or time, and even less technical managers can build such tools with the help of AI. That convinced me Barney and Reeves are right. If almost any firm can build the app, the app itself cannot be a lasting advantage. So the strategic value lies elsewhere, for example in the short-term saving, which is worth taking early because it will not last, and in the expertise of Ruler’s legal experts.
