Founding growth engineering at Fiber AI

The problem

At Fiber AI, growth work required a close understanding of the product: what its APIs could do, which capabilities mattered to a buyer, and how to communicate them accurately.

My role connected that understanding to execution. I worked across research, internal tooling, content, and iteration with the team, rather than treating engineering and commercial communication as separate jobs.

Founding growth engineering

As a founding growth engineer, I moved between technical product questions and the work needed to bring the product to market. That meant understanding capabilities, building internal tools, preparing commercial material, and improving the work through team feedback.

• Product understanding: research API capabilities and connect them to relevant use cases.
• Internal tooling: build preparation and verification systems that support repeatable growth work.
• Growth execution: turn research into source-backed copy, visual direction, and review material.
• Iteration: work with the team on product accuracy, branding, and editorial quality.

A wider remit; one selected implementation

The research-to-review workflow below is a selected example from the founding-growth role. It brings together product research, engineering, and commercial communication; it is not the full extent of the role.

This implementation supported internal preparation and verification. Publishing remained a separate human decision.

Keep evidence attached through generation and review

I kept research, generation, and publication separate. Source material stays attached to the claims it supports, and missing evidence remains an open question. The reviewer should not have to repeat the research just to decide whether a sentence is safe to use.

Following team feedback, I made the branding deterministic so generated material would follow consistent visual rules. Charts and captions needed separate checks: charts had to represent their data correctly, while captions needed useful product detail and a natural editorial voice. Those remained quality checks to work through, rather than results I could assume from a successful generation.

The direction developed with the team. Feedback on Fiber’s API capabilities helped shape the research and content workflow; my contribution was connecting that product understanding to the internal build.

Selected build: research-to-review tooling

I built the workflow around a reviewable output, with checks and verification records that could be inspected beyond a single successful run.

• Input checks and research workflows connecting a product question with supporting material.
• Content review packages that keep copy, visual direction, and source evidence together.
• Repeatable test cases and verification records, followed by a separate human publishing gate.

How the selected workflow fits together

Product understanding fed the preparation tools; the tools returned material that someone could inspect before publication.

Preparing work for review

The internal workflow produced complete review packages rather than isolated drafts. A reviewer could inspect the claim, its source, and the checks together before deciding what could be published.

What I took forward

A growth engineer needs to understand the product well enough to build useful tools and explain it well enough to reach a buyer. At Fiber, I worked on both sides, using feedback to improve the connection between them.