Why I built a fictional product (and a documentation portfolio around it)
Every technical writer who has built a portfolio has run into the same problem. The best documentation work you've done is either covered by an NDA, attributable in ways you can't make public, or living inside an internal wiki that no one outside your company can access. You can describe what you did, but you can't show it.
To demonstrate and not just describe, I had to work around this limitation, and decided to build a fictional SaaS product that I could document as if it were real.
NimbusWiz is an enterprise SaaS platform for modernizing legacy systems. It includes a full product thesis, defined personas, a multi-stage workflow, and a working 13-screen application prototype. Every piece of documentation in this portfolio is built around it, and none of it is restricted.
The practical case for fiction
Even when NDA and attribution constraints are not a concern, authorship is often blurred: what reflects your thinking versus the team’s? What changed through review cycles? What can you claim with confidence?
With NimbusWiz, I don't have that ambiguity. Every decision in this portfolio, from the product design, structure, microcopy, and terminology to documentation, is mine, without redaction or hedging.
Why enterprise SaaS specifically
Enterprise products create real documentation challenges: multiple user roles, layered functionality, complex configuration, and competing user goals. They require documentation that spans onboarding, administration, APIs, and decision-making.
That complexity creates space for meaningful information architecture decisions. A simpler product would have resulted in simpler documentation, and fewer opportunities to demonstrate how structure, hierarchy, and flow are designed.
Three personas, three voices
I designed NimbusWiz for three primary users:
- A DevOps engineer focused on pipelines and APIs
- A system administrator managing configuration and access
- A technical manager making risk and outcome-based decisions
Each requires a different level of depth, context, and tone. By writing for all three audiences while maintaining a consistent product voice, I'm showcasing a core documentation skill in this portfolio, of adapting content without fragmenting the experience.
The Harry Potter nod
NimbusWiz emerged from an exploration of product ideas while I was listening to Harry Potter audiobooks; subtle references such as “Nimbus2000-class systems,” “Flight Profiles,” “Quirk Intelligence”, and Quidditch players' alter-egos as user personas are woven into the prototype.
That said, I've intentionally designed NimbusWiz to function as a standard enterprise SaaS application prototype, while understating The Harry Potter influence, because the goal isn’t novelty. It is coherence to help the system feel more real and reduce the artificiality of fully invented environments.
The product thesis does real work
NimbusWiz is built around a central idea: preserve versus replace.
The Modernization Advisor is a core feature that helps users decide whether to upgrade a system, not just how. This changes the role of documentation: not just to guide actions, but to explain reasoning, assumptions, and edge cases.
Features like simulation and system “quirks” extend this further. They require documentation that supports interpretation and judgment, not just execution.
Why this matters
By making every decision visible, this portfolio brings my core skills of product thinking, information architecture, and writing into the open. My work can be assessed on its actual substance. NimbusWiz is still a high fidelity prototype, and this portfolio is my sandbox! I intend to experiment with the latest tricks in Docs as Code at will here.