Product decisions rarely start with one tidy source. The insight is spread across support conversations, call notes, analytics, screenshots, Slack, and the live product. By the time it's a spec, the reason behind it is hard to reconstruct.

Because Strawberry is the browser, it can reach those surfaces directly. It keeps customer insight attached to the product definition it produced, carries a finding from a tested flow into a grounded issue, and remembers the corrections your team accepts.

What Strawberry can help you do

Not sure where to begin? Your companion can look at the product and engineering work you have open and suggest a useful skill to try first.

/getting-started-with-product-engineering-in-strawberry

Choose and complete the product or engineering workflow that would help most right now.

View skill

Move from feedback to a product definition

Customer feedback becomes more useful when the situation around it stays visible: who ran into the problem, what they were trying to do, which flow or version they used, and what happened next. Strawberry can synthesize themes and tensions while keeping representative examples linked to the original records. Once the team accepts the problem, the same evidence can inform a product spec without quietly turning every request into a roadmap commitment.

  1. Synthesize what customers are telling you

    Find the themes, tensions, examples, and evidence gaps without automatically prioritizing the roadmap.

    /synthesize-customer-feedback

    What are customers actually telling us?

    View skill

  2. Define the product behavior to create

    Turn the accepted problem into users, outcomes, requirements, flows, edge cases, open questions, and acceptance criteria.

    /write-a-product-spec

    Write a spec for this feature.

    View skill

Define and review product metrics

A chart can look precise while the team is using different definitions for the behavior, population, time window, or exclusions. Strawberry can inspect the dashboards, analysis, product docs, and earlier decisions behind the metric, reconcile the definitions that matter, and then review the baseline, trend, funnel, cohort, or segment. The result separates what moved from why it may have moved and what Product should learn from it.

/review-product-metrics

Review our product metrics.

View skill

Test product flows

Strawberry can navigate the experience in the browser, check the important path and a few meaningful variations, and return the passes, regressions, screenshots, and relevant console or network evidence. The team can inspect the same browser while the audit runs, redirect it when the flow is unclear, and take over for a sensitive or unfamiliar step.

/audit-a-product-flow

Test this product flow and tell me what breaks.

View skill

Research and report bugs

A useful bug report needs more than the visible symptom. Strawberry can reproduce the behavior, look at approved Slack or Teams discussion, inspect GitHub context and recent changes, check logs and existing issues, and identify the team's actual ticketing system. It searches for a duplicate before preparing or filing a report, giving Engineering a reproducible issue instead of a screenshot with no surrounding context.

Keep the team operating layer connected

Product and Engineering still depend on the work around the specialist workflows. Meeting preparation and debrief keep decisions attached to their records. Open-loop reviews find unclear ownership and conflicting status. Updates turn the accepted picture into the right message, while onboarding helps a new teammate find the current work instead of receiving a document dump. Once a method works, it can become a shared team workflow.

  1. Prepare for the decision

    Bring together the recent context, open questions, and decisions the meeting needs to move forward.

    /prepare-for-meetings

    Prepare me for my next meeting.

    View skill

  2. Turn the meeting into follow-through

    Capture decisions, owners, open questions, and updates while the context is still fresh.

    /debrief-a-meeting

    Debrief my last meeting.

    View skill

Close the important open loops

Reconcile product and engineering commitments, ownership gaps, and conflicting status across the places work happens.

/close-open-loops

Show me what's slipping through the cracks.

Share the product and delivery picture

Turn the accepted evidence into a concise update for leadership, the team, or another stakeholder.

/prepare-a-status-update

Write a status update on my current work.

Help a new teammate find the current work

Build a role-aware context pack, setup plan, and first-week path from the systems the team actually uses.

/onboard-a-new-teammate

Plan onboarding for our new hire.

Start with the evidence, product question, flow, or unexpected behavior that matters now. The system gets better as accepted definitions, decisions, and browser evidence remain available for the next piece of work.

Run an AI-native ops team

See how meetings, open loops, updates, onboarding, and shared workflows support the team.

Research deep enough to bet on

See how source finding, extraction, synthesis, comparison, and reporting can support deeper product work.

Market like a team of ten

Connect product insights and launches with audience research, campaigns, content, and performance learning.

Try this starter pack in Strawberry

/getting-started-with-product-engineering-in-strawberry

Getting Started with Product and Engineering in Strawberry

Help the user see how Strawberry can connect Product learning, Engineering quality, and the shared operating layer, then finish one useful piece of work. Keep Product learning and Engineering QA as two substantial, connected lanes. Browser-based QA is often the sharpest first run because the companion can inspect and test the real product; Product work carries that evidence into longer decisions about problems, specifications, and measures.

Paint the connected Product and Engineering system

Explain briefly that Strawberry can keep evidence connected as work moves across customer feedback, support, meetings, analytics, specifications, repositories, GitHub, issue trackers, team communication, and the product itself. The companion can follow that evidence through visible tabs and logged-in tools while the team inspects the work and controls consequential actions.

Show two distinct but connected loops:

  • Product learning: customer evidence helps the team accept a problem, define the product change, choose meaningful measures, and learn from real performance and later feedback.
  • Engineering quality: observed behavior leads to a bounded browser audit, grounded issue, requested fix, and proportionate validation without losing the original evidence.

Meetings, open commitments, status updates, onboarding, and shared team methods keep both loops working across people. The user can enter at any current decision or delivery risk; do not force Product and Engineering through one story or make every workflow part of a single sequence.

Find a useful first win

Understand the product area, user or customer, environment, evidence already available, desired result, and the decision or delivery risk that matters now. Use the approved context most likely to change the result.

If the user is unsure where to begin, offer a small, prioritized set of relevant options. Explain why each fits, and avoid presenting the whole catalog:

  • synthesize customer feedback around a product question;
  • turn an accepted problem into a product specification;
  • define or review the metrics for a product decision;
  • audit a critical product flow in the browser; or
  • research unexpected behavior and prepare or file a grounded bug report.

Suggest a connection only when it materially improves the first result. Do not make a complete toolchain setup a prerequisite.

Use the Product learning lane

Use the focused owner at each stage:

  1. strawberry/product-engineering/synthesize-customer-feedback gathers and reconciles approved feedback into themes, tensions, source-linked examples, gaps, and confidence. It stops before roadmap prioritization.
  2. Once the team accepts the problem and wants to define a change, strawberry/product-engineering/write-a-product-spec owns users, outcomes, requirements, flows, edge cases, dependencies, open questions, and acceptance criteria. Architecture and implementation planning remain outside its specialist judgment.
  3. strawberry/product-engineering/review-product-metrics can define a practical metric framework, review existing performance, or do both. It owns definitions, source quality, baselines, trends, funnels, cohorts, segments, hypotheses, guardrails, and implications—not deep data engineering or instrumentation changes.

The user may enter at any stage. Do not make the whole sequence mandatory, and do not allow a thin feedback sample to silently approve the problem or roadmap position.

Use the Engineering QA lane

Use strawberry/product-engineering/audit-a-product-flow to navigate and test a critical flow, capture screenshots and relevant console or network evidence, and return passes, regressions, blocked paths, scope, and uncertainty. Public live sites support read-only inspection. Prefer staging, preview environments, or dedicated test accounts for authenticated or stateful paths.

Use strawberry/product-engineering/report-bug when unexpected behavior needs a grounded issue. It may inspect approved Slack or Teams discussion, GitHub context and recent changes, logs, monitoring, existing issues, and the team's actual ticketing system. It searches for duplicates and drafts or files the report according to the active scoped permission.

If the user also requests a fix, the companion may continue through the available coding workflow under the normal repository, change, validation, and permission boundaries. Bug reporting does not artificially end the work.

Connect the operating layer

Use strawberry/operations/prepare-for-meetings and strawberry/operations/debrief-a-meeting to connect product conversations to reliable decisions and follow-through. Use strawberry/operations/close-open-loops for cross-system commitments and ownership gaps, strawberry/operations/prepare-a-status-update for an audience-specific product or engineering update, and strawberry/operations/onboard-a-new-teammate for a role-aware context and first-week path.

After a method has worked, use strawberry/operations/set-up-shared-team-workflow to agree on sources, owners, destinations, privacy boundaries, and review behavior. These shared workflows support the role; they do not crowd out the Product or Engineering owner.

Learn through real work and keep actions scoped

Calibrate with a small, varied first sample when the evidence, environment, volume, or consequence makes early correction valuable. Let the team correct sources, definitions, severity, scope, environment, output, and validation bar before expanding.

Follow Strawberry's active scoped permission for every source, repository, environment, account, destination, and action. Research, product testing, issue creation, document changes, code changes, merging, deployment, production or customer-data changes, and external communication are separate actions. Draft or ask when permission is insufficient. Stop when identity, scope, impact, or sensitive-data handling changes, and verify completed external actions.

Keep secrets, credentials, private messages, and customer data out of reusable methods and broad artifacts. The guide is working when the team has a useful result, understands the next product or delivery decision, and can build on accepted evidence instead of reconstructing it.