# Documentation Validation

I began my career in SSD and firmware testing, where failure analysis and edge
cases are a daily reality. That mindset has carried forward into my work across
software and documentation.

For the past seven years, I’ve worked at the intersection of customers,
engineering, and documentation. As a validation engineer by training, I focus
on how systems, and the materials that support them hold up in real-world use,
not just in ideal scenarios.

Documentation validation isn’t glamorous, but it directly impacts adoption,
support load, and customer trust. For companies building complex technology,
unclear or incorrect documentation is a hidden business risk.

I offer a one-week engagement focused on a single software stack. The goal is
to evaluate whether the documentation enables customers to succeed, where it
introduces friction, and where it may actively block adoption. This can include
high-level reviews of tutorials and guides, or targeted analysis of known
problem areas.

The engagement concludes with a concise, prioritized report highlighting what
is working (green), what needs improvement (yellow), and what is likely broken 
red), giving leadership a clear view of risk, impact, and next steps.

## Overview

A focused, external review for execution-focused engineering teams

### The Problem

In fast-moving engineering organizations, documentation validation often falls behind product delivery and operational demands. As a result, documentation issues are frequently discovered first by customers through failed onboarding, increased support requests, or stalled adoption.

By the time these signals appear, they already represent lost time, lost momentum, or lost trust.

### The Approach

This engagement applies a validation mindset, drawn from systems and firmware testing, to customer-facing documentation.

Instead of reviewing documentation for completeness or polish, the focus is on how it performs under real-world use:

- Does it enable a new customer to succeed?
- Where does it introduce friction or confusion?
- Where does it fail outright?

As a neutral third party, the review is intentionally independent of internal context, intent, or historical decisions.

### The Engagement

**Duration**: One week \
**Scope**: One software stack

During the engagement, documentation is validated from the customer’s perspective. This may include:

- Reviewing onboarding paths, tutorials, and guides
- Walking through documented workflows end to end
- Identifying contradictions, missing assumptions, and failure points
- Focusing on areas known to generate support or customer friction

The engagement is fixed-scope and designed to be low-risk and easy to approve.

### The Deliverable

At the conclusion of the engagement, leadership receives a concise, prioritized report that categorizes findings as:

- **Green**: Working as intended
- **Yellow**: Needs improvement or clarification
- **Red**: Likely broken or actively blocking adoption

Findings are written to be actionable for both engineers and writers. Each issue includes clear context, concrete examples, and guidance on what to fix, not just what is wrong.

### Who This Is For

This engagement is well-suited for teams that:

- Build complex or technical software
- Care about customer adoption and time-to-value
- Suspect documentation may be a hidden source of friction
- Want an independent, decision-quality assessment

### Price Structure

Validation Review ($2,500)
: Targeted validation of one core documentation path (for example: onboarding, tutorial, or quickstart), including findings and recommendations.

Workflow Validation ($6,500)
: Broader review of documentation workflows, including contribution process, CI/CD integration, structure, and multiple user paths.

These engagements are designed to be low-overhead and typically complete within 1–2 weeks.