The target audience. SME regularly deploying software products.

Simple is Feasible

Think about it. Everything revolves around a “Product”. Business/Industry/Investors, all actors think in terms of Products. Not Software, Architectural or some other artifacts. After Business decided they know WHY do the need it, product owners and business analyst are iterating to define WHAT business wants. Just then it is feasible to deploy the consistent plan to the Technology people, to decide HOW will it be done. The better information they have the less time they will spend iterating to “understand the thing”. Better means detailed, articulated, with requirements managed and clarified. No ambiguities.

The image above is an product development Operational Model, inside an (well behaved and organized) company; AI based. Company that has adopted and implemented the BPT Operating Model and has learned how to use an LLM, and how not to. Crucially under the guidance of the “BPT Method”.

Operating model applied

Note: DBJ BPT is not a “Product Driven Development” (PDE). DBJ BPT is (much) wider in scope. PDE is firmly in the Technology domain. BPT is organization operational model. It changes the whole organization.

Notice the three domains, each iterating with the next, to produce two main artifact goal.md and the plan.md . Iterations can produce more but these are two main two.

  1. chat.md — freeform exploration. Confusion belongs here. Where the organization stake holders find out what do they not understand. WHY do they want the Product.
    1. Very often it is iterated only over between “Business” and the “Product”
  2. goal.md — the distilled goal statement artifact. Architecture gets involved. Iterating between Business and Product teams, the public deliverable, signed and staying
    1. Now note the Exceptions. Note the optional cascading and the overall effect.
      1. BPT Exceptions are “all hands” events carrying the full trace: where it happened, and what has happened
        1. BPT Exception is caught by the domain where it originated from. Because non Engineering roles missed the problem that caused the Exception being thrown “down the line”.
          1. That is BPT Agility, inbuilt backtracking events
    2. Exception are operating model mechanisms.
    3. Carrying the information used to discover and solve the cause.
      1. To notice and rectify the expensive mistakes, on the level of organization, not inside the Technology domain which has no view into the domains that cause the Sequence of Event that led to a Exception.
  3. plan.md — the concrete implementation plan, made by roles in the Product team. Business Analyst being the important role.
    1. Steps, dependencies, order. Iterating between Product and Technology team until it is agreed.
      1. At this stage Product team has the visibility of the goal.md and can go back to Business to reconfirm the decisions or to provoke the goal.md revisiting.

Problems in Production

After seeing the product release in production, someone can say: “This is not what I wanted”. Usually those are “stake holders”. Roles in Business or Product domain.

At that moment (or reckoning), following the operating model. Engineering people “throw” (perhaps send mail) the BPT Exception document, out of the Technology domain back to the Product domain. Full information on the “Product” (previous) in the Product domain is available, as it was the in the last formal request to develop and deliver. Next, Product then decides can it solve it, if not it rethrows the Exception (send mail again) back to the Business team.

the Issue Origin will be found

  1. Important BPT Model feature: each technology product review activity will be able to “throw” the Exception back to the Product domain.
  2. Eventually arriving to the Business, if Product demands.
    1. Business is the top accountable domain.
  3. Exception cascading is propagating with the full trace back, all the way to the business decisions and the product team decisions.
  4. This is very powerful capability of the BPT OP Model: going back to the real source of an issue.
    1. the “Issue Origin” is most often outside of the confines of the technology.

This is not “tooling”

What is critical is that domain Business and Product are able to “send back” fully articulated product item declaration and requirements artifacts referenced. That is very malleable for a mature AI development where the “software factory” is given a goal and a plan, not a wish. That is not a organization, following the prompt and pray, ai-anti-pattern.

Please note what this is not. It is not a tooling standard. It is not a LLM recommendation or choice. BPT model defines domains, named artifacts, and roles ownership at each step.

With a internal backtrace loop made possible by the Exception feature — made visible at the level of the organization owning the final outcome.

And the outcome is the Product. Hence the “Product Factory” name, often describing the internals of the Technology domain.

There are various kinds of Products. Change the artifacts structure and the same Operating Model governs procurement, law office, insurance claims, etc. Not just internal or public software products.

Alternative: Prompt and Pray

Market pressure is tremendous. After one or more failed AI demo, a clear and colossal mistake is very visible. Someone opens a chat window, types “just build the thing,” and “prays”. Expecting the stories are true: finished and working software product arrives.(hint: It never will)

alt text

No defined input. No way to separate success from failure. The model produces something. Nobody can say whether it is correct, because there is nobody who can say what correct means. When it fails, the finding is “the AI model was not good enough,” which was never the actual cause.

This is not an AI problem. It is a legacy process undefined, just running faster. THat is organization with no operating model.

Why do we care

At least half of the organizations currently in AI post-pilot “zero ROI” mode are following the “Prompt and pray” strategy. There are licenses for tokens to spend, the AI team. They ran the pilot, no KPI of the outcome.

Pilot is declared a success, and it is scaled out — spreading the anti-pattern on the company level. Costs we have seen can be catastrophical.

The Summary

BPT information flow is two iterations between the three domains. BPT is not a sequence, it is a loop: the two artifacts are not a waterfall sequence. Namely goal.md and plan.md are the artifacts produced by updating as a result of iterating between domains. And each carries a named roles and origin information across a boundary. To be used by Exception throwing and by Exception solving.

goal.md and plan.md are boundary artifacts; each carries forward the information developed between two adjacent domains.

Scalability. BPT scales. An organization can run these three domains separately, for a product needing one developer and one feature; equally sensibly as for a whole business unit or a transformation programme. BPT Loops are multiple and running in parallel. It all depends on the size and complexity of the organization.

Product Maintenance is the most expensive stage of the product lifecycle. BPT loop, categorizes and saves crucial information for the maintenance stage.

It is very easy to restart the paused loop. There are artifacts and information needed.

If you want to know whether an organization is AI-ready, do not audit the tooling. Watch someone use it. If there is no visible op model, you are looking at the problem.

 

CAVEAT: That is true albeit simplified, DBJ BPT implementation, made by AI Practitioners. Generally other organizations jump straight into engineering. All find themselves with slightly different agentic harnesses, or no harnesses, or even no software products portfolio. Most have product quarterly plans, heavy JIRA managed procedures, etc.

The point is they all need adopt an operating model, before failing again.

 

Vocabulary

  • BPT — Business Process Transformation. In the DBJ Method it is an operational model: how the organization actually runs. Defined processes, named artifacts, clear decision rights, ownership, governed data. See The Three Domains.
  • Operational model — the description of how an organization does its work day to day. Distinct from the business model, which is what it sells and to whom.
  • Post-pilot mode — the state after an AI pilot has been declared a success and rollout has been funded, but before anyone has checked whether the process that made the pilot work survives being scaled.
  • BPT Exception — an event thrown by a role when the work received does not match what was asked for. It carries the full trace back to the domain where the cause originated, so the fix happens there, not where the symptom appeared.
  • Anti-pattern — a common response to a recurring problem that is usually ineffective and often counterproductive.