Personas
20 fictional practitioners covering the full spectrum of roles in a technology product organisation. Each persona carries a best practices profile across all 12 library categories.
Working With the Team
The PushBackLog team is the product's first and most demanding client. Before PushBackLog can enforce quality gates on other teams' backlogs, review AI execution runs for other teams' projects, and close the feedback loop between production incidents and properly-formed work items, it has to work that way itself. This roster is not assembled as a demo or a showcase — it is the actual squad building a platform whose central claim is that bad tickets cost your team more than bad code, and whose entire value proposition rests on doing delivery right.
That creates a specific kind of team: one with sharp edges, strong convictions, institutional depth, and a particular intolerance for the shortcuts that produce the poor backlog quality PushBackLog exists to end. What follows is an honest account of what that means for anyone engaging with them.
What the Team Brings
The product they're building is their own first use case — and they know it.
PushBackLog is confirmed to manage its own continued development through itself as early as the platform is functional enough to do so. That means every persona on this roster will eventually be represented as a configured AI worker in the system, with enforcement levels drawn directly from the profiles in this directory. Every quality gate the platform enforces on other teams will first have been enforced on a PBL work item.
Security is non-negotiable at every level of the stack.
PushBackLog handles tenant data, codebase access via GitHub App installation tokens, AI execution runs in ephemeral Fargate sandboxes, and short-lived credentials that must never be stored long-lived. Five independent practitioners from different disciplines all independently hold the same four security practices at hard: OWASP Top 10, input validation, secrets management, and least privilege.
Delivery is disciplined because the product depends on it being trusted.
PushBackLog's competitive claim is that it produces better backlog quality than teams manage on their own. That claim falls apart the instant the team ships something vague, unreviewed, or built against acceptance criteria nobody wrote down. Christopher Shank owns the backlog and does not let items proceed without clarity on what done means.
The institutional memory here is the Best Practices Library in human form.
PushBackLog's Best Practices Library is one of its three strategic assets — a public, freely readable catalog of actionable practices that personas embed as their durable knowledge layer. The library did not emerge from a content strategy meeting. It emerged from a team with decades of hard-won production experience encoded into each article.
The platform is built to fail gracefully because its first engineers have been on-call.
Marcus Okonkwo builds with written, tested runbooks as baseline hygiene. Dayle holds structured logging and distributed tracing at hard, because she has managed production incidents where their absence turned a thirty-minute diagnosis into a six-hour investigation.
The PushBackLog name is not aspirational branding — it is a job description.
Christy Arthur will open a PR review and ask why is this not tested? before she asks anything else. Todd Jensen's first question about any practice is what problem does this solve, and is that a problem we actually have? The product claims it will push back on poor quality. The team building it does the same thing, consistently, as a working style rather than a policy.