The Work BeginsAfter the Demo.

What Stayed with Me from September 5

The conversation moved between legal services, manufacturing and an internet company serving overseas markets. People described tools they had built, then others asked how employees used them, how permissions worked, and why customers would keep paying. Those questions made the distance between a working demo and everyday use easier to see.

There were different instincts about where to begin. Some argued for a shared foundation across the company; others started with a small problem a customer already wanted solved. A discussion of paper records and OCR raised another question: how much of the existing routine needs to change? I came away wanting to understand the conditions behind each approach before borrowing it.

Follow One Piece of Work

I want to begin with a business goal, then follow one piece of work from start to finish. What comes in? What must come out? Who owns each step, and where does it wait? A single transaction can make the gaps between departments, tools, and expectations much easier to see.

This takes patience. Before deciding where AI belongs, I need to understand how the work gets done today, including the informal steps people rely on to keep it moving.

One speaker suggested starting with an order and asking people to demonstrate each handoff. Another described a law firm that wanted help preparing tender documents because the repetitive work was driving staff away. That example reminds me to ask why a request matters. A task that looks unremarkable from the outside may carry a real problem for the people doing it.

Find What Holds the Outcome Back

A faster step is useful when it changes the result. If a task takes half the time but the same queue still determines delivery, the overall improvement may be small. I want to ask which constraint actually limits speed, quality, or capacity.

That also changes how I think about validation. The question is whether the business outcome improves in use. Time saved inside a tool is one piece of evidence; what happens to the surrounding workflow matters too.

A manufacturing example made this tangible. The speakers described a demo that assembled company knowledge into a draft design-for-manufacturing assessment for experienced staff to revise. Preparing that assessment depended on a small number of experts. Faster quotations and more orders were possibilities they hoped to unlock. I would still want to see what happened to review time, errors and the complete quotation cycle before calling it a business improvement.

Start Small, Keep the Whole in View

A focused pilot feels like a sensible way to learn, provided the whole workflow stays in view. The first slice should be small enough to deliver and specific enough to judge. It should also teach us something that helps with the next slice.

Shared data, business rules, tools, and knowledge can grow from what proves useful. I like the discipline in that sequence: solve a concrete problem, examine the result, then decide what deserves to become a shared capability.

Understand How the Business Works

The discussion of business context and Ontology brought up objects, relationships, roles, actions and workflows. Someone asked what happens when sales and finance use the same word, ‘customer’, differently. Collecting more documents will not settle that difference on its own. The people who use those definitions need to help make them explicit.

For my own practice, I want to start with one decision: which facts does it depend on, who can make it, what action follows, and what changes its status? Existing code and database structures can help me form a first understanding. When someone corrects that understanding, I want to keep the reason as well as the revised model. That is where I expect to learn how the business actually works.

Give Responsibility a Place

The design needs to say what AI may do, which decisions need a person’s approval, and who takes over when something goes wrong. Without those answers, even a working system can leave people unsure whether they should trust it or use it.

Adoption also needs a practical benefit for the people doing the work. If they gain time, clarity, or fewer repeated tasks, there is a reason to return and offer feedback. I want to treat that everyday experience as part of delivery.

A participant from manufacturing described colleagues who were reluctant to use an internal AI tool: they worried about replacement, privacy and having to check the output anyway. Elsewhere, a question about token usage exposed how easily effort can be confused with results. An experienced person may finish with fewer attempts. I want to understand what makes someone’s work better, including whether the tool leaves them with more checking to do.

Stay After the Demo

My understanding of FDE is becoming more concrete: discover the problem, explain its value, build something that works, handle exceptions, and check the result. Business understanding has to survive the passage into engineering and everyday use.

A demo is an early test of that understanding. What interests me is staying close enough afterwards to learn where it breaks, what people actually need, and whether the change helps. That is a capability I want to develop through practice.

The proposed meeting workflow—prepare information before the meeting, let people decide, then follow execution and review the result—gave me a useful way to think about that responsibility. I would need to make each handoff concrete: an owner, permission to act, a definition of done, and a way to recover when execution fails. Following the result back to the original decision is the part I most want to learn to build.

Earn the Next Project, and the Next Renewal

Reusable templates, tools, and experience can lower the cost of the next delivery. Ongoing revenue asks a separate question: what will keep being valuable to the customer after the initial work is done? Maintenance, updates, and optimization may provide an answer, but that value has to remain visible.

I want to keep both questions in view. One asks how to do good work again with less repeated effort. The other asks why someone would keep paying for it. Each needs its own evidence.

This distinction surfaced in a question from a practitioner whose revenue felt as though it started from zero every year. The reply focused on reusing knowledge and components. I found the gap between the question and the answer useful: reusable delivery can improve the service business, while a renewal still needs a reason that matters to the existing customer.

What I Want to Practise Next

For my next customer conversation, I want to ask for one ordinary transaction and one that needed rework. I will trace the input, output, owner and waiting points, then choose one small step whose outcome we can actually judge.

I also want to test my prototypes with a changed input, a missing fact and an exception. Can I explain the result, locate the failure, and put it right? Keeping the original business description, my first interpretation and the corrections together should make that learning easier to revisit.

These are things I want to practise, and I still have a lot to learn about doing them well. The day gave me a clearer way to judge my progress: whether I can take responsibility for one small piece of work, see it through use, and explain what changed.