Same method, different domain: the BD engine

APD/M is not only for shipping product features. Studio operations are a product too.

Our BD engine is APD/M pointed at a different domain: find real businesses, understand them deeply, build something concrete, then talk.

The pipeline

At a high level:

1. Research and score leads

2. Deep-dive audit

3. Spec

4. Prebuild (real software, not a mockup deck)

5. Pitch with evidence

Agents own a large share of research, structuring, and build prep. Humans own the gates that change economic and ethical reality: whether the audit is good enough, whether the spec is right, what to charge, whether to walk away.

We encode that as explicit approvals. Agents do not self-stamp audit_ok or spec_ok. That is the same philosophy as a human deploy gate on a product squad: speed underneath, accountability on the irreversible steps.

Why this is the same method

The APD/M System and the BD engine share the same DNA. Domain differs: live product health and shipping versus a pipeline of opportunities. Context differs: board, repo, and metrics versus leads, audits, specs, and prebuilds. Roles differ: orchestrator and specialists versus BD with handoffs to dev and ops. Gates differ: human ship versus human audit, spec, and close.

Different skills. Same bones.

What load-bearing looks like

The pipeline is real software and real process. Jobs, skills, templates, and dashboards move work without waiting for someone to open a blank chat. Pursuit runs on our schedule with human gates on stage flips. That is production ops.

Why we write about it

Because the point of APD/M as a pattern is transfer. If the method only worked for one product vertical, it would be a case study. If it works for product squads and for studio BD, it is a practice.

We build agentic ops machines. Some of them ship product. Some of them fill the top of the funnel. Same discipline. The BD engine is studio ops DNA, not a public service SKU.