| name | business-product-consulting |
| description | Use when framing, reviewing, validating, or communicating product engineering decisions through business/product consulting judgment. Trigger for business value analysis, product strategy, product/market analysis, PRD/RFC/memo/deck/executive-summary writing or review, SCR/SCQA/Pyramid Principle communication, MECE/issue-tree problem structuring, UI/UX review with product/business lens, developer productivity measurement with SPACE, AI-assisted development rollout with DORA 2025, Team Topologies/org-flow/ownership reviews, risk/second-order-effect analysis, and future-facing product/system tradeoff decisions. |
Business Product Consulting
Use this skill to make product engineering work decision-ready: clarify business context, user value, stakeholder decision, metrics, risks, organizational flow, and communication storyline before proposing implementation.
Core Rule
Do not start from the feature, screen, model, library, architecture, or implementation. First clarify the situation, complication, stakeholder, decision, desired outcome, alternatives, business/user value, risks, metrics, ownership, and next test or ask.
Reference Routing
Read only the references needed for the current task.
- Always start with
references/00_README.md for broad business/product consulting work.
- For translating a ticket into business/user value, stakeholder decision, outcomes, constraints, and non-goals, read
references/01-business-thinking.md.
- For executive updates, PRDs, RFCs, strategy memos, postmortems, emails, and concise narrative framing, read
references/02-scr-scqa-communication.md.
- For answer-first communication, storyline, synthesis, argument quality, and executive summaries, read
references/03-pyramid-principle.md.
- For problem decomposition, root-cause analysis, issue trees, workstreams, segmentation, roadmap options, and taxonomy design, read
references/04-mece-issue-trees.md.
- For product discovery, market/opportunity analysis, value proposition, adoption friction, competitor/alternative framing, and UI/UX review through product/business outcomes, read
references/05-product-discovery-and-market-analysis.md.
- For developer productivity, dev tooling, platform/productivity claims, engineering metrics, and avoiding vanity metrics, read
references/06-developer-productivity-space.md.
- For AI-assisted software development, agentic coding, AI tool rollout, evals, guardrails, governance, and value-stream impact, read
references/07-ai-assisted-development-dora.md.
- For organization design, team ownership, platform/product boundaries, cognitive load, dependencies, and fast flow, read
references/08-team-topologies-fast-flow.md.
- For downside analysis, future impact, hidden work, support burden, operational risk, rollback, and guardrails, read
references/09-risk-and-second-order-effects.md.
- For reviewing decks, memos, RFCs, demo narratives, UI/UX narratives, and leadership updates, read
references/10-presentation-review-checklist.md.
- For creating or updating a future skill, routing behavior, output discipline, or agent operating model, read
references/11-agent-operating-model-and-skill-outline.md.
Workflow
- Classify the request:
- Ambiguous product/engineering task: read
01, then 04, 05, and 09 as needed.
- PRD, RFC, deck, memo, executive update, or presentation review: read
02, 03, and 10.
- Product/market analysis or opportunity framing: read
01, 04, 05, and 09.
- UI/UX review: read
05 and 10, then use the product-design skill/knowledge when deeper UI/UX methods are needed.
- Developer productivity or tooling: read
06, plus 09.
- AI-assisted development or agents in engineering workflows: read
07, then 06 and 09.
- Org design, ownership, platform, architecture dependencies, or team flow: read
08, then 09.
- Identify blocking unknowns. Ask only if the missing information changes the decision; otherwise state assumptions.
- Start with an answer-first recommendation or a crisp problem statement.
- Use SCR/SCQA to frame context and urgency.
- Use MECE/issue trees only when decomposition clarifies the decision.
- Connect every recommendation to user value, business value, metrics, risks, and ownership.
- Separate
Source-backed, Applied extension, Assumptions, and Open questions when the answer mixes framework facts with product-engineering inference.
Output For Product Or Business Framing
Include:
- Situation and complication.
- Stakeholder and decision needed.
- User/customer/buyer/operator affected.
- Desired product and business outcome.
- Alternatives and trade-offs.
- Evidence, assumptions, and uncertainty.
- Success metrics and guardrails.
- Risks, second-order effects, and rollback/owner.
- Recommended next test or next decision.
Output For Communication Review
Lead with storyline quality and missing decisions:
- Main answer or recommendation.
- Whether SCR/SCQA is clear.
- Whether the Pyramid Principle holds: one governing thought, grouped reasons, evidence, and
so what.
- Whether MECE grouping is clean enough for the decision.
- Missing risks, trade-offs, metrics, or asks.
- Concrete rewrite or outline.
Output For Developer Productivity Or AI Adoption
Include:
- Current bottleneck and value stream.
- SPACE dimensions or DORA AI capability being improved.
- Expected benefit and failure mode.
- Quality, security, privacy, review, and eval guardrails.
- Metrics across outcome, flow, quality, satisfaction, and rework.
- Rollout, rollback, owner, and downstream impact.
Output For Org, Platform, Or Architecture Flow Review
Include:
- Value stream and owning team.
- Team types and interaction modes where useful.
- Cognitive-load and handoff risks.
- Platform-as-product or thinnest viable platform considerations.
- Dependencies, service boundaries, team API, and owner.
- How the relationship should evolve as learning changes.
Quality Bar
- Do not present frameworks as proof. Use them to structure evidence and decisions.
- Do not claim market facts, competitor facts, legal facts, pricing facts, or current tool status without current evidence.
- Do not call productivity improved from activity metrics alone.
- Do not recommend AI rollout without evals, human review policy, guardrails, and ownership.
- Do not recommend org/platform changes without explicit owner, interaction mode, cognitive-load impact, and fast-flow rationale.
- Mark ideas beyond the bundled sources as
Applied extension or external extension.
