dMetrics

At dMetrics, I lead product design for analytical workflows spanning structured writing, evidence analysis, intelligent assistance, collaboration, and knowledge graphs. I work from ambiguous domain problems through product strategy, interaction models, prototypes, interface design, and implementation, partnering directly with engineers, ML/data specialists, and subject-matter experts.

Minsky IPE

One evidence trail from the requirement to the reviewed report

For Minsky IPE, I framed the product around a break in the intelligence workflow: requirements, sources, drafts, and approvals lived in different systems, while the finished analysis still had to be written and reviewed in Microsoft Word. The opportunity was not another AI chat interface. It was a connected production environment that helped analysts find gaps, evaluate evidence, and preserve responsibility for every conclusion.

• Set the direction around the evidence lifecycle. I used doctrine, analytical standards, stakeholder knowledge, and domain research to connect planning, collection, analysis, validation, publication, and review around one shared record.
• Made deliberate product cuts. I ruled out a cloud assistant because the work had to remain on an air-gapped network, a replacement editor because analysts already produced reports in Word, and generated answers detached from source material because they weakened traceability.
• Designed AI to support judgment rather than replace it. Suggestions remained reversible, evidence stayed attached to claims, failures stayed visible, and analysts could inspect supporting or contradicting material before accepting a machine-assisted conclusion.
• Embedded analytical rigor in the workflow. ICD-203 and best-practice checks surfaced unsupported claims, classification conflicts, and disclosure issues without silently rewriting the analyst’s work.
• Carried the design into working software. In a three-person platform team, I designed with two engineers and built realistic prototypes with React, TypeScript, Node.js, Yjs, ProseMirror, Google Cloud, and Firebase. When the workflow still stopped at the document, I proposed, designed, and implemented the Word LTSC 2024 add-in.

The shipped add-in brought requirements, evidence, collection state, tradecraft checks, and the review trail into the document where analysts already worked. It also established a reusable interaction pattern across the platform: enter at the point of work, expose what is missing, keep failure visible, and make generated actions reversible.

Knowledge graph and collaboration workflows

Connected information that remains traceable and reusable

The same product direction extended beyond one report. I designed interaction models that connect AI outputs to entities, relationships, evidence, and source material so people can investigate where information came from, understand how it relates, and reuse it in later analysis.

• Made the graph useful through tasks, not diagrams alone. Exploration patterns helped analysts discover related entities and evidence in the context of a question they were trying to answer.
• Preserved accountability in collaborative work. Real-time editing and character-level attribution made contributions visible as reports moved between analysts and reviewers.
• Used code to test product behavior early. Implementation-oriented prototypes let product and engineering evaluate collaboration, editor behavior, AI interactions, and technical constraints before committing them to the platform roadmap.

Across these workflows, my role is to turn complex AI and data capabilities into systems experts can interrogate, control, and trust, and to stay close enough to implementation that the product behavior can be tested rather than only described.