A polished product specification can still hide the decision that matters. If the problem, user, outcome, or scope is unsettled, filling in a PRD template only makes the uncertainty harder to see.

Strawberry can work across customer evidence, product analytics, current browser behavior, documents, meetings, related tickets, and approved repository context. Your companion can trace requirements back to the accepted problem and keep open decisions visible instead of smoothing them into confident prose.

Start with the problem worth solving

Clarify the problem, affected users and situations, desired outcome, decision owner, scope, timing, constraints, evidence, and why the team is specifying it now. If the problem or priority is not accepted, write the smallest decision brief or open-question list needed to resolve it first.

Want to try it?

Ask your Strawberry companion: “Turn this accepted product problem and its evidence into a clear spec with user flows, requirements, edge cases, dependencies, open questions, and acceptance criteria.”

Skill

Write a product spec

Turn an accepted product problem and its evidence into a shared product definition and observable acceptance criteria.

Skill

Synthesize customer feedback

Synthesize the customer evidence first when the underlying problem is still unclear.

Inspect the current product

Review the current flow, relevant surfaces, existing documentation, related tickets, past decisions, constraints, dependencies, and known product behavior. Use the browser, analytics, meetings, documents, and repository context only where they change the definition.

Keep current behavior, customer evidence, stakeholder request, product judgment, and technical constraint distinct. Surface conflicts and stale assumptions rather than choosing the most convenient source.

Define the product change

Part of the specificationWhat it should resolve
Problem and outcomesWho is affected, in which situations, what should improve, and the evidence behind it.
Goals, non-goals, and scopeWhat this work will and will not attempt to change.
Flows and statesThe main path plus alternate, empty, error, permission, and recovery behavior.
Requirements and rulesObservable product behavior, content or data needs, dependencies, and rollout considerations.
Measurement and acceptanceHow the team will know the outcome improved and whether the implementation meets the definition.
Open decisions and risksThe owner, evidence needed, and why the unresolved choice could change the work.

Describe product behavior and outcome, not an implementation disguised as a requirement. Architecture, detailed system design, task breakdown, and code changes belong to the relevant Engineering workflow.

Review the high-risk parts first

When the interaction or scope is uncertain, review the critical flow and highest-risk choices before expanding the document. Trace consequential requirements to the accepted problem, evidence, constraint, or decision.

Check for contradictory rules, missing states, hidden dependencies, undefined terms, untestable criteria, accidental scope growth, and metrics that cannot answer whether the outcome improved. Ask each specialist only about decisions they genuinely own.

Put the spec where the team can use it

Deliver the concise decision summary, source links, flows, requirements, acceptance criteria, and remaining decisions in the team's useful format. Creating or updating that document does not approve tickets, roadmap changes, architecture, implementation, release, or customer communication.

Skill

Define and review product metrics

Define success measures or review the baseline when the specification's measurement still needs work.

Skill

Audit a product flow

Test the accepted flow and its important states in a safe environment once there is something to inspect.

Official Strawberry skill
Copy skill file Download skill file
name
write-a-product-spec
description
Turn an accepted product problem into a source-linked specification covering users, outcomes, requirements, flows, edge cases, dependencies, open questions, non-goals, measurement, and acceptance criteria. Use when product and engineering need a shared definition of what to build; keep roadmap prioritization, architecture, and implementation planning separate.

Write a Product Spec

Turn an accepted product problem into a clear definition of what should change and how the team will know it works. Do not hide unresolved product decisions behind a polished template.

1. Confirm the accepted problem

Clarify the problem, affected users and situations, desired outcome, decision owner, scope, timing, constraints, and why the team is specifying it now. Use source-linked customer feedback, product evidence, metrics, existing behavior, strategy, and prior decisions when available.

Use strawberry/product-engineering/synthesize-customer-feedback when the feedback still needs proper synthesis. A synthesis can inform the problem; it does not automatically approve the roadmap priority or solution.

If the problem or priority is not accepted, produce the smallest decision brief or list of open questions needed to resolve it rather than writing a fictional specification.

2. Understand the current product

Inspect the current flow, relevant product surfaces, existing documentation, past decisions, related tickets, constraints, and known dependencies. Use approved browser, document, product, analytics, meeting, and repository context where it changes the product definition.

Keep current behavior, user evidence, stakeholder request, product judgment, and technical constraint distinct. Surface conflicting sources and stale assumptions.

3. Define the product change

Build the specification around the work, including:

  • problem, users, situations, desired outcomes, and evidence;
  • goals, non-goals, scope, and decision boundaries;
  • the main user flow and important alternate, empty, error, permission, and recovery states;
  • functional requirements and relevant experience requirements;
  • product rules, data or content needs, dependencies, migrations, and rollout considerations;
  • measurement and guardrails;
  • acceptance criteria tied to observable behavior; and
  • open questions, risks, owners, and decisions still needed.

Write requirements that describe the product behavior and outcome, not an implementation disguised as a requirement. Architecture, detailed system design, engineering task breakdown, and code changes remain with the relevant Engineering workflow.

When the interaction or scope is still uncertain, present the critical flow and highest-risk choices first. Let the team correct them before expanding the full document.

4. Validate the specification

Trace consequential requirements back to the accepted problem, evidence, constraint, or decision. Check for contradictory rules, missing states, hidden dependencies, undefined terms, untestable criteria, unsupported claims, accidental scope expansion, and metrics that cannot answer whether the outcome improved.

Ask the relevant product, design, engineering, data, legal, support, or go-to-market owner only about decisions they genuinely own. Record accepted choices and leave unresolved items visible.

5. Deliver and apply only permitted document actions

Provide a concise spec in the team's useful format, with a short decision summary, source links, clear acceptance criteria, and the few remaining decisions that could change implementation.

Follow Strawberry's active scoped permission for the destination and action. If the current permission covers creating or updating the specified document or product record, apply the approved content and verify it. Otherwise return a reviewable draft or ask. Ticket creation, roadmap changes, architecture, implementation work, and release actions are separate.

Use strawberry/product-engineering/review-product-metrics when success measures need definition or current performance needs review. Preserve accepted product terminology, spec shape, source hierarchy, and review behavior after they prove useful.