Business Product Consulting

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

For an open strategic or business decision, connect the situation, stakeholder, desired outcome, alternatives, value, risks, metrics and ownership before recommending action. Reuse supplied context and accepted choices. A bounded request does not require new discovery, an organizational intervention, an OKR or a memo. Investigate only missing information that can materially change the requested decision or work; use the relevant output fields and existing authorization.

Hierarchy And Handoffs

This skill owns decision framing above the feature: stakeholder choice, business value, alternatives, market and portfolio logic, operating model, organization, second-order effects, and an executive-ready recommendation. Start here when a leader or team must choose a direction rather than design a specific experience.

Use $product-design as the primary owner when the unresolved question is user research, opportunity discovery, UX behavior, interaction design, design-system work, or product requirements. Use this skill afterwards to synthesize the business decision from that evidence. Do not use a strategic memo as a substitute for discovery evidence.

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, non-goals, or realized economics, 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/market choices, vision and strategy, customer partners, business constraints, adoption friction, evidence selection, and UI/UX review through 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 product leadership capability, succession, role design or coordination burden, read the leadership sections of references/12-product-leadership-and-operating-model.md.
• For requested operating-model change or diagnosis of slow innovation/delivery, read the intervention and trial sections of references/12-product-leadership-and-operating-model.md. Team boundaries and dependencies remain in 08.
• 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

Select the relevant steps and output fields for the decision; reuse supplied framing for bounded work.

1. 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.
   • Product leadership or operating-model change advice: read the relevant sections of 12; use 08 for boundary/dependency questions and 09 for consequential risks.
2. Identify blocking unknowns. Ask only if the missing information changes the decision; otherwise state assumptions.
3. Start with an answer-first recommendation or a crisp problem statement.
4. Use SCR/SCQA to frame context and urgency.
5. Use MECE/issue trees only when decomposition clarifies the decision.
6. Connect every recommendation to user value, business value, metrics, risks, and ownership.
7. 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.