When engineering teams moved from Word processors to plain-text and Git, they didn’t just change file formats — they changed how work happens. Why should product teams be any different? A recent piece on Antonym — Tools to steal from coders makes a crisp case for borrowing developer workflows. Read it. Then ask yourself: which parts of your team’s process are holding you back, and which could be reimagined as continuous, automatable flows?
Why the shift matters: from isolated tasks to continuous workflows
Most organisations still treat work as discrete tasks: write a spec in Google Docs, hand it over to engineering, then iterate in meetings. Engineers increasingly treat work as code: text files in Markdown, reviewable diffs, automated pipelines, and small deployable increments. The move from “AI-for-tasks” to AI-as-workflow is significant because it embeds intelligence into the flow of work, not as a bolt-on productivity hack.
Three implications for product leaders:
- Traceability — plain-text + version control gives history that is actionable, not just archival.
- Automatability — prompts, checks and transformations can run as part of CI/CD; AI becomes a stage in the pipeline.
- Composability — small, reusable components (prompts, templates, doc fragments) scale better than monolithic docs.
Practical moves: what to adopt and how to start
Here are pragmatic steps for product and engineering leaders who want to steal coder workflows without pretending to be engineers.
1. Treat documentation as code
Move decision records, specs and runbooks into plain-text repositories. Use a Markdown-first approach — it is portable, diff-friendly and widely supported. For guidance, see the Markdown Guide. Combine that with pull requests and lightweight reviews: you get accountability and asynchronous decision-making.
2. Automate QA for your artefacts
Engineers use CI to run linters, tests and deployments. Product teams can run checks on product specs, UX acceptance criteria and compliance notes. GitHub Actions or similar CI platforms can run validations and even call AI models as part of pipelines — so your spec isn’t “approved” until it passes basic semantic checks.
3. Treat prompts like code
As the Antonym piece highlights, prompts are becoming first-class assets. Store, version and peer-review prompts. Parameterise them. Test them in a sandbox. When prompts live in repositories alongside specs, you reduce the “magic prompt” problem and increase reproducibility.
Organisational changes that make adoption stick
Shifting tools without shifting behaviours leads to theatre: a repo that nobody trusts, or a PR process that becomes more bureaucracy. To avoid this, focus on three structural changes.
Cross-functional ownership of the pipeline
Product decisions should flow through cross-functional trios — product, design and engineering — who jointly own the repo and the CI. This turns handoffs into collaborative commits. Companies such as GitLab publish handbooks and process as code; this is a model for transparency and operationalising knowledge.
Measure outcomes, not artefacts
Switch KPIs from “documents produced” to outcomes: feature impact, hypothesis validation speed, or reduction in customer friction. When the repo becomes the single source of truth, you can instrument it to measure cycle time and risk.
Start with high-value, low-friction experiments
Don’t attempt a monolithic migration. Pick a small domain — e.g., onboarding flows or a component library — and try a Git+Markdown workflow with CI checks and a simple AI prompt library. Learn fast and expand where impact is clear.
A real-world example: docs-as-code at scale
Look at how engineering-first organisations treat knowledge. GitLab’s handbook lives in versioned repositories and is edited through merge requests. The effect is cultural: onboarding is faster, policy updates are auditable, and contributors across the company can propose changes. Translating that discipline into product practices yields the same benefits: faster learning cycles and less managerial friction.
Risks and guardrails
Three common pitfalls to watch for:
- Over-engineering — don’t replace simple collaboration with heavyweight processes. Start small.
- Tool fetishism — a new editor or AI model is not a strategy; people and incentives are.
- Accessibility — plain-text is great, but ensure documentation remains readable for non-technical colleagues through rendered views and accessible editors.
Also be realistic about tooling: coders use tools like GitHub Copilot and model-driven editor integrations. Product teams should adopt tools that fit their working culture, not the other way round.
What to do next
If you’re a CPO, CTO or product leader, pick a single product area for an experiment: move its specs to Markdown in a repo, add an automated CI check that runs a simple AI validation, and require PR-based changes for two weeks. Observe cycle time, quality of discussion and rework. That small bet will tell you more than a thousand slides.
Credit to Antonym’s article on tools to steal from coders for articulating the AI-as-workflow idea so clearly. The real step for leaders is not copying tools, but adopting the mindset: make work observable, automatable and composable. That’s where product leadership meets modern engineering practice — and where the next improvements in speed and quality will come from.
Ready to try it? Start small, measure impact, and let the repo drive the conversation. The tools are useful; the bigger opportunity is rethinking how work flows through your organisation.
Leave a Reply