Der ganze Katalog

You are a product strategist who has seen plenty of projects die. Assess my SaaS idea honestly, without cheering me on.

Idea: {what the service does}
For whom: {who, as narrowly as possible}
What the person does today without us: {how the job gets done now}
How I plan to charge: {model and price}
Time and money I can spend before first revenue: {resources}

Break it down:
1. The problem: does it hurt regularly, or is it a one-off inconvenience? Answer plainly.
2. Who pays: the user themselves or their manager — and why that changes the product.
3. The three main risks: why this could fail. For each — the cheapest way to test it.
4. What already exists on the market, including a spreadsheet, a notebook and "do nothing" — count those as competitors too.
5. The most dangerous assumption: the one that makes everything else pointless if it's wrong.
6. A one-week test plan: what to do on which day to get a signal without writing code.
7. The kill criterion: what result means the idea should be dropped.

If the idea is weak, say so in the first paragraph.

Help me draw the boundary of an MVP that can actually be shipped and sold.

Product: {what the service does}
The main scenario: {what the user does from login to result}
Who the user is: {description}
Time available for development: {timeframe}
Who is building it: {one developer / a team / no-code}

Do this:
1. One user path from sign-up to first value — step by step, no branches.
2. The features without which that path doesn't work. Each with a reason why it can't be dropped.
3. Features that feel mandatory but aren't needed in an MVP — and what replaces them for now (manual work, an email, a spreadsheet).
4. What to cut entirely, and why it won't stop you selling.
5. The boundaries: what the product does NOT do. Wordings for the site so nobody expects otherwise.
6. An estimate in weeks, broken down, with a note on where the estimate is least reliable.
7. What can be done by hand for the first few months instead of being automated.

Rule: if a feature can be replaced by a human at launch, it does not belong in the MVP.

Help me choose the technologies for a project and explain the price of each decision.

What the product is: {description}
What I can do: {languages and tools, honestly}
Time to launch: {timeframe}
Who will maintain it: {just me / a team / a contractor}
Special requirements: {payments, files, real time, offline, integrations}
Monthly infrastructure budget: {amount}

Break it down:
1. The recommended set: frontend, backend, database, hosting, auth, payments, email.
2. For each — why this one in my situation, and a sensible alternative.
3. The price of the choice: what becomes awkward within a year.
4. What I shouldn't build myself but buy as a service, and what it costs.
5. What to avoid specifically in my case, and why.
6. An estimate of the infrastructure bill at 100, 1,000 and 10,000 users.
7. Which choice will be hardest to reverse later — and how to reduce that lock-in.

Account for my skills: an unfamiliar technology on a short deadline is a risk, not an advantage.

Write the hero section of a landing page for a SaaS product.

Product: {what it does}
For whom: {a narrow audience}
What work it replaces: {what the person does today}
The main benefit in numbers: {time, money or errors saved}
Model: {free tier / trial / paid only}
How it differs from the nearest competitor: {a fact}

Give me:
1. Five headline options: clear rather than clever. No metaphors and no use of the word "platform".
2. A subheading for each: who it's for and what happens after signing up.
3. Button copy — three options, at different levels of commitment.
4. A line under the button that removes fear: card, cancellation, setup time.
5. Three pieces of proof to sit beside the hero that you can show without an existing customer base.
6. What to remove: the standard phrases that say nothing.
7. A test: read the headline aloud and say whether someone hearing about the product for the first time would understand it.

Write it so the headline makes the product's job clear even without the image.

Turn a list of changes into release notes and an email to users.

Changes: {paste a list of commits, tickets or your own notes}
Product: {what it does}
Who reads it: {technical users / general users}
Any breaking changes: {yes, which / no}
What the user must do: {nothing / update settings / migrate}

Do this:
1. Release notes grouped into "new", "improved", "fixed". Every item in the language of benefit, not of code.
2. Breaking changes as a separate block at the top, with the exact date and instructions.
3. The email: subject, first line, three paragraphs, one button. About the single biggest change; the rest as a link.
4. A short social post about the most noticeable item.
5. What on the list users don't need to hear about at all — and why.
6. A tone check: cut "we've been working hard" and "we're excited to announce", keep what people can now do.

Rule: never write "fixed bugs" without saying which — be specific or don't mention it.

Pick the metrics for my product at its current stage.

Product and model: {what it is and how people pay}
Stage: {no users / first customers / steady sales}
Paying customers now: {number}
What I already track: {list}
The main question I need answered: {e.g. "is it worth spending on ads"}

Do this:
1. Five to seven metrics, no more. For each: what it shows, how it's calculated, how often to look.
2. Why the other popular metrics are only a distraction at my stage.
3. The single number that shows whether the product is healthy — and how to calculate it for my case specifically.
4. Benchmarks: which value counts as bad, normal and good for my model.
5. How each metric can be accidentally gamed, and what to watch alongside it so that doesn't happen.
6. What to start recording in the product now so there is something to analyse in six months.
7. For each metric: what decision I'll make if it turns bad.

If a metric leads to no decision, leave it out.