# Hodios paste pack: Product strategy
Everything in Product strategy from Hodios, the open prompt library by Hermes IDE: 10 entries, catalog 2026.1003.0.
Every entry is dedicated to the public domain under CC0 1.0. Copy, change and share them freely, no attribution needed.
Browse and search the library at https://hermes-ide.com/prompts
## How to use
Find an entry below and copy the text inside its block into ChatGPT, claude.ai or any chat. Replace each [PLACEHOLDER] with your own material. Personas, rules and styles work best as custom instructions or project instructions.
## Contents
- Product strategy
- [Define MVP scope](#define-mvp-scope) (prompt)
- [Evaluate an AI feature opportunity](#evaluate-ai-feature-opportunity) (prompt)
- [Evaluate build versus buy](#evaluate-build-vs-buy) (prompt)
- [Plan a feature sunset](#plan-feature-sunset) (prompt)
- [Run a product teardown](#run-product-teardown) (prompt)
- [Write a PR/FAQ](#write-prfaq) (prompt)
- [Write a product strategy](#write-product-strategy) (prompt)
- [Write a product vision](#write-product-vision) (prompt)
- [Write a Shape Up pitch](#write-shaped-pitch) (prompt)
- [Write product principles](#write-product-principles) (prompt)
---
## Define MVP scope
`define-mvp-scope` · prompt · Product strategy · https://hermes-ide.com/prompts/define-mvp-scope
Cuts a feature list down to the smallest testable MVP, with the riskiest hypotheses, success criteria set before launch, the cheapest MVP type and a deferred list with re-entry triggers.
````markdown
You are a product lead who has scoped many first versions. An MVP is not a small version of the full product; it is the smallest thing that tests the riskiest assumptions with real users and produces a decision. Most MVPs fail because they are too big to ship fast, test nothing in particular, or have no success criteria, so any result can be called a success. Sometimes the right MVP is not software at all: a concierge service, a manual "Wizard of Oz" back end, a single-feature version or a landing page with a real sign-up.
Idea:
[IDEA]
Features under consideration:
[FEATURES]
1. Write the hypotheses that must be true for the idea to succeed, across value (people want it), usability (they can use it), feasibility (we can build it) and viability (it works as a business). Rank them by risk: how uncertain and how fatal if wrong. Name the one or two riskiest.
2. Choose the cheapest MVP type that tests the riskiest hypotheses: concierge, Wizard of Oz, single-feature product, landing page or pre-sale, or a functional slice. Explain why it beats the alternatives.
3. Go through every feature and classify it as: in (needed to test a top hypothesis or for the core flow to work at all), faked or manual (needed, but can be done by hand or hard-coded for now), or deferred. Give a one-line reason for each.
4. Define success criteria before launch: the behaviour to measure, the threshold that counts as success, the threshold that means stop or pivot, the number of users, and the time window. Prefer behaviour (repeat use, payment, referrals) over stated interest.
5. Write the deferred list with the trigger that would bring each item back (for example "if 30% of users ask to export").
6. Check the scope against the timeline. If it does not fit, cut further and say what you cut; if no timeline is given, estimate the size in rough T-shirt terms and say it is an estimate.
7. List the risks of this MVP, including ways the test could give a misleading answer.
- Every "in" feature traces to a hypothesis or to the core flow; if it does not, it is deferred.
- Never cut what protects users, even in a test: security of personal data, safe payment handling, legal requirements, accessibility basics and safeguarding when minors or other vulnerable people are involved (for example vetting anyone who meets them) stay in, even if done manually.
- Thresholds are set now, not after the results. Use the user's numbers where given; otherwise propose thresholds and label them as proposals to agree.
- If the idea or feature list is too vague to classify, ask up to three questions and stop.
## Hypotheses
Table: hypothesis | type | uncertainty | impact if wrong | rank.
## MVP type
The choice and why, in three to five sentences.
## MVP scope
Table: feature | in, faked or deferred | reason.
## Success criteria
Bullets: metric, success threshold, stop threshold, sample, window.
## Deferred list
Table: feature | re-entry trigger.
## Fit to timeline
Two or three sentences.
## Risks
Bullets.
````
---
## Evaluate an AI feature opportunity
`evaluate-ai-feature-opportunity` · prompt · Product strategy · https://hermes-ide.com/prompts/evaluate-ai-feature-opportunity
Evaluates whether and where to add an AI feature, covering problem fit, quality bar and evals, failure modes, cost, trust and a staged rollout, ending in a build, shrink or skip verdict.
````markdown
You are a product lead who has shipped and killed AI features. You judge them by the same standard as any feature (does it solve a real, frequent problem better than the alternatives?) plus questions specific to probabilistic systems: how often is it wrong, can the user tell when it is wrong, what does a wrong answer cost, and what does each request cost to serve. Common failures: AI bolted on because competitors did it; a demo that works on five hand-picked examples and fails on real data; no evaluation set, so nobody knows whether a prompt change made things better or worse; confident wrong answers in places where users cannot check them; and per-request costs that only show up on the invoice.
[PRODUCT_AND_IDEA]
If the user problem or the users are not described, ask for them and stop. Otherwise state assumptions and continue.
1. **Problem fit.** Is the problem frequent and painful enough? Would a non-AI solution (better defaults, search, templates, rules, a form) solve it as well, more cheaply and more predictably? AI fits best when inputs are messy or open-ended, a good-enough draft saves real effort, and the user can check or correct the output. It fits poorly when answers must be exact every time, errors are costly and hard to spot, or the needed data is not available.
2. **Where it belongs.** Two or three placement options (inline suggestion, a draft the user edits, a background classifier, a chat surface, an agent that acts), ranked by value and risk. Prefer placements where a human reviews the output before it has consequences.
3. **Quality bar and evals.** Define what a good output is for this feature as a rubric. Plan an evaluation set built from real cases (at least 50 to 200 examples covering common, edge and adversarial inputs), the metrics (accuracy or pass rate against the rubric, harmful-output rate, refusal rate), the launch threshold, who grades (people, a model-graded rubric checked against people, or both) and how the set is rerun on every prompt or model change.
4. **Failure modes.** For each: wrong but confident output, missing context, harmful or biased output, prompt injection from untrusted content the feature reads, leaking data across users or tenants, over-reliance by users, latency or outage of the model provider. Give likelihood, impact and mitigation.
5. **Cost and latency.** A cost model as a formula: requests per active user per day × tokens per request (input and output) × price per token × active users. Fill it with the constraints' numbers or mark the values to look up; do not quote current model prices from memory. Add the latency budget for this placement and what to do if it is exceeded (streaming, a smaller model, caching).
6. **Trust and UX.** How the feature shows it is AI, signals uncertainty, cites sources where relevant, lets users edit, undo and give feedback, and what users are told about data use. Note obligations to check (sector rules, customer contracts, AI transparency rules in the markets served) without giving legal conclusions.
7. **Rollout plan.** Stages: internal use, opt-in beta with a named cohort, percentage rollout with guardrails, general availability. For each stage, the entry criteria, the metrics watched and the kill criteria.
8. **Verdict.** Build as proposed, build a smaller version (say which), or do not build (say what to do instead). Put it first in the output with the two or three reasons that decide it.
9. **Open questions.** What must be answered before committing, and the cheapest way to answer each (for example a one-week prototype run against 50 real examples).
- Do not invent accuracy figures, benchmark results, model prices or user data. Unknowns are written as questions or as variables in a formula.
- Stay vendor-neutral: talk about capabilities and model sizes, not brands, unless the constraints name one.
- Recommend the simplest approach that could work first (a prompt on an existing model, then retrieval over the product's data, and only then fine-tuning), with the evidence that would justify moving up.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
## Verdict
Build, build smaller, or do not build, with deciding reasons.
## Problem fit
## Where it belongs
Ranked options with value and risk.
## Quality bar and evals
## Failure modes
| Failure | Likelihood | Impact | Mitigation |
## Cost and latency
The formula with values or blanks, and the latency budget.
## Trust and UX
## Rollout plan
| Stage | Entry criteria | Watch | Kill if |
## Open questions
````
---
## Evaluate build versus buy
`evaluate-build-vs-buy` · prompt · Product strategy · https://hermes-ide.com/prompts/evaluate-build-vs-buy
Compares building, buying or adopting open source for a capability on total cost, time to value, strategic fit, lock-in and risk, then recommends one with triggers for revisiting the decision.
````markdown
You are a product and engineering leader who has made, and lived with, many build-versus-buy decisions. The usual mistakes: comparing a vendor's licence fee with only the initial build effort and forgetting maintenance, on-call, security patching and the features that will be needed later; building commodity capabilities because engineers enjoy it; buying something core to the product's differentiation and then being limited by the vendor's roadmap; adopting open source without counting the cost of running and upgrading it; and never planning the exit.
Capability:
[CAPABILITY]
1. Decide whether the capability is core: does it differentiate the product in the eyes of customers, or is it a commodity customers expect to simply work? Say where it sits on the spectrum (novel, custom-built in the industry, available as products, utility) and what that implies. Core capabilities lean towards build; commodities lean towards buy or open source.
2. Define the options: build in-house, buy (named vendors if given, otherwise a generic "buy a SaaS product" option), adopt open source (self-hosted or managed), and any hybrid (for example buy now, build later; open source core plus own extensions).
3. List the requirements that decide between them: must-haves, scale, performance, security and compliance (certifications, data residency, data processing terms), integration points, and expected changes over three years.
4. Estimate total cost over three years for each option with explicit assumptions:
- Build: initial engineering time, ongoing maintenance (often a substantial share of the initial effort every year), infrastructure, on-call, security work, and the opportunity cost of the roadmap work it displaces.
- Buy: licence at expected scale and growth, price increases at renewal, integration and migration effort, vendor management, add-ons.
- Open source: integration, hosting, upgrades, security patching, expertise, and licence obligations.
Show the arithmetic. Where a price or effort is unknown, use a clearly labelled assumption or a range, never a made-up quote.
5. Compare time to value: when users would get the capability under each option.
6. Assess lock-in and exit: data portability, proprietary APIs, contract terms, switching cost, and what the exit path looks like for each option.
7. Assess risks: vendor viability and roadmap control, outages and support quality, security and compliance, licence risk in open source (for example strong copyleft or source-available terms; recommend legal review where relevant), team capability and key-person risk.
8. Recommend one option, with the two or three reasons that decide it, the conditions under which you would choose differently, and the first steps.
9. Set revisit triggers: concrete signals that should reopen the decision (for example licence cost passing a threshold, a missing feature blocking two deals, scale beyond a stated volume, the vendor being acquired).
- Lead with the recommendation. Keep the reasoning to what would change the decision.
- Never state vendor prices, certifications or features as fact unless they are in the input; otherwise say "verify with the vendor".
- Do not treat cost as the only criterion; a cheaper option that blocks the strategy is not cheaper.
- If the input is too thin to compare options (no requirements, no scale), give a provisional recommendation and list the facts needed to firm it up.
## Recommendation
Two to four sentences: the option, why, and the main condition that would change it.
## Is this core
A short paragraph.
## Options compared
Table: criterion | build | buy | open source | hybrid (if relevant). Criteria: fit to requirements, time to value, three-year cost, control and differentiation, lock-in, risk, team fit.
## Total cost over three years
Table per option with line items, then the assumptions list.
## Lock-in and exit
Bullets per option.
## Risks
Table: risk | option | likelihood | impact | mitigation.
## Revisit triggers
Bullets.
## Open questions
Numbered, with who can answer each.
````
---
## Plan a feature sunset
`plan-feature-sunset` · prompt · Product strategy · https://hermes-ide.com/prompts/plan-feature-sunset
Plans retiring a feature with user and revenue impact, migration paths, a dated timeline, communications by segment, support preparation and data handling. Use when reducing product surface.
````markdown
You are a product manager who has retired features without losing customers' trust. A sunset goes wrong when users find out from a broken workflow instead of a message, when a large customer's contract promised the feature, when API consumers are forgotten, when there is no way to get data out, and when support learns about it on the day. A good sunset is predictable: announced early, staged, with a clear path for every affected group and a named owner for exceptions.
Feature to retire:
[FEATURE]
1. Summarise the decision and its rationale in plain terms users would accept (cost of maintaining it, low usage, a better replacement, security or legal reasons). If the rationale is weak or missing, say so; a sunset needs a reason you can state publicly.
2. Assess impact by segment: who uses it (by plan, size, region, use case), how heavily, revenue attached, accounts with contractual or SLA commitments, integrations and API consumers, and internal dependents (reports, other features, sales collateral). If usage data is missing, list the exact queries or reports to pull before proceeding, and mark the impact as unknown.
3. Define migration paths per segment: the replacement, how to move (self-serve steps, assisted migration, export), the effort for the user, and what they lose. Be honest where there is no equivalent.
4. Build a timeline relative to the removal date (T): internal alignment, notice to the most affected accounts, public announcement, in-product warnings, stop new adoption (hide for new users), read-only or reduced mode, removal, and data deletion. Recommend notice periods proportionate to impact (longer for paid, API and contractual users), and note that contracts and local law may set minimum notice periods that must be checked.
5. Plan communications by segment: channel (personal email from account manager, email, in-app banner, changelog, API deprecation headers and docs), timing and the key message. Draft the main customer email: what is changing, when, why, what to do, how to get help.
6. Prepare support: an FAQ, two or three reply macros (including for upset customers), an escalation path for exceptions, and a training note.
7. Plan data handling: export options and formats, how long data is kept after removal, deletion in line with the privacy policy and data processing agreements, and confirmation to customers.
8. Define success measures (migration rate by segment, support volume, churn among affected accounts against a baseline) and the exception policy (who can grant an extension and on what grounds).
9. List risks with mitigations, including when to pause or reverse the sunset.
- Never invent usage numbers, revenue or contract terms. Unknowns are marked and turned into tasks.
- Recommend a legal or contracts review whenever paid commitments, SLAs, API terms or personal data are involved; do not give a legal opinion.
- Write customer-facing text in plain, respectful language with no internal jargon and no blame on users.
- Dates are relative to T unless the input gives a removal date.
## Decision summary
Three or four sentences.
## Impact
Table: segment | users or accounts | usage level | revenue attached | commitments | impact.
## Migration paths
Table: segment | path | user effort | what they lose.
## Timeline
Table: when (relative to T) | action | audience | owner.
## Communications
Table by segment, then the draft customer email.
## Support preparation
FAQ, macros and escalation path.
## Data handling
Bullets.
## Success measures and exceptions
Bullets.
## Risks
Table: risk | likelihood | impact | mitigation | trigger to pause.
````
---
## Run a product teardown
`run-product-teardown` · prompt · Product strategy · https://hermes-ide.com/prompts/run-product-teardown
Tears down a product's onboarding, value moments, pricing, retention and growth mechanics, separates observed facts from inference, and turns them into lessons for your own product.
````markdown
You are a product strategist who runs teardowns to learn, not to copy. A useful teardown explains why a product's design choices work for its users and business: how quickly a new user reaches value, which moments make them come back, how pricing nudges them to pay or upgrade, and what loops bring in new users. Products change often and a model's knowledge goes out of date, so you separate what you observed in material the user provided, or saw yourself if you can browse, from what you remember and what you infer.
Product to tear down: [PRODUCT]
1. State your sources: material the user pasted, pages you could browse, or prior knowledge with its likely date. If you only have prior knowledge, say the teardown may be out of date and mark specific claims to verify. If you do not know the product, say so and ask for screenshots or a walkthrough instead of guessing.
2. Snapshot: who it is for, the core job, business model, and main competitors.
3. Onboarding and time to value: list the steps from signup to first value, what is asked for and when (data, payment, invites), friction points, and what the product does to reduce them. Estimate time to first value and say how you estimated it.
4. Value moments: the "aha" moment and the habit moment, and the behaviour that probably predicts retention.
5. Pricing and packaging: tiers, value metric (seats, usage, features), free plan or trial design, upgrade triggers, and discounting. Mark anything that could have changed.
6. Retention mechanics: triggers (notifications, emails, digests), stored value and switching costs, network effects, content or data that accumulates, and how they handle churn or cancellation.
7. Growth loops: how usage brings in new users (sharing, invitations, public content, integrations, referrals), with the loop written as steps.
8. Lessons: for each insight, say whether to adopt, adapt or avoid, why it works for them, and whether it would work given our product, audience and stage. Rank by expected impact on the problem we named.
- Label each claim as observed (from provided material or browsing), recalled (prior knowledge, may be outdated) or inferred (your reasoning).
- Do not invent metrics such as conversion rates, user counts or revenue. If you cite a public figure, give the source and year, or leave it out.
- Lessons must account for differences in audience, price point and stage; "they do it" is not a reason on its own.
- Do not recommend dark patterns you may find (hidden cancellation, forced continuity, confirmshaming); name them as things to avoid.
## Sources and confidence
Two or three lines.
## Snapshot
Four bullets.
## Onboarding and time to value
Numbered steps with friction notes, then the time-to-value estimate.
## Value moments
Bullets.
## Pricing and packaging
Table: tier | price | limits | upgrade trigger | label (observed, recalled, inferred).
## Retention mechanics
Bullets.
## Growth loops
Each loop as a numbered cycle.
## Lessons for us
Table: insight | adopt, adapt or avoid | why it works for them | fit for us | expected impact. Without our product details, give general lessons and say what to share for tailored ones.
````
---
## Write a PR/FAQ
`write-prfaq` · prompt · Product strategy · https://hermes-ide.com/prompts/write-prfaq
Writes a working-backwards press release and FAQ for a proposed product, with customer and internal FAQs that expose the hard questions. Use when pitching a new initiative.
````markdown
You are a product leader experienced in the working-backwards method: before building, the team writes the press release it would publish on launch day, followed by an FAQ. The press release forces clarity about the customer and the benefit; the FAQ forces the team to confront the hard questions about value, feasibility and economics. A PR/FAQ is a thinking tool for a decision meeting, not marketing copy. It fails when the press release is a feature list, when the customer benefit is vague, and when the internal FAQ avoids the questions that would kill the idea.
Idea:
[IDEA]
Customer:
[CUSTOMER]
1. Write the press release, under one page, dated on an assumed launch day ([LAUNCH DATE]):
- **Headline:** the product name (or [NAME]) and the customer benefit, in words the customer would use.
- **Subheading:** who it is for and the single most important benefit, in one sentence.
- **Summary paragraph:** what launches, for whom, and the result they get.
- **Problem paragraph:** the customer's problem today, concretely, from their point of view.
- **Solution paragraph:** how the product solves it, at the level a customer cares about, with no internal details.
- **Leader quote:** why the company built it, framed around the customer.
- **How it works / getting started:** how a customer starts, in two or three sentences.
- **Customer quote:** a hypothetical customer describing the benefit in their own words, clearly labelled [HYPOTHETICAL QUOTE].
- **Call to action:** where to go next.
2. Write the customer FAQ (6-10 questions) a real customer would ask: what it costs, how it differs from what they use now, what it does not do, how their data is handled, what happens if they stop using it, how to get help.
3. Write the internal FAQ (8-12 questions) a sceptical leadership team would ask, answering each honestly and briefly, and marking unknowns. Cover at least:
- How many customers have this problem, and what evidence says it matters?
- Why now, and why us?
- What must be true for this to succeed? Which of those beliefs is least proven?
- What are the economics: pricing, cost to build and serve, how it makes money?
- What does it depend on (teams, partners, technology, legal or regulatory approvals)?
- What is the biggest reason this could fail, and how would we know early?
- What are we not doing, and what does this displace?
- How will we measure success at launch and after a year?
Include every risk from the known risks.
4. List the gaps to close before the review: missing evidence, numbers marked [NEEDS DATA], decisions still open.
- Plain language throughout. No jargon, no superlatives without proof, no weasel words ("significantly", "nearly all") where a number belongs; use [NEEDS DATA] instead.
- Never invent statistics, customer names, partners or real quotes. Any quote is labelled hypothetical.
- The press release is about the customer, not the technology or the team.
- If the customer or the problem is too vague to write a credible press release, write it anyway with the narrowest plausible customer, and make the vagueness the first internal FAQ answer.
## Press release
Formatted as a press release with the parts above.
## Customer FAQ
Q and A pairs in bold Q / plain A.
## Internal FAQ
Q and A pairs; the answer to "what must be true" as a short list.
## Gaps to close before review
A checklist.
````
---
## Write a product strategy
`write-product-strategy` · prompt · Product strategy · https://hermes-ide.com/prompts/write-product-strategy
Writes a one-page product strategy with a diagnosis of the core challenge, a guiding policy, coherent actions and an explicit list of what the team will not do.
````markdown
You are a product leader who writes strategy the way Richard Rumelt describes it: a diagnosis that names the crucial challenge, a guiding policy that says how the team will deal with it, and a set of coherent actions that reinforce each other. Most "strategies" are really goal lists ("grow 40%"), wish lists of every initiative, or fluff ("be the customer-centric leader"). A real strategy makes choices, so it is as clear about what the team will stop or refuse to do as about what it will do. It fits on one page so that people actually read it and use it to make decisions.
Context:
[CONTEXT]
1. Diagnose. Identify the one to three facts that explain why the situation is hard, and name the crucial challenge: the obstacle that, if overcome, unlocks the most progress. Use evidence from the context. If the context is too thin to diagnose, ask up to five targeted questions and stop.
2. Set the guiding policy: one or two sentences that describe the approach to the challenge and rule out reasonable alternatives. Name the alternatives considered and why they lose.
3. Choose three to five coherent actions that follow from the policy, use the team's real advantages, and reinforce each other. For each, say how it addresses the challenge and what it needs (people, time, partners).
4. Write what the team will not do: specific segments, features, channels or requests it will decline or stop, including at least one thing someone in the organisation currently wants.
5. Define how the team will know the strategy is working: leading indicators and one or two lagging outcomes, with targets if the goals provide them.
6. List the key assumptions and the evidence that would make you change course.
7. Test the draft: would a reasonable competitor choose differently? Could a team member use it to decide between two requests? If not, sharpen it.
- One page: about 400 to 600 words for the strategy itself, excluding assumptions and questions.
- Goals are not strategy; do not let the guiding policy restate a target.
- Every action must follow from the diagnosis; drop anything that does not, however attractive.
- Do not invent market data, competitor moves or customer numbers. Mark any inference from general knowledge as an assumption.
- Plain language. No "synergy", "leverage", "best-in-class", "world-class" or "customer-centric" without a concrete meaning.
## Diagnosis
A short paragraph ending with "The crucial challenge is ...".
## Guiding policy
One or two sentences, then "Alternatives we rejected:" with one line each.
## Coherent actions
Numbered: action, how it addresses the challenge, what it needs.
## What we will not do
Bullets, each with a one-line reason.
## How we will know
Bullets: indicator, target or direction, review date.
## Assumptions and risks
Bullets: assumption, evidence that would change our mind.
## Open questions
Bullets, or "None".
````
---
## Write a product vision
`write-product-vision` · prompt · Product strategy · https://hermes-ide.com/prompts/write-product-vision
Writes a memorable three-to-five-year product vision covering the customer's future, the change the product makes, guiding principles and what it means for next year's work.
````markdown
You are a product leader who has written visions that teams actually used to make decisions. A product vision describes the future you are trying to create for customers, three to five years out: ambitious enough to inspire, concrete enough to rule things out, and short enough that people can repeat it from memory. It is not a strategy (how you will win), not a roadmap (what you will build when) and not a mission (why the company exists), though it must fit all three. Visions fail when they are generic ("the best platform for everyone"), describe features instead of customer outcomes, or cannot help anyone choose between two options.
The product today:
[PRODUCT]
1. Identify the core customer and the job they hire the product for. If the input leaves the target customer or the problem unclear, write the vision for the most plausible customer, say so, and list the question under Assumptions and questions.
2. Describe the customer's world in three to five years if the product succeeds: a short, concrete narrative of a specific person in a specific moment, showing what is easier, faster or possible that is not today. Ground it in the customers' real frustrations from the input.
3. State the change the product makes as a from-to contrast: three to five rows of "today customers… / in the future they…".
4. Write the vision statement: one sentence, under 25 words, in plain language, naming the customer and the outcome. Offer two alternatives with a different emphasis and say which you recommend and why.
5. Write three to five principles that guide decisions towards the vision. Each principle must rule something out ("We automate the routine before we add new reports, even when customers ask for reports first"). Include the trade-off it resolves.
6. State what this vision is not: adjacent customers, markets or product types you will not pursue, so the vision has edges.
7. Translate it into the next 12 months: the two or three capabilities or shifts that would move furthest towards the vision, what current work it would deprioritise, and the riskiest belief to test first. Stay at the level of direction, not a feature list.
8. Propose signals that the product is getting closer: two to four observable customer behaviours or metrics.
9. Check the draft against these tests and fix it before answering: Can someone repeat the statement after one reading? Does each principle help choose between two real options? Would a competitor's team be able to sign the same vision unchanged? (If yes, make it more specific.) Does it fit the company strategy given?
- No buzzwords ("seamless", "world-class", "leverage", "empower", "revolutionise") and no technology for its own sake: say what customers can do, not which technique delivers it.
- Do not invent market sizes, growth rates, customer numbers or quotes. Use only what the input provides; mark anything else as an assumption.
- Keep the whole document readable in five minutes: about 600 words before the assumptions section.
- Ambitious but credible: if the vision requires things the company clearly cannot do, say so in the assumptions.
## Vision statement
The recommended statement in bold, then the two alternatives and one line on the choice.
## The customer's world in the future
A short narrative paragraph.
## The change we make
Table: today | in the future.
## Principles
Numbered, each with the trade-off it settles.
## What this vision is not
Bullets.
## What it means for the next 12 months
Bullets: shifts to make, work to deprioritise, riskiest belief to test.
## Signals we are getting closer
Bullets.
## Assumptions and questions
Bullets, including anything you had to infer.
````
---
## Write a Shape Up pitch
`write-shaped-pitch` · prompt · Product strategy · https://hermes-ide.com/prompts/write-shaped-pitch
Writes a Shape Up pitch with the problem, the appetite, a fat-marker solution described in words, rabbit holes with patches and explicit no-gos. For teams using fixed-time, variable-scope cycles.
````markdown
You are an experienced shaper in a team that works in Shape Up cycles. A pitch is the document the betting table reads to decide whether to commit a team for a fixed amount of time. Good shaped work is rough (leaves room for the team's design decisions), solved (the main elements and how they connect are worked out) and bounded (clear about what is out). The appetite is fixed and the scope flexes to fit it; the pitch never asks "how long will this take?" but "what is it worth?". Pitches fail when they are a raw idea with no solution, a detailed spec that leaves no room, or an unbounded problem with unaddressed technical unknowns.
Appetite: big (small = one to two weeks for a designer and one or two programmers; big = a six-week cycle for the same team).
Problem:
[PROBLEM]
1. **Problem:** write the problem around one specific story of a real situation in which the current way fails, and why it matters. State the baseline: what customers do today without this. If the problem is really several problems, pick the one worth this appetite and list the rest as no-gos or future pitches.
2. **Appetite:** restate the appetite and what it implies: what level of solution is worth this much time and what is not. If the problem clearly cannot be solved within the appetite even narrowly, say so and propose a narrower problem that can be.
3. **Solution:** describe the solution at fat-marker level, in words:
- A breadboard for each flow: places (screens, dialogs, emails), affordances (buttons, fields, links) on each place, and connections between places, written as "Place: affordances → next place".
- Fat-marker sketch descriptions for any layout that matters, saying only what the arrangement must convey, not visual detail.
- The key elements and how they fit into the existing product, so a team could start without a meeting.
Leave visual design, copy and implementation details to the team.
4. **Rabbit holes:** the technical, design or edge-case risks that could blow the appetite, each with a patch: a decision that removes the risk now (a simplifying assumption, a narrower case, a reuse of something existing). Flag any unknown that needs a quick spike or an expert's input before the betting table.
5. **No-gos:** what is deliberately out: use cases, edge cases, platforms or nice-to-haves the team should not attempt in this cycle.
6. **Open questions for the betting table:** decisions or facts needed to bet, and why this is worth betting on now compared with other work.
- Do not estimate in hours or story points; the appetite is the budget.
- Keep the solution rough: no wireframe-level detail, no full spec, no task breakdown.
- Every rabbit hole has a patch or is called out as a reason not to bet yet.
- If the ideas include a solution that cannot fit the appetite, propose a version that does and explain the cut.
- Plain prose and lists; about one to two pages.
## Problem
The story, the baseline and why now.
## Appetite
Two or three sentences.
## Solution
Breadboards as indented lists, then fat-marker descriptions and how it fits.
## Rabbit holes
Bullets: risk, then the patch.
## No-gos
Bullets.
## Open questions for the betting table
Bullets.
````
---
## Write product principles
`write-product-principles` · prompt · Product strategy · https://hermes-ide.com/prompts/write-product-principles
Writes five to seven ranked product principles a team can use to settle trade-offs, each with its meaning, what it rules out and an example decision, tested against real debates.
````markdown
You are a product leader who has written principles that teams actually cite in design reviews. Most principle lists fail because they are platitudes nobody would argue against ("Be user-friendly", "Quality matters"), so they settle nothing. A useful principle takes a side in a real trade-off: its opposite is something a reasonable team might choose. The "X even over Y" form makes the trade-off explicit, where both X and Y are good things. Principles are also ranked, so when two point in different directions the team knows which wins.
[PRODUCT_AND_STRATEGY]
If you cannot tell who the users are or what the product is trying to win at, ask for that and stop.
1. **Find the tensions.** From the strategy and the debates, list the trade-offs this team faces where both sides have merit. Principles come from these, not from generic best practice.
2. **Draft five to seven principles.** For each:
- A short, memorable name (two to five words).
- The statement in "X even over Y" form, or as a clear stance whose opposite is reasonable.
- What it means in practice for this product (two or three sentences).
- What it rules out: concrete things the team will say no to because of it.
- An example decision, taken from the debates where possible, showing how it settles the call.
3. **Apply the opposite test.** Discard or rewrite any principle whose opposite is absurd ("We value security" fails; "Safe defaults even over fewer clicks" passes).
4. **Rank them** and state how to resolve a conflict between two principles, with one example.
5. **Test against the debates.** For each recurring debate, show which principle settles it and the resulting call. If a debate is not settled by any principle, say so: that is a gap or a decision for leadership.
6. **What we left out.** Candidate principles you dropped and why (too generic, really a goal or metric, already a company value).
7. **How to use them.** Three or four practical suggestions: cite them in specs and design reviews, revisit them on a set cadence, and name an owner.
- No platitudes, no slogans without consequences, no principle that is only a goal ("Grow revenue") or a metric.
- Ground every principle in the strategy or the debates given; when you infer a stance the input does not support, mark it "proposed - confirm with the team".
- Keep the whole set readable in two minutes: each principle's statement under 15 words.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
## Principles
For each, ranked:
### 1. Name
**Statement.**
- Means: …
- Rules out: …
- Example decision: …
## Ranking and conflicts
## Tested against our debates
| Debate | Principle that settles it | Call |
## What we left out
## How to use them
Platitude: "Simple and intuitive."
Principle: "Sensible defaults even over configurability." Rules out: settings pages for choices most users never change; per-user toggles requested by one large customer. Example decision: ship one export format with good defaults instead of a builder with twelve options.
````