/curating-the-strategy-ideas-backlog

name: curating-the-strategy-ideas-backlog
description: Peer-Reviewer and portfolio-curator side of the TSI Shepherding Model — backlog stewardship, quarterly prioritization, funnel intake handoff.
when_to_use: Use when peer-reviewing someone else's Technical Strategy Idea or stewarding the ARCH idea portfolio. Triggers — "I'm peer reviewer on ARCH-…", "Architecture Council prep", "quarterly RICE scoring", "transitioning ARCH-X to the funnel". Not for Primary Owner work on a specific idea (use `championing-a-strategy-idea`).
allowed-tools: Skill, mcp__plugin_bitwarden-atlassian-tools_bitwarden-atlassian__get_issue, mcp__plugin_bitwarden-atlassian-tools_bitwarden-atlassian__get_issue_comments, mcp__plugin_bitwarden-atlassian-tools_bitwarden-atlassian__get_issue_remote_links, mcp__plugin_bitwarden-atlassian-tools_bitwarden-atlassian__search_issues, mcp__plugin_bitwarden-atlassian-tools_bitwarden-atlassian__get_confluence_page, mcp__plugin_bitwarden-atlassian-tools_bitwarden-atlassian__get_confluence_page_comments, mcp__plugin_bitwarden-atlassian-tools_bitwarden-atlassian__search_confluence, mcp__plugin_bitwarden-atlassian-tools_bitwarden-atlassian__search_confluence_cql

Peer-Reviewer and portfolio-curator playbook for Bitwarden's [Technical Strategy Ideas](https://bitwarden.atlassian.net/wiki/spaces/EN/pages/2344517656) (TSI) backlog — the upstream idea-stage system that feeds the Software Initiative Funnel at Identification. Covers serving as constructive challenge function for someone else's idea, stewarding the backlog (weekly triage, monthly RICE updates, Now/Next/Later placement), the quarterly prioritization review with engineering leadership, and the handoff of approved ideas to the funnel.

The Two Roles per Active Idea

Each TSI in active status (Research through Implementation) has two Architecture members assigned. The TSI page is explicit about this:

• **Primary owner.** Drives the idea through the pipeline: writes the problem statement, conducts research, presents at Architecture Council, shepherds the transition to the funnel. Accountable for progress. The Primary Owner's playbook is `Skill(championing-a-strategy-idea)`.
• **Peer reviewer.** A second Architecture engineer who acts as a sounding board, stays informed, and provides a **constructive challenge function**. Not a co-owner. Their job is asking the hard questions, catching cross-initiative conflicts, ensuring stakeholder engagement is thorough. **This is your role when invoking this skill** — alongside the broader portfolio-curator practice covered in the rest of the skill.

How Peer Review Works

Per the TSI page:

• Peer reviewers are assigned per idea. As ideas move through the lifecycle and new ones enter, pairings shift to keep the team building breadth across the portfolio.
• The primary owner shares progress and decision points with the peer reviewer on an ongoing basis. The biweekly architecture working session is the primary venue; ad-hoc check-ins are expected for time-sensitive decisions.
• Before an idea moves from Backlog to Research, the primary owner and peer reviewer **jointly complete the Stakeholder & Engagement Map** section of the template. This is a gate.
• When the idea is presented at Architecture Council, the peer reviewer attends as an informed ally who can help field questions and support the discussion.
• **No single engineer should carry more than two active reviewer assignments at a time, primary or peer.** Overloading review defeats its purpose.

The Stakeholder & Engagement Map as a Gate

The map is the gate ideas must pass through before advancing from Backlog to Research. Its five fields — Decision makers, Must consult, Must inform, Known friction points, Engagement approach — are detailed in `Skill(championing-a-strategy-idea)`, the canonical home for the map's mechanics from the Primary-Owner side. The map is **completed collaboratively** by Primary Owner and Peer Reviewer; ideas do not enter Research without it.

As Peer Reviewer, your specific job is to push on the map — especially **Known friction points**, the field where ideas most often get soft-pedaled and the TSI page explicitly names as where "technically sound proposals stall at adoption." When triaging an idea ready to advance from Backlog → Research, the question is: is the map complete and honest? Push back if friction is hand-waved, if decision makers are vague ("the Vault team" rather than a named role with stated authority), or if the engagement approach doesn't match the stakeholder's communication style.

RICE Scoring Discipline

Each idea carries a RICE score: **Reach × Impact × Confidence / Effort**. Per the TSI page, scoring guidance lives in [Idea RICE Scoring](https://bitwarden.atlassian.net/wiki/spaces/EN/pages/2634252326/Idea+RICE+Scoring).

Curator practice:

• **Update scores monthly.** As more is learned about an idea — through peer review, stakeholder conversations, or related initiatives advancing — the score gets refined.
• **Weekly new-idea triage** ensures the backlog stays current; **mid-quarter backlog management** revisits scores against the current portfolio.
• Resist score inflation. Reach is what it is; Confidence reflects the actual state of knowledge. An honest RICE score that says "Confidence is low" is more valuable than an inflated one that hides the question that PoC would answer.

Theme, Roadmap Placement, Customer Segments

Per the TSI page, ideas carry standardized prioritization fields beyond RICE:

• **Theme.** Architecture / Operations / SDLC / Products / Application Security. Determines which portfolio view the idea shows up in.
• **Roadmap placement.** Now / Next / Later. Per the [Architecture / Engineering Operating Model](https://bitwarden.atlassian.net/wiki/spaces/EN/pages/1286963201), these are the lanes used in the Now/Next/Later portfolio communicated to engineering leadership.
• **Customer segments.** Individuals / Teams / Enterprises / Self-Hosted