Fractional AI Product Manager · Houston, TX

Hire an AI product manager in Houston.

Shell and Halliburton have built AI prototypes that operations leadership does not use. Baker Hughes has a predictive maintenance model that engineering built without input from the field technicians who were supposed to benefit from it.

The prototype works technically. The adoption is zero. That is a product problem. The UX was designed by engineers who never spent a day in the field workflow they were trying to improve.

The AI PM's job is to go to the field, understand what operators actually do, and rewrite the spec to match that workflow. The engagement runs 8–12 weeks at a fixed price scoped to the engagement.

How we work

Tell us about the AI product that is not getting adopted.

When adoption fails and it is a product problem, not a technology problem.

HCA Healthcare's digital health team has vendor-built AI features that clinical staff ignore. The features passed the vendor demo. They failed in the workflow because nobody defined clinical integration requirements before the vendor built them. The alert fires at a point in the workflow where the clinician has already moved past the decision it was meant to support.

In energy, a predictive maintenance feature at a Houston offshore operator alerts field technicians to equipment anomalies. The alerts are correct. Technicians ignore them because the maintenance scheduling system does not surface the same information, and technicians trust the scheduling system they have used for ten years over a new alert they do not understand.

Both failures follow the same pattern. Engineering built to the data they had and the requirements a non-operator stakeholder specified. The people who were supposed to use the feature were consulted once, in a requirements meeting where they did not feel safe saying the design was wrong.

Field workflow discovery surfaces what that requirements meeting missed. We spend five to seven days in the actual workflow: structured interviews with four to six operators, a process walk following one real transaction from start to finish, and a friction inventory cataloging every place the workflow breaks or requires workarounds. The spec rewrite starts from what we find, not from what the engineering team assumed.

The field workflow discovery process.

Structured operator interviews

Four to six people who do the actual work, not their managers. Recorded with permission, verbatim notes. We ask what they do when the current system gives them a wrong answer, not what the policy says they should do.

Process walk from start to finish

We follow one real transaction or procedure through every step, tool, and decision point. We note every workaround, every step that requires tribal knowledge, and every place the documented process diverges from the actual process.

Friction inventory

A catalog of every point where the current workflow breaks, slows down, or fails for edge cases. Each friction item gets a severity rating and a frequency estimate. The AI feature should address high-severity, high-frequency frictions first.

Workflow diagram with design annotations

The output is a diagram showing where the AI feature was designed to fit versus where the actual workflow creates the opening for automation. Engineering reviews this before any spec rewrite begins.

What the spec rewrite looks like.

Workflow integration points defined explicitly

The spec states the exact step in the operator workflow where the AI output surfaces: which screen, after which user action, in which system. If the AI alert fires at a step where the operator has already made the decision, the spec is wrong and adoption will fail.

Offline and low-connectivity behavior specified

Offshore platforms and remote field sites have intermittent connectivity. The spec defines three tiers: full connectivity, degraded connectivity, and offline. Each AI function has explicit behavior for each tier. Safety-critical functions have a defined fallback to manual procedure.

Engineering co-authored, not handed down

The spec rewrite is a joint document. Engineering reviews field discovery findings before the rewrite starts. Every line in the rewrite gets a technical feasibility sign-off from engineering before the spec is finalized. No surprises at the first sprint planning.

Houston industry specifics included

Energy specs include equipment tag identifiers and service classification fields. Healthcare specs include the clinical workflow step and the relevant EHR system screen. The spec is grounded in the actual systems the Houston operator or clinician works in every day.

How we work.

Discovery call, written scope, fixed price

One call to understand the prototype, the current adoption rate, and the field context. Within 48 hours: a written scope, list of deliverables, timeline, and fixed price. You approve the scope before we start.

Remote-first with Houston-time availability

We work Central Time and are available during Houston business hours. Shared Slack channel, Friday written updates, Loom walkthroughs for every milestone. Field discovery interviews are conducted by video call with screen-recorded sessions.

Start in two weeks

No recruiter, no job posting, no onboarding ramp. Field discovery can begin within two weeks of a signed agreement. The prototype that has been sitting unused for six months can have a revised spec in engineering within the month.

Questions about AI product management and field workflow discovery in Houston.

How do you do field workflow discovery, what does that process look like and how long does it take?: Field workflow discovery takes five to seven business days. It has three components. First, structured interviews with four to six people who actually use the workflow: not their managers, not the process owners, the people at the keyboard or on the platform. We record these with permission and take verbatim notes. Second, a process walk: we follow one real transaction or procedure from start to finish, noting every step, every tool, every decision point, and every workaround. Third, a friction inventory: we catalog every place the current workflow breaks, slows down, or requires tribal knowledge. The output is a workflow diagram with annotations showing where the AI feature was designed to fit versus where the actual workflow creates the opening for automation. That diagram drives the spec rewrite.
How do you write a product spec that accounts for low-connectivity environments like offshore platforms?: The spec needs a connectivity tier section that defines behavior at three states: full connectivity, degraded connectivity (satellite or LTE with latency above 500ms), and offline. For each AI feature, the spec states which functions degrade gracefully and which require connectivity to function at all. Safety-critical lookups that need an AI response should either be pre-cached during the daily sync window or blocked with a clear message directing the operator to the manual fallback. The spec also defines the sync protocol: when connectivity is restored, what data gets written back to the central system, in what order, and how conflicts with records modified onshore during the offline period are resolved. Shell and Halliburton both have established patterns for this in their mobile applications. We build on those patterns rather than inventing a new approach.
What is the most common reason AI features do not get adopted in operational environments, and how do you identify it?: The most common reason is that the AI feature was designed around the data the engineering team had, not around the question the operator actually needs answered. An anomaly detection feature built on sensor data works technically but does not get used because operators already watch those sensors on a dashboard and the AI alert does not tell them anything they do not already see. The adoption failure is visible in the field workflow discovery: you ask the operator 'when this alert fires, what do you do with it?' If the answer is 'I check the dashboard I already have open,' the feature is redundant. You identify it by watching the actual workflow, not by interviewing the person who commissioned the feature.
How do you manage the relationship between the engineering team that built the prototype and the AI PM who is rewriting the spec?: The framing matters from the first conversation with the engineering team. The field discovery findings are presented as new information, not a critique of the prototype. The prototype answered the question it was asked. The field discovery found that the question was incompletely specified. Every engineer on the team gets a copy of the workflow diagram and the friction inventory before the spec rewrite starts. We run a spec review meeting where engineering identifies which parts of the rewrite require rebuilding versus reconfiguring. We want engineering bought into the new spec, not defending the old one. The spec rewrite is a joint document: engineering signs off on technical feasibility for every line before it is finalized.

Get your Houston AI prototype into production.

Tell us the AI feature, the current adoption rate, and the industry context. We respond within one business day with a scope and price. No commitment required.

Hire an AI product manager in Houston.

The prototype works technically. The adoption is zero. That is a product problem. The UX was designed by engineers who never spent a day in the field workflow they were trying to improve.

When adoption fails and it is a product problem, not a technology problem.

The field workflow discovery process.

Structured operator interviews

Process walk from start to finish

Friction inventory

Workflow diagram with design annotations

The output is a diagram showing where the AI feature was designed to fit versus where the actual workflow creates the opening for automation. Engineering reviews this before any spec rewrite begins.

What the spec rewrite looks like.

Workflow integration points defined explicitly

Offline and low-connectivity behavior specified

Engineering co-authored, not handed down

Houston industry specifics included

How we work.

Discovery call, written scope, fixed price

Remote-first with Houston-time availability

Start in two weeks

Questions about AI product management and field workflow discovery in Houston.

How do you do field workflow discovery, what does that process look like and how long does it take?

Field workflow discovery takes five to seven business days. It has three components. First, structured interviews with four to six people who actually use the workflow: not their managers, not the process owners, the people at the keyboard or on the platform. We record these with permission and take verbatim notes. Second, a process walk: we follow one real transaction or procedure from start to finish, noting every step, every tool, every decision point, and every workaround. Third, a friction inventory: we catalog every place the current workflow breaks, slows down, or requires tribal knowledge. The output is a workflow diagram with annotations showing where the AI feature was designed to fit versus where the actual workflow creates the opening for automation. That diagram drives the spec rewrite.

How do you write a product spec that accounts for low-connectivity environments like offshore platforms?

The spec needs a connectivity tier section that defines behavior at three states: full connectivity, degraded connectivity (satellite or LTE with latency above 500ms), and offline. For each AI feature, the spec states which functions degrade gracefully and which require connectivity to function at all. Safety-critical lookups that need an AI response should either be pre-cached during the daily sync window or blocked with a clear message directing the operator to the manual fallback. The spec also defines the sync protocol: when connectivity is restored, what data gets written back to the central system, in what order, and how conflicts with records modified onshore during the offline period are resolved. Shell and Halliburton both have established patterns for this in their mobile applications. We build on those patterns rather than inventing a new approach.

What is the most common reason AI features do not get adopted in operational environments, and how do you identify it?

The most common reason is that the AI feature was designed around the data the engineering team had, not around the question the operator actually needs answered. An anomaly detection feature built on sensor data works technically but does not get used because operators already watch those sensors on a dashboard and the AI alert does not tell them anything they do not already see. The adoption failure is visible in the field workflow discovery: you ask the operator 'when this alert fires, what do you do with it?' If the answer is 'I check the dashboard I already have open,' the feature is redundant. You identify it by watching the actual workflow, not by interviewing the person who commissioned the feature.

How do you manage the relationship between the engineering team that built the prototype and the AI PM who is rewriting the spec?

The framing matters from the first conversation with the engineering team. The field discovery findings are presented as new information, not a critique of the prototype. The prototype answered the question it was asked. The field discovery found that the question was incompletely specified. Every engineer on the team gets a copy of the workflow diagram and the friction inventory before the spec rewrite starts. We run a spec review meeting where engineering identifies which parts of the rewrite require rebuilding versus reconfiguring. We want engineering bought into the new spec, not defending the old one. The spec rewrite is a joint document: engineering signs off on technical feasibility for every line before it is finalized.

Get your Houston AI prototype into production.

Tell us the AI feature, the current adoption rate, and the industry context. We respond within one business day with a scope and price. No commitment required.