From 00964626e0396253e3ae0d2366469be8b745bef8 Mon Sep 17 00:00:00 2001 From: za-iteraite Date: Wed, 27 Aug 2025 13:02:00 -0400 Subject: [PATCH 1/2] Adding the PM documentation --- .../.cursor/rules/RICE-analysis-template.mdc | 68 ++++++++ .../.cursor/rules/context-generator.mdc | 43 +++++ .../.cursor/rules/epic-generator-template.mdc | 100 +++++++++++ .../.cursor/rules/kpi-revenues-template.mdc | 67 ++++++++ .../.cursor/rules/lean-canvas-template.mdc | 42 +++++ .../.cursor/rules/persona-template.mdc | 27 +++ .../.cursor/rules/prd-template.mdc | 131 +++++++++++++++ .../.cursor/rules/product-context.mdc | 59 +++++++ .../.cursor/rules/product-positioning.mdc | 25 +++ .../.cursor/rules/risk-analysis-template.mdc | 26 +++ .../.cursor/rules/roadmap-template.mdc | 33 ++++ .../.cursor/rules/user-journey-template.mdc | 55 ++++++ .../.cursor/rules/user-story-template.mdc | 38 +++++ .../LICENSE | 21 +++ .../README.md | 115 +++++++++++++ .../alternate-templates/alternate_read.me | 3 + .../alternate-templates/epic-alternate | 38 +++++ .../helper-docs/example-product-context.md | 59 +++++++ .../helper-docs/extra-copy-context.txt | 59 +++++++ .../helper-docs/kpi_revenues.txt | 50 ++++++ .../list_of_product_metrics_text_only.txt | 159 ++++++++++++++++++ .../product-documents/Contents.txt | 1 + 22 files changed, 1219 insertions(+) create mode 100644 rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/RICE-analysis-template.mdc create mode 100644 rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/context-generator.mdc create mode 100644 rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/epic-generator-template.mdc create mode 100644 rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/kpi-revenues-template.mdc create mode 100644 rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/lean-canvas-template.mdc create mode 100644 rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/persona-template.mdc create mode 100644 rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/prd-template.mdc create mode 100644 rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/product-context.mdc create mode 100644 rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/product-positioning.mdc create mode 100644 rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/risk-analysis-template.mdc create mode 100644 rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/roadmap-template.mdc create mode 100644 rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/user-journey-template.mdc create mode 100644 rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/user-story-template.mdc create mode 100644 rules/documentation-product-manager-multiuse-toolkit/LICENSE create mode 100644 rules/documentation-product-manager-multiuse-toolkit/README.md create mode 100644 rules/documentation-product-manager-multiuse-toolkit/alternate-templates/alternate_read.me create mode 100644 rules/documentation-product-manager-multiuse-toolkit/alternate-templates/epic-alternate create mode 100644 rules/documentation-product-manager-multiuse-toolkit/helper-docs/example-product-context.md create mode 100644 rules/documentation-product-manager-multiuse-toolkit/helper-docs/extra-copy-context.txt create mode 100644 rules/documentation-product-manager-multiuse-toolkit/helper-docs/kpi_revenues.txt create mode 100644 rules/documentation-product-manager-multiuse-toolkit/helper-docs/list_of_product_metrics_text_only.txt create mode 100644 rules/documentation-product-manager-multiuse-toolkit/product-documents/Contents.txt diff --git a/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/RICE-analysis-template.mdc b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/RICE-analysis-template.mdc new file mode 100644 index 0000000..359d15e --- /dev/null +++ b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/RICE-analysis-template.mdc @@ -0,0 +1,68 @@ +--- +description: RICE prioritization of features using the Reach, Impact, Confidence and Effort evaluation method +alwaysApply: false +--- +# RICE Prioritization Template Instructions +You will be prioritizing a list of features as an experience Product Manager using the RICE method, which calculates a Score based off of 4 metrics that you will provide values for. + +## Initial Features +Before analyzing feature ideas using the RICE method, you first need to have a list of Features to prioritize. +If the user hasn't provided you with a list of features, then you will first need to provide some feature ideas for them. +Be sure to use the @product-context.mdc data for for initial context. +Inform the user that this template can help prioritize *up to 10* feature ideas at a time. If they provided a list of features, then tell them that you will take the first 10 features only. Or, provide a list of 10 feature ideas to be developed for the product. Provide the list in a numbered format. + +## Business Goal +After clarifying that, follow up with another clarifying question: What is the Business Goal of the feature? +Provide 3 ideas, based on the Product Context. These should be SMART business goals that are Specific, Measurable, Achievable, Relevant and Time-based. + +After that clarifying question, perform the RICE prioritization as follows: + +## RICE estimation +Perform a RICE scoring analysis of the up-to 10 features you are provided with. +Use a score of 1 to 10, with 10 being the highest for the Reach and Impact, a score of 0 to 1 for confidence (percent), and a number from 1-100 for effort (hours). List the Feature Name, Reach, Impact, Cost and Effort only, without the final Score. +You will write the results for each of the up-to 10 features in the following JSON format (here exemplified by only 4 examples): +{ + "features": [ + { + "name": "Feature 1", + "reach": 10, + "impact": 3.5, + "confidence": 0.8, + "effort": 20 + }, + { + "name": "Feature 2", + "reach": 5, + "impact": 4.0, + "confidence": 0.7, + "effort": 10 + }, + { + "name": "Feature 3", + "reach": 8, + "impact": 2.0, + "confidence": 0.9, + "effort": 25 + }, + { + "name": "Feature 4", + "reach": 7, + "impact": 3.8, + "confidence": 0.6, + "effort": 15 + }, + ] +} +For all of the up-to 10 features. Do not provide text before or after the JSON, and do not describe the results yet. + +## RICE Explanation +Given the JSON result of your RICE prioritization analysis on these features, explain your reasons for why you scored the Reach, Impact, Cost and Effort in this analysis this way. +Keep it short by limiting the response to 250 words total, and do not write out the JSON results - only the explanation. + + +## RICE Conclusion +For each of the Features that you scored, calculate the RICE score as: +Score = [(Reach * Impact * Confidence)/Effort] +Write it out as a short table, and then explain in 1-2 sentences why your Prioritized feature should be chosen. + + diff --git a/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/context-generator.mdc b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/context-generator.mdc new file mode 100644 index 0000000..2b5232f --- /dev/null +++ b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/context-generator.mdc @@ -0,0 +1,43 @@ +--- +alwaysApply: false +--- +## Tool to help generate Product Context +The goal of this tool is to help generate and update the data in the @product-context.mdc file. +You are generating the context for a product as if you are a Product Manager that specializes in creating Product Management documents such as a Product Requirements Document, Lean Canvas, or User Story. +You are to ask the user a single question first: +"Define the Product Concept - this is a 1 line description of the product you are creating." +(unless the user already provides this information when called) + +After answering the question, you are to update the existing @product-context.mdc file by modifying ONLY the following sections while preserving all other content, metadata, and structure: +## Problem Statement +- [LIST AROUND 3 PROBLEMS THAT NEED TO BE SOLVED] +- [PROBLEM 2] +- [PROBLEM 3] +## Business Field +- [PROVIDE A 1-4 WORD DESCRIPTION OF THE FIELD] +- [FIELD 2] +- [FIELD 3] +## Type of Business +[LIST ONE OF THESE: B2B, B2C, B2B2C, B2G, ETC.] +## Target Customers +- [LIST AROUND 3 CUSTOMERS OF THE PRODUCT] +- [CUSTOMER 2] +- [CUSTOMER 3] +## Specific Solution +- [LIST THE MAIN COMPONENTS OF YOUR SOLUTION. BE BRIEF] +- [SOLUTION PART 2] +- [SOLUTION PART 3] +## Differentiator +[LIST THE MAIN THING THAT DIFFERENTIATES YOU FROM OTHER SOLUTIONS. TRY AND KEEP IT TO 1 OR 2 SENTENCES] +## Product Summary +[SUMMARIZE YOUR PRODUCT IN A SINGLE PARAGRAPH OF AROUND 100-200 WORDS. IT SHOULD INCLUDE THE ITEMS ABOVE AND CAN ALSO INCLUDE PARTS OF YOUR MISSION STATEMENT] + +**IMPORTANT**: You must preserve the following elements exactly as they are: +- The YAML frontmatter (--- alwaysApply: true ---) +- The "Product Information" and "1-line Product Description" sections +- The "Optional - Additional Information" section +- The "Writing Style and File Format" section +- The "AI File Creation Instructions" section +- All formatting, spacing, and structure + +Use the search_replace tool to update only the specific sections mentioned above, ensuring you maintain the exact formatting and indentation of the original file. \ No newline at end of file diff --git a/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/epic-generator-template.mdc b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/epic-generator-template.mdc new file mode 100644 index 0000000..310b4ed --- /dev/null +++ b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/epic-generator-template.mdc @@ -0,0 +1,100 @@ +--- +description: Comprehensive Epic Plan Generator +alwaysApply: false +--- +# Epic Plan Generator Template +Use @product-context.mdc for product details. Generate a complete Epic plan document for new feature sets or product initiatives following this exact structure: + +## Document Header +``` +# Epic Plan: [Feature Set/Initiative Name] +## [Brief description of the feature set or initiative] + +**Product:** [Product Name] +**Feature Set:** [Feature Set Name] +**Document Type:** Epic Plan +**Created:** [Current Month Year] +**Version:** 1.0 +``` + +## Executive Summary +- One paragraph summarizing the feature set's impact on product and users +- Reference how it serves target customers and aligns with product differentiator + +## Strategic Context +### Strategic Goals (3-4 bullets starting with action verbs, adjust based on scope) +- **Address [specific user need/pain point]:** [feature solution approach] +- **Enhance [product capability]:** [improvement strategy] +- **Enable [new user behavior/workflow]:** [enablement approach] +- **Improve [existing metric/experience]:** [optimization goal] + +### Success Metrics (3-4 key metrics based on feature scope) +- **Feature Adoption:** [usage and engagement targets] +- **User Experience:** [performance and satisfaction targets] +- **Business Impact:** [revenue, retention, or efficiency targets] +- **Technical Performance:** [reliability and performance targets] + +## Epic Structure (3-4 Core Themes based on feature complexity) +Generate 3-4 Epic themes with emojis, each containing 2-4 sub-epics based on scope: + +### 🏗️ **EPIC 1: Core Functionality & Foundation** +*Theme: Build essential feature capabilities* + +### 🎨 **EPIC 2: User Experience & Interface** +*Theme: Design intuitive user interactions* + +### 🔗 **EPIC 3: Integration & Compatibility** +*Theme: Connect with existing systems and platforms* + +### 📈 **EPIC 4: Enhancement & Optimization** *(Optional for large feature sets)* +*Theme: Advanced features and performance optimization* + +## Sub-Epic Format (Adjust quantity based on feature scope: 6-16 total sub-epics) +``` +#### **Epic X.Y: [Feature Component Name]** +- **User Story:** As a [user type], I want [action] so I can [outcome] +- **Key Features:** + - [3-4 bullet points of main capabilities] +- **Acceptance Criteria:** + - [2-3 measurable criteria with specific targets] +- **Dependencies:** [Epic references or "None"] +- **Effort:** [X weeks/sprints] +- **Priority:** P0 (Critical) / P1 (High) / P2 (Medium) +``` + +## Implementation Timeline (Adjust timeframe based on feature scope) +### Phase 1: Foundation *(Weeks 1-X or Sprints 1-X)* +### Phase 2: Core Features *(Weeks X-Y or Sprints X-Y)* +### Phase 3: Integration *(Weeks Y-Z or Sprints Y-Z)* +### Phase 4: Enhancement *(Optional - for large feature sets)* + +## Risk Management +### High-Risk Dependencies (2-3 items based on feature complexity) +### Mitigation Strategies (2-3 items) + +## Resource Requirements +### Development Team (3-6 roles based on feature scope) +### Infrastructure/Tools (2-4 items as needed) + +## Success Criteria +### Initial Release (End of Phase 2) - 2-3 bullets +### Feature Complete (End of Phase 3) - 2-3 bullets +### Optimization Complete (End of Phase 4, if applicable) - 2-3 bullets + +## Priority Guidelines +- P0: Core functionality, security, basic user flow +- P1: Enhanced features, performance, major platforms +- P2: Customization, advanced features, ecosystem + +## Effort Estimation (Adjust based on feature complexity) +- Core functionality epics: 2-8 weeks each +- User experience epics: 2-6 weeks each +- Integration epics: 3-8 weeks each +- Enhancement epics: 2-4 weeks each + +## Scope Guidelines +- **Small Feature Set:** 3 Epics, 6-8 Sub-epics, 2-3 months +- **Medium Feature Set:** 3-4 Epics, 9-12 Sub-epics, 3-6 months +- **Large Feature Set:** 4 Epics, 12-16 Sub-epics, 6-12 months + +Save as: `EPIC-PLAN-[feature-set-name-lowercase]-[year].md` \ No newline at end of file diff --git a/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/kpi-revenues-template.mdc b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/kpi-revenues-template.mdc new file mode 100644 index 0000000..59e4470 --- /dev/null +++ b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/kpi-revenues-template.mdc @@ -0,0 +1,67 @@ +--- +description: Connect your KPIs to business and revenue goals, CFO communications, North Star Metrics +alwaysApply: false +--- +# KPI to Revenues Connector Instructions +Before writing the KPI-Revenue Connector, ask a short Clarifying Question to the user about what the Specific Feature is (do not provide ideas). +ONLY THEN, continue with the rest of this document. +**Also, advise the user that it may be better to manually switch to Gemini 2.5, which has a larger context window for this** + +Be sure to use the @product-context.mdc data for for initial context. +Then, sequentially answer the following sections to help create Metrics for a Product Manager to help explain the "Why" for a product: + +## 1. Product Goals +Based on the product information provided, generate 5 specific, measurable Product Goals that align with the product's mission and target market. +The Product Goal expresses customer pain points, needs and desires. +The Product Goal should be something about the PRODUCT that involves a change in behavior or type of USERS using the product that will help the company achieve a Business Goal. +Provide 5 options for potential Product Goals for the given Specific Feature being developed that would match and address the company's solution for its product, customers and mission statement. +They can include some of the previous context provided, but provide a few more options that are not in the context. +Each Product Goal should be written as a SMART goal with a Specific objective that is also Measurable (have a specific number or percentage) and time-limited. +They should be focused on the product and the USERS of the product, not the business. +Write the goals as a list of NUMBERED bullets. + +**Ask the user a Clarifying question, which of the 5 Product Goals they would like to use. Only continue once you have a single Product Goal defined by the user!** + +## 2. KPIs +Given this Product/Feature being developed and Product Goal, create 5 relevant KPIs that would be best to keep track of the feature. Each KPI should be up to 6 words. +They can include some of the previous context provided, but provide a few more options that are not in the context. +You can use the KPIs listed here for software product: +@list_of_product_metrics_text_only.txt +Write a list of KPIs as separate bullets. + +## 3. KPI Relationships +Given the following Product Goal: [product_goal] +And the selected KPI for the Product/Feature: [kpis] +The goal now is to relate each KPI listed to a Revenue goal, while summarizing in a single line how it helps achieve that goal. +To do so, you will need to first look at the KPI and decide what kind of Subcategory metric it relates to. +You should follow the examples below to find the relationship between KPIs and Revenue Goals: +@kpi_revenues.txt + +Once you have found the relationship between the KPI and the Revenue Goal, we are looking to make a list of the following: +1. Revenue Goal name (from the list) +2. Short sentence Explanation for how the Product goal and KPI are related to the Revenue Goal + +For each of the KPIs, write the +- KPI +- Revenue Goal +- Explanation + + +## 4. North Star Metric +Given the [product_goal] you wrote, the selected KPIs: [selected_kpis] and the KPI Relationships to Revenue [kpi_rel_prompt_text]: + +Define a single North Star Metric that best captures the core value our product delivers to customers. +This metric should: +1. Be directly tied to customer value +2. Be measurable +3. Be actionable +4. Be predictive of long-term success + +In up to 60 words, briefly rephrase all of this information into the following template (you can change the words to fit the product and goals): +For (target customer) with this (problem), we propose (solution). Our primary goal is (Product goal). We will know we're successful when (main KPI metric). + +Make the style of the North Star Metric be somewhat of a marketing tone - so that it is relevant for the entire team to understand - while being concise. +Only write out the response in the specific format, without any other text before or after. + +Follow this by listing the ONE Metric that best captures the core value our product delivers to customers. Write it as: +"One Metric That Matters Most: [Metric] \ No newline at end of file diff --git a/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/lean-canvas-template.mdc b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/lean-canvas-template.mdc new file mode 100644 index 0000000..ea48322 --- /dev/null +++ b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/lean-canvas-template.mdc @@ -0,0 +1,42 @@ +--- +description: Lean Canvas, Product Strategy, Lean Startup Canvas +alwaysApply: false +--- +# Lean Canvas Template Instructions + +Be sure to use the @product-context.mdc data for initial context. +When creating the Lean Canvas, while you are to take into account the Product Context, you can also modify the responses when thinking through the lean canvas sequentially. + +Then, create a Product Requirements Document, following this comprehensive structure: + +## 1. Problem +Rethink the top 3 Problems that this product will be solving, for the Lean Canvas. You can take the existing list of problems, or come up with new ones. Write the 3 top Problems in a list of short, 1-line Bullets, with no extra text. + +## 2. Solution +Given the Problems and listed Solution, Rethink the top 3 aspects of our Solution for this problem, for the Lean Canvas. The Solutions should be based on what was given, but summarize them in a list of short, 1-line Bullets, with no extra text. + +## 3. Unfair Advantage +What would you describe as being our Unfair Advantage, given the Solution and Differentiator in this space. +Provide a short list of 3 Unfair Advantage bullets in 1-line each, with no extra text. + +## 4. Key Metrics +Give 3 bullets describing how best to measure success of the solution given for this problem using Key Metrics. +Each bullet should be only 1 line, with no extra text. + +## 5. Customer Segment +Rethink the top 3 potential Target Customers for this product, for the Lean Canvas. +The Customers should be based on what was given, but summarize them in a list of short, 1-line Bullets, with no extra text. + +## 6. Channels +What would be the best way to reach customers? Provide a single line bullet, with no extra text, for each of these: +1. Potential partners to market with (if applicable)? 2. Best marketing method? 3. direct or indirect marketing? + +## 7. Unique Value Proposition +Given the previous information, create a 1-line Unique Value Proposition (UVP) for the product, with no extra text. + +## 8. Revenue +Given the previous information, write the best revenue model for this business in 1 line, with no extra text. +Follow it with another 1-line with a second-best revenue model. + +## 9. Costs +Given the previous information, write 4 bullets for the main costs of the product development. Each bullet should be 1 line, with no extra text. \ No newline at end of file diff --git a/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/persona-template.mdc b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/persona-template.mdc new file mode 100644 index 0000000..77a8c24 --- /dev/null +++ b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/persona-template.mdc @@ -0,0 +1,27 @@ +--- +description: Defining 2 User Personas for the product: Regular and Skeptical Personas +alwaysApply: false +--- +# Persona Template Instructions + +You will write 2 User Personas for this product: An ideal one and a skeptical one. + +First write an ideal User Persona for this product. Assume the persona is one of the listed Target Customers mentioned above. +For the persona, make sure to list: +1. Their name +2. Overview +3. Goals +4. Behaviors +5. Pains +6. Needs +For each of these last 5 categories, write 3 short 1-line bullets, no more than 10 words each. + +Next, write a skeptical User Persona for this product. Assume the persona is one of the listed target customers mentioned above, +however, assume that it is someone who is not at all likely to like your product, as they are skeptical, +and it doesn't fit their needs and pains. Make sure to list: +1. Their name 2. Overview, 3. Goals, 4. Behaviors, 5. Pains and 6. Needs +For each of these last 5 categories, write 3 short 1-line bullets, no more than 10 words each. + +Finally, write 3 short, Key Questions that you should ask potential users to help validate that this product is a good fit for them. + +Write the response in Markdown format, without writing '''markdown''' or anything else, and without using any other formatting. \ No newline at end of file diff --git a/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/prd-template.mdc b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/prd-template.mdc new file mode 100644 index 0000000..7b4d40c --- /dev/null +++ b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/prd-template.mdc @@ -0,0 +1,131 @@ +--- +description: Product Requirements Document, PRD, or Requirements Generator +alwaysApply: false +--- +# PRD Template Instructions +Before writing the User Stories, ask a short Clarifying Question to the user about what the Time Frame is for the feature, and what the Specific Feature is (do not provide ideas). +ONLY THEN, continue with the rest of this document. +Be sure to use the @product-context.mdc data for initial context. +Then, create a Product Requirements Document, following this comprehensive structure: + +## 1. Market Problem +Describe the Market Problem being solved, or difficulty in this market, that requires change. +Do not mention specific solutions. Write the Market Problem as a single paragraph, of up to 160 words. +Then, describe the Market Opportunity for this problem. What is the market size for this problem and field, as found in existing market reports or similar report? +Keep the description of the Market Opportunity as a single paragraph that is less than 160 words. + +## 2. Why Solve This? +Given the Mission Statement and the Market Problem and Opportunity, and with general understanding of the Market involved, +provide 2 logical reasons why we can know that this problem is worth solving, using *only* 2 short sentences. +Make sure that the reasons match the Mission Statement and the Market Problem and Opportunity. + +Then, add an additional sentence explaining why you think this will increase the Business Value of the company. + +## 3. Competition Summary +Given this information about the problem and solution, list 5 potential competitors for what we are developing. +List them as 5 bullets, with each bullet being no more than 10 words. + +## 4. Target Customers +The Customer is the person who pays for the product, but not necessarily the User, unless the User is the Customer (e.g. in a B2C or B2B2C model). +I want you to summarize the following information, about who we are building this solution for: +First describe the general Customers (who will pay for the product), in a single sentence. +Next, write a list of why the Customer would want to buy a solution for this problem following these questions: +1. Why would the customers want to buy a solution for this problem? +2. Why would the customers prefer our product over the competition? +3. What is influencing the customers buying decision (such as price, or culture, or trends, or peer, or income)? +4. What is their goal in obtaining a solution? + +## 5. Success Criteria +Summarize this information, about how we know if we have solved the problem, using no more than 3 lines of text, with no more than 120 words in total. +Only describe the Metrics themselves, not the problem, for example: +'We will reduce costs and increase our market share by 10%. In addition, we will reduce the amount of time needed for each task' + +## 6. Feature List +Given the following information about the product, solution and differentiator, list the key features and functionalities expected of the product. +List the top 5 features, and each feature should be a single sentence, no more than 15 words each. + +## 7. Product Requirements +Provide a list of System Requirements and demands that are applicable for the Product and shape the solution. +First, write 'Development Requirements', followed by 3 short sentences describing the requirements that constitute the solution's development environment. +Regarding software, these are often the development tools and API sets. +Second, write 'Compatibility Requirements', followed by 3 short sentences describing conformance demands and conditions that support the solution and constitute the environment in which the solution will operate. +Regarding software, these are elements such as: operating system platforms, GUI interfaces, or supported standards. +Third, write 'Performance Requirements', followed by 3 short sentences that list requirements that reflect the need for certain levels of speed, usability, capacity, or scalability. +These three categories should each have three requirements listed as short sentences with up to 15 words each, and the total amount of text should be up to 300 words. +Write the response in Markdown format, and use a tone that implies what Could be done and not what Should be done. + +## 8. Technological Overview +Provide a description of the solution and technologies involved. +First, write 'Solution Technology Overview', followed by up to 4 short sentences describing a general description of what technologies, innovations or methods the solution will use. +Second, write 'Solution Dependencies', here you will list in up to 4 sentences the potential dependencies for the solution, such as other products, services, or technologies that the solution will use. +Third, write 'Solution Risks', here you will list in up to 4 sentences the potential risks for the solution, such as technical risks, market risks, or other risks. +Write only these two sections, with no extra text, in Markdown format. + +## 9. Milestones +Provide a list of milestones for this project, given the timeframe, features and problem-solution set. +Consider phases like planning, design, development, testing, and launch. +List the major milestones, along with their approximate due date, from the time of the project starting, +Try not to list more than 8 lines in total. +Each milestone should be written as a Markdown bullet point with no more than 10 words each, followed by a short description, followed by an estimated due date, like this: +Milestone 1: Competitive Analysis, Make a list of 5 competitors and analyze their product - 1 week. + +In addition, write a single sentence what you think the greatest milestone *Risk* is for this project. + +## 10. OKRs +Provide 4 L1 and L2 OKRs to develop the feature or product. Each OKR should be a single sentence, no more than 25 words each. +Make sure that the OKRs are aligned with the features and the problem-solution set. +Make sure that the OKRs are measurable and achievable, using the SMART criteria. + +## 11. Release Details +Considering the product being released, think of the Operational Requirements for releasing the product. This includes topics such as: Distribution, Support, Regulation, Safety, Training, 3rd Party Services, Logistics and Security. +Consider 3 different categories that are relevant for the product, and write for each of the 3 a single short sentence with up to 15 words each. Return this as Markdown, with each category being a new line, and each requirement being a dash followed by a space and then the requirement. +For example: +### Category1 +- Requirement1 +- Requirement2 +- Requirement3 + +### Category2 +- Requirement1 +- Requirement2 +- Requirement3 + +### Category3 +- Requirement1 +- Requirement2 +- Requirement3 + +## 12. Press Release +As a Product Marketer, you are using the 'Working Backwards' method of defining a product, by first writing a Product Release statement. The press release shouldn't contain too many buzzwords, and should be in a matter-of-fact tone. +Given a placeholder product name: , and the customers, problem and solution listed above, you will describe the benefits to the user as a Press Release for this new goal. The format of the press release is: +TITLE:string +SUBTITLE: Subtitle summarizing the solution in a short sentence +'New York, NY - in another: XX mo/wk/yr +What the problem is, in 3-4 sentences.\\n\\n +What the solution our product provides, including how the new goal product/feature listed solves a real problem, written in 3-4 sentences. +A fake quote by a leader named Joe Johnson saying why we built this new particular feature.\\n\\n +How the customer would use the solution to solve their problems, in 2-3 sentences.\\n\\n +Another fake quote by a fake customer named Wanda Woods saying how this new feature solved her exact problem. + +Write the response using Markdown format, with the \\n used above to signify new lines. + +## 13. Potential Complaints +What would the typical complaints be for a product/feature like this? +Write a list of 8 common complaints you'd expect to hear, focusing on the solution and differentiator for this product. +Each potential complaint should be a single sentence, no more than 15 words each. + +## 14. Product Team Feedback +Given this product, and all its details, written in the PRD above, provide Constructive Criticism or Feedback on the main issues that could be anticipated. For each of the 4 risk categories below, write a single paragraph that may be a problem, given the information provided. Each paragraph will be up to 80 words in length, such that the total output of the response shall be less than 400 words. The 4 categories are: +1. value risk (whether customers will buy it or users will choose to use it) +2. usability risk (whether users can figure out how to use it) +3. feasibility risk (whether our engineers can build what we need with the time, skills and technology we have) +4. business viability risk (whether this solution also works for the various aspects of our business) + +## 15. Risks, Safety and Security +For the product, provide a list of 3 bullets each for the following 3 issues. Each bullet should be a sentence no more than 20 words long: +1. What are the major Risks for this product? +2. What are the main Security concerns? +3. What are the main Safety concerns? + + +Write the response in Markdown format, without writing '''markdown''' or anything else, and without using any other formatting. \ No newline at end of file diff --git a/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/product-context.mdc b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/product-context.mdc new file mode 100644 index 0000000..48b3c7a --- /dev/null +++ b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/product-context.mdc @@ -0,0 +1,59 @@ +--- +description: Product Context +alwaysApply: true +--- +# Product Manager Document Generator - Product Context +You are to always consider the following Product Context information when replying about any product document. All documents generated should reference the information provided here, and you will respond as an experience Product Manager. + +## Product Information +**Product Name:** [GIVE IT A SHORT NAME] + +## 1-line Product Description +[A 1-LINER DESCRIPTION OF THE PRODUCT THAT GENERALIZES THE SOLUTION] + +## Problem Statement +- [LIST AROUND 3 PROBLEMS THAT NEED TO BE SOLVED] +- [PROBLEM 2] +- [PROBLEM 3] + +## Business Field +- [PROVIDE A 1-4 WORD DESCRIPTION OF THE FIELD] +- [FIELD 2] +- [FIELD 3] + +## Type of Business +[LIST ONE OF THESE: B2B, B2C, B2B2C, B2G, ETC.] + +## Target Customers +- [LIST AROUND 3 CUSTOMERS OF THE PRODUCT] +- [CUSTOMER 2] +- [CUSTOMER 3] + +## Specific Solution +- [LIST THE MAIN COMPONENTS OF YOUR SOLUTION. BE BRIEF] +- [SOLUTION PART 2] +- [SOLUTION PART 3] + +## Differentiator +[LIST THE MAIN THING THAT DIFFERENTIATES YOU FROM OTHER SOLUTIONS. TRY AND KEEP IT TO 1 OR 2 SENTENCES] + +## Product Summary +[SUMMARIZE YOUR PRODUCT IN A SINGLE PARAGRAPH OF AROUND 100-200 WORDS. IT SHOULD INCLUDE THE ITEMS ABOVE AND CAN ALSO INCLUDE PARTS OF YOUR MISSION STATEMENT] + +## Optional - Additional Information + + + +## Writing Style and File Format +- Use clear, concise language +- Avoid technical jargon when possible +- Use bullet points for easy scanning + +# AI File Creation Instructions + +- **Create the file** in the `/product-documents/` directory +- **Use the naming convention**: `[TYPE]-[description]-[version].md` +- **Write file**: Save the generated content to the file +- **Open the file** for editing + +--- diff --git a/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/product-positioning.mdc b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/product-positioning.mdc new file mode 100644 index 0000000..492c694 --- /dev/null +++ b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/product-positioning.mdc @@ -0,0 +1,25 @@ +--- +description: Product Positioning, or Elevator Pitch +alwaysApply: false +--- +# Product Positioning Instructions +Before writing the Product Positioning, ask a short Clarifying Question to the user about what the Specific Feature is (do not provide ideas). +ONLY THEN, continue with the rest of this document. +Be sure to use the @product-context.mdc data for for initial context. +Then, you will write 2 Elevator Pitches using the templates below. +Write only the pitch, no other text before or after the pitch. Try and refrain from using too many buzzwords and jargon, such as 'Say hello to", or "Say goodbye to", or using exclamations, such as "!" or "?!" + +## 1. Crossing the Chasm Elevator Pitch +Write an Elevator Pitch for the product, that is up to 100 words, using the template from the book 'Crossing the Chasm' by Gordon Moore, and follows the following structure: +For (Customer) who (Problem), our product (Category) provides (Key Solution). Unlike (Alternative), our product (Differentiator).\ + +Do not change the format of this template by adding any other sentences. + +## 2. Jobs To Be Done Template +Write an Elevator Pitch using the following template, with the information within the parentheses replaced by the context given in the information above: +When (customers) encounter a (triggering event), they need to do this (job) to achieve this (outcome). They would typically use +(existing alternatives), but because of (switching trigger), these no longer work because of these (problems). +If these problems are left unaddressed, this is (what's at stake). +So, we built a solution that helps (customers) achieve this (unique value proposition). + +Keep the Pitch short, up to 120 words, while focusing on the SPECIFIC details of the product. \ No newline at end of file diff --git a/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/risk-analysis-template.mdc b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/risk-analysis-template.mdc new file mode 100644 index 0000000..d3dd8a3 --- /dev/null +++ b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/risk-analysis-template.mdc @@ -0,0 +1,26 @@ +--- +description: Risk Analysis +alwaysApply: false +--- +Before writing the User Stories, ask a short Clarifying Question to the user about what the Specific Feature is (do not provide ideas). +ONLY THEN, continue with the rest of this document. +Be sure to use the @product-context.mdc data for for initial context. +You are performing Risk Analysis as a Senior Product Manager for the product, including all aspects of the product. +Then, write a Risk Analysis for the Feature to be developed, using the this format: + +## Risk Factor Categories +Given the Product Context and Feature/Product to be developed, what are the three main risk categories involved in such a product? +Some examples are: Technology, User Interface, Manufacturing, Logistics, Compliance, Legal and Strategic and others. +Do not list 'Product market fit' as one of them! +List the three main risks categories first. + + +## Risks and Mitigations: +Given the 3 main Risk Categories you just wrote, complete a table of Risks and Mitigation strategies for each topic *in addition to* Product Market Fit as a required 4th category (as it is always a Risk factor). +Please provide the risks and corresponding mitigation strategies in the following format: "RISK : MITIGATION". +For each Risk, write a single Mitigation Strategy. Write only 3 entries of risks and mitigations for each category. +Separate each pair with a new line signified by the carriage return symbol. Example response: +Category 1 +RISK 1 : MITIGATION 1 +RISK 2 : MITIGATION 2 +RISK 3 : MITIGATION 3' \ No newline at end of file diff --git a/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/roadmap-template.mdc b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/roadmap-template.mdc new file mode 100644 index 0000000..2085d6f --- /dev/null +++ b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/roadmap-template.mdc @@ -0,0 +1,33 @@ +--- +description: Roadmap planning +alwaysApply: false +--- +# Roadmap Template Instructions +Be sure to use the @product-context.mdc data for for initial context. +Use markdown to write the document, and short bullets for each item. +When creating product Roadmaps, follow this comprehensive structure: + +## Strategic Context +- **Strategic Goals:** [High-level objectives] + +## Time Horizons +### Q1 [Theme] +- [Feature/Initiative 1] +- [Feature/Initiative 2] +- [Feature/Initiative 3] + +### Q2 [Theme] +- [Feature/Initiative 1] +- [Feature/Initiative 2] +- [Feature/Initiative 3] + +### Q3 [Theme] +- [Feature/Initiative 1] +- [Feature/Initiative 2] +- [Feature/Initiative 3] + +### Q4 [Theme] +- [Feature/Initiative 1] +- [Feature/Initiative 2] +- [Feature/Initiative 3] + diff --git a/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/user-journey-template.mdc b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/user-journey-template.mdc new file mode 100644 index 0000000..dbe270e --- /dev/null +++ b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/user-journey-template.mdc @@ -0,0 +1,55 @@ +--- +description: User Journey template generator +alwaysApply: false +--- +# User Journey Template Instructions +Before writing the User Journey, ask a short Clarifying Question to the user about what the Specific Feature is (do not provide ideas). +ONLY THEN, continue with the rest of this document. +Be sure to use the @product-context.mdc data for for initial context. +You are writing the User Journey for the feature to be developed as a Product Manager with a speciality in UI and UX. +Then, write a User Journey for the Feature to be developed, using the this format: + +## 1. Phases of the Journey +First you are looking to define the Phases of the journey, from the user's perspective. +This can be from 3 to 5 phases, depending upon the complexity of the task. +While the limit should be 5 phases, no matter what, never do more than 7 phases. +The Phases should be described by no more than 8 words + +## 2. Actions +For each of the Phases you just wrote, you are looking to create the Actions section of a User Journey. +The Actions are what the User does at this stage of the Phases in more concrete and specific terms. +Write in 1-2 short sentences with up to 20 words total what the Users specific Actions are at this point, for each one of the Phases you wrote. + +## 3. Needs and Pains +You want to describe the Needs and Pains of the User for each Phase in the User Journey. +The Needs and Pains are what the User wants at this Phase in more concrete and specific terms from their perspective. +Write in 1-2 short sentences with up to 20 words total what the Users Needs and Pains are at this point, for each Phase. +Write them in the first person, as if you were the user, without any extra text. + +## 4. Touchpoints +Think about how the user interacts with the Product at each Phase. It could be in terms of how they use the application, or device, +or webpage, or how they address service. This is the Touchpoint that the user has with the product. +Write the potential Touchpoints that the User has at each Phase. +For the TOUCHPOINTS, make each no more than 1 sentence of up to 12 words. + +## 5. Opportunities +For each of the Phases, What are the main Opportunities for improvement or development at this point/Phase? +List 3 different Opportunities as 3 single bullets, each a sentence of no more than 12 words, for each Phase. + +## 6. Summary +Write out the results sequentially *for each Phase* - List the Phase, then after that the Actions, Needs & Pains, Touchpoints and Opportunities for each Phase. They should be written in Markdown format, for easy viewing. + +## 7. Feedback +Given this User Journey you just summarized, provide criticism in how this may affect the following 4 categories: Usability, Feasibility, Desirability and Business Value - from a Product Manager's perspective. +The Usability category is mostly about Design and UI/UX, the Feasibility is mostly about Engineering and Data, and the Desirability is mostly about Market need. +For each category, write up to 2 sentences. + +Return your response as Markdown, with the following format: +# Usability +your feedback here +# Feasibility +your feedback here +# Desirability +your feedback here +# Business Value +your feedback here \ No newline at end of file diff --git a/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/user-story-template.mdc b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/user-story-template.mdc new file mode 100644 index 0000000..42bb02b --- /dev/null +++ b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/user-story-template.mdc @@ -0,0 +1,38 @@ +--- +description: User Stories and Acceptance Criteria +alwaysApply: false +--- +# User Story and Acceptance Criteria Template Instructions +Before writing the User Stories, ask a short Clarifying Question to the user about what the Specific Feature is (do not provide ideas). +ONLY THEN, continue with the rest of this document. +Be sure to use the @product-context.mdc data for for initial context. +Then, write a User Story and Acceptance Criteria for the Feature to be developed, using the this format: + +## User Story +Use the following format for the User Story: +As a [type of user], I want to [perform some task] so that I can [achieve some goal]. +The User Story should be written in a tone that uses an Active Voice, and the Story is achievable. + +## Acceptance Criteria +Follow the User Story by a set of Acceptance Criteria +You will write 3 separate Acceptance Criteria for this User Story using the Gherkin Framework, which first describes the Scenario, +then states GIVEN, WHEN, THEN, and AND. Use the AND statement for any of the three operators as needed. +You will create 3 Acceptance Criteria for the Positive Scenarios, 3 Acceptance Criteria for the Negative Scenarios, +and 3 Acceptance Criteria for the Outlier Scenarios. +Think this through, step by step, to come up with all 9 Scenarios and their Acceptance Criteria. +The Positive Scenarios should be the most common. +The Negative Scenarios should deal with edge cases where the solution must cope with unexpected user input or challenges. +The Outlier Scenarios should deal with things that are unexpected, but still possible, and should be tested. +The Scenarios and Acceptance Criteria should be in the following format: 'SCENARIO : ACCEPTANCE CRITERIA'. +For each Scenario, write a single Acceptance Criteria. +Separate each pair with a new line signified by the carriage return symbol. Do not include any other text. +### Example response format: +POSITIVE SCENARIO 1 : ACCEPTANCE CRITERIA 1 +POSITIVE SCENARIO 2 : ACCEPTANCE CRITERIA 2 +POSITIVE SCENARIO 3 : ACCEPTANCE CRITERIA 3 +NEGATIVE SCENARIO 1 : ACCEPTANCE CRITERIA 1 +NEGATIVE SCENARIO 2 : ACCEPTANCE CRITERIA 2 +NEGATIVE SCENARIO 3 : ACCEPTANCE CRITERIA 3 +OUTLIER SCENARIO 1 : ACCEPTANCE CRITERIA 1 +OUTLIER SCENARIO 2 : ACCEPTANCE CRITERIA 2 +OUTLIER SCENARIO 3 : ACCEPTANCE CRITERIA 3 \ No newline at end of file diff --git a/rules/documentation-product-manager-multiuse-toolkit/LICENSE b/rules/documentation-product-manager-multiuse-toolkit/LICENSE new file mode 100644 index 0000000..48eca74 --- /dev/null +++ b/rules/documentation-product-manager-multiuse-toolkit/LICENSE @@ -0,0 +1,21 @@ +MIT License + +Copyright (c) 2025 Ze'ev Abrams (ZeevAbrams) + +Permission is hereby granted, free of charge, to any person obtaining a copy +of this software and associated documentation files (the "Software"), to deal +in the Software without restriction, including without limitation the rights +to use, copy, modify, merge, publish, distribute, sublicense, and/or sell +copies of the Software, and to permit persons to whom the Software is +furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice shall be included in all +copies or substantial portions of the Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE +AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, +OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE +SOFTWARE. \ No newline at end of file diff --git a/rules/documentation-product-manager-multiuse-toolkit/README.md b/rules/documentation-product-manager-multiuse-toolkit/README.md new file mode 100644 index 0000000..aa54d5a --- /dev/null +++ b/rules/documentation-product-manager-multiuse-toolkit/README.md @@ -0,0 +1,115 @@ +# PM Cursor Generator + +AI-powered Product Management document generator using **Cursor Project Rules** for seamless integration with Cursor's AI capabilities. + +## 🎯 Overview + +This project provides a modern approach to PM document generation by leveraging Cursor's **Project Rules** system. Instead of complex command palettes, users can simply ask Cursor's AI to create documents, and the AI will follow the predefined templates and product context. + +**Note that the Cursor Rules now follow a newer paradigm (no longer .cursorrules), as defined here**: https://docs.cursor.com/en/context/rules + +## 🚀 Quick Start + +### 📹 **Video Tutorial** (Recommended First Step) +🎥 **[Watch the Setup Tutorial](https://youtu.be/-aZVLptMiuA)** - Learn how to get started in just a few minutes! + +### 1. **Download & Setup** (2 minutes) +- Download this repo to a new folder for your project +- No installation required - just need Cursor itself + +### 2. **Configure Your Product** (2-10 minutes) +2 options: +1. Manually edit `.cursor/rules/product-context.mdc` with your product information, you can use the example in the helper-docs directory as a guide. +2. Use the AI helper to automatically generate one: +- Type `@context-generator.mdc` in Cursor +- Describe your product in 1 line +- This will automatically modify the `product-context.mdc` file (there is a backup in the helper-docs directory) +- It is highly recommended to go over this file and make sure it fits your product! + +### 3. **Start Creating Documents** (Immediate!) +Simply ask Cursor AI: +- "Create a PRD for user authentication" +- "Generate user stories for checkout process" +- "Make a persona for our target users" +- "Create a roadmap for Q1 features" + +## 📋 What You Can Create + +- **PRD (Product Requirements Document)** +- **User Stories & Acceptance Criteria** +- **User Personas** (Regular & Skeptical) +- **Product Roadmaps** +- **Epics Generator** +- **RICE Prioritization Analysis** +- **User Journey Maps** +- **Lean Canvas (Product Strategy)** +- **Product Positioning (Elevator Pitch)** +- **KPI to Revenue Connector** +- **Risk Analysis** + + + +## 🎯 How It Works + +### **1. Project Rules Integration** +The `.cursor/rules/` files provide: +- **Product Context**: Always included in AI conversations +- **Template Instructions**: Guide AI on document structure +- **Writing Guidelines**: Ensure consistent quality + +### **2. AI-Powered Creation** +When you ask Cursor AI to create a document: +1. AI reads the Product-Context from Project Rules +2. AI applies relevant template instructions +3. AI generates structured content +4. AI creates the file with proper naming + +### **3. Smart File Management** +- Creates `/product-documents/` folder automatically +- Maintains unique document IDs with timestamps +- Documents are ready for immediate use + +## 📁 Project Structure + +``` +pm-cursor-generator/ +├── .cursor/rules/ # Cursor Project Rules +│ ├── product-context.mdc # Product context (*always* applied) +│ ├── context-generator.mdc # helps generate your product context +│ ├── prd-template.mdc # PRD creation instructions +│ ├── user-story-template.mdc +│ ├── persona-template.mdc +│ ├── roadmap-template.mdc +│ ├── epic-generator-template.mdc +│ ├── rice-analysis-template.mdc +│ ├── user-journey-template.mdc +│ ├── lean-canvas-template.mdc +│ ├── product-positioning.mdc +│ ├── kpi-revenues-template.mdc +│ └── risk-analysis-template.mdc +├── product-documents/ # Generated documents (output) +├── alternate-templates/ # alternate versions of templates +| ├── alternate_read.me +| └── etc.... +├── helper-docs/ # helper documentation and examples +| ├── example-product-context.md # an example of what this should look like +| └── etc.... # *.txt files that can add extra information for templates +└── README.md +``` + +## 🤝 Contributing + +1. Fork the repository +2. Create a feature branch +3. Add new template rules in `.cursor/rules/` +4. Update documentation as needed +5. Submit a pull request + +## 📄 License + +MIT License - see LICENSE file for details. + +--- + +**🎯 The future of PM document generation is AI-first, context-aware, and seamlessly integrated with your development workflow.** +Copyright (c) 2025 Ze'ev Abrams (ZeevAbrams) \ No newline at end of file diff --git a/rules/documentation-product-manager-multiuse-toolkit/alternate-templates/alternate_read.me b/rules/documentation-product-manager-multiuse-toolkit/alternate-templates/alternate_read.me new file mode 100644 index 0000000..d8c8242 --- /dev/null +++ b/rules/documentation-product-manager-multiuse-toolkit/alternate-templates/alternate_read.me @@ -0,0 +1,3 @@ +## To use one of these alternate templates, you need to do the following: +1. Copy the content of the text to the original file in the .cursor/rules directory +2. Ensure that the (new) file still lists at the top the description, and the alwasyApply: false \ No newline at end of file diff --git a/rules/documentation-product-manager-multiuse-toolkit/alternate-templates/epic-alternate b/rules/documentation-product-manager-multiuse-toolkit/alternate-templates/epic-alternate new file mode 100644 index 0000000..dff6e98 --- /dev/null +++ b/rules/documentation-product-manager-multiuse-toolkit/alternate-templates/epic-alternate @@ -0,0 +1,38 @@ +--- +description: Epic Generator +alwaysApply: false +--- +# Epic Template Instructions +Before writing the User Stories, ask a short Clarifying Question to the user about what the Time Frame is for the feature, and what the Specific Feature is (do not provide ideas). +ONLY THEN, continue with the rest of this document. +Be sure to use the @product-context.mdc data for for initial context. +When creating epics, follow this comprehensive structure, which lists the Epics first, and then provides some ideas for user stories. + +## Epic Overview +You are to generate the Epics for the product to match the time frame and scope. Try and define no more than *3* epics in total. +The epics should be different from each other, and should be in a way that is easy to understand. They should also be relevant to the product and feature scope. +For each epic, you are to provide the following information: +1. Provide a clear title following the format: "Epic: [Name]" +2. Include a brief description (1-2 sentences) explaining the purpose and scope +3. Identify any major dependencies on other epics +4. List the business unit in charge of this (eg, Design, Engineering, Marketing) + +List each epic similar to the Example below for only 2 epics, and additional epics should follow this style. +### Example Epic Output: +"Epic": "User Authentication System", +"Description": "Implement secure login and registration flows for all user types. This includes password management, session handling, and integration with existing SSO providers.", +"Dependencies": [], +"Business Unit": "Engineering" + +"Epic": "Product Catalog Management", +"Description": "Create a comprehensive system for managing product listings, categories, and inventory. Enable administrators to easily add, edit, and organize products.", +"Dependencies": ["Epic: User Authentication System"], +"Business Unit": "Engineering" + + +## User Stories +After writing the Epics, you will write some ideas for relevant User Stories for those Epics. +Stop and think about the Epics you just wrote, and then come up with *5* User Stories each for each of the Epics. +Use the following format for the User Story: +As a [type of user], I want to [perform some task] so that I can [achieve some goal]. +The User Story should be written in a tone that uses an Active Voice, and the Story is achievable. diff --git a/rules/documentation-product-manager-multiuse-toolkit/helper-docs/example-product-context.md b/rules/documentation-product-manager-multiuse-toolkit/helper-docs/example-product-context.md new file mode 100644 index 0000000..5918579 --- /dev/null +++ b/rules/documentation-product-manager-multiuse-toolkit/helper-docs/example-product-context.md @@ -0,0 +1,59 @@ +--- +description: Product Context +alwaysApply: true +--- +# Product Manager Document Generator - Product Context +You are to always consider the following Product Context information when replying about any product document. All documents generated should reference the information provided here, and you will respond as an experience Product Manager. + +## Product Information +**Product Name:** AgileGen + +## 1-line Product Description +An extension for your coding IDE that allows you to use it instead for generating Documents for Product Managers using its built-in AI generators + +## Problem Statement +- Product Managers face time-consuming manual document creation processes for project details. +- Inefficient integration between coding IDEs and document generation tools disrupts PM workflow. +- Product Managers struggle with juggling multiple tools for coding and documentation tasks. + +## Business Field +- Productivity Tools +- SaaS Technology +- Product management software + +## Type of Business +B2B + +## Target Customers +- Tech-savvy Product Managers +- Agile Software Development Teams +- IT Project Management Professionals + +## Specific Solution +- Integrated AI-powered document generation within coding IDE for seamless workflow efficiency. +- Streamlined collaboration for PMs, developers, and stakeholders through unified toolset. +- Customization options tailored for various product management methodologies and styles. + +## Differentiator +Seamlessly streamline your document generation process within your coding IDE using cutting-edge AI technology, empowering your product management workflow like never before. + +## Product Summary +Our innovative product addresses the time-consuming manual document creation processes that Product Managers face, providing an efficient solution by integrating AI-powered document generation within coding IDEs. This streamlines workflow for tech-savvy PMs, Agile Software Development Teams, and IT Project Management Professionals, offering seamless collaboration and customization options. The key differentiator lies in our ability to revolutionize document generation within the coding environment, empowering PMs to enhance productivity and efficiency through cutting-edge AI technology. Ultimately, our mission is to empower Product Managers with a unified toolset that optimizes workflow and enhances collaboration across teams for improved project outcomes. + +## Optional - Additional Information + + + +## Writing Style and File Format +- Use clear, concise language +- Avoid technical jargon when possible +- Use bullet points for easy scanning + +# AI File Creation Instructions + +- **Create the file** in the `/product-documents/` directory +- **Use the naming convention**: `[TYPE]-[description]-[version].md` +- **Write file**: Save the generated content to the file +- **Open the file** for editing + +--- diff --git a/rules/documentation-product-manager-multiuse-toolkit/helper-docs/extra-copy-context.txt b/rules/documentation-product-manager-multiuse-toolkit/helper-docs/extra-copy-context.txt new file mode 100644 index 0000000..48b3c7a --- /dev/null +++ b/rules/documentation-product-manager-multiuse-toolkit/helper-docs/extra-copy-context.txt @@ -0,0 +1,59 @@ +--- +description: Product Context +alwaysApply: true +--- +# Product Manager Document Generator - Product Context +You are to always consider the following Product Context information when replying about any product document. All documents generated should reference the information provided here, and you will respond as an experience Product Manager. + +## Product Information +**Product Name:** [GIVE IT A SHORT NAME] + +## 1-line Product Description +[A 1-LINER DESCRIPTION OF THE PRODUCT THAT GENERALIZES THE SOLUTION] + +## Problem Statement +- [LIST AROUND 3 PROBLEMS THAT NEED TO BE SOLVED] +- [PROBLEM 2] +- [PROBLEM 3] + +## Business Field +- [PROVIDE A 1-4 WORD DESCRIPTION OF THE FIELD] +- [FIELD 2] +- [FIELD 3] + +## Type of Business +[LIST ONE OF THESE: B2B, B2C, B2B2C, B2G, ETC.] + +## Target Customers +- [LIST AROUND 3 CUSTOMERS OF THE PRODUCT] +- [CUSTOMER 2] +- [CUSTOMER 3] + +## Specific Solution +- [LIST THE MAIN COMPONENTS OF YOUR SOLUTION. BE BRIEF] +- [SOLUTION PART 2] +- [SOLUTION PART 3] + +## Differentiator +[LIST THE MAIN THING THAT DIFFERENTIATES YOU FROM OTHER SOLUTIONS. TRY AND KEEP IT TO 1 OR 2 SENTENCES] + +## Product Summary +[SUMMARIZE YOUR PRODUCT IN A SINGLE PARAGRAPH OF AROUND 100-200 WORDS. IT SHOULD INCLUDE THE ITEMS ABOVE AND CAN ALSO INCLUDE PARTS OF YOUR MISSION STATEMENT] + +## Optional - Additional Information + + + +## Writing Style and File Format +- Use clear, concise language +- Avoid technical jargon when possible +- Use bullet points for easy scanning + +# AI File Creation Instructions + +- **Create the file** in the `/product-documents/` directory +- **Use the naming convention**: `[TYPE]-[description]-[version].md` +- **Write file**: Save the generated content to the file +- **Open the file** for editing + +--- diff --git a/rules/documentation-product-manager-multiuse-toolkit/helper-docs/kpi_revenues.txt b/rules/documentation-product-manager-multiuse-toolkit/helper-docs/kpi_revenues.txt new file mode 100644 index 0000000..f510f40 --- /dev/null +++ b/rules/documentation-product-manager-multiuse-toolkit/helper-docs/kpi_revenues.txt @@ -0,0 +1,50 @@ +The following are possible connectors between Revenue Goals and Key Performance Indicators. + +The three Revenue Goals are: +1. Growth (making revenue) +2. Retention (preserving revenue) +3. Margins (sustaining revenue) + +For companies that are not for-profit, or have non-revenue related business objectives (such as Tech development), here are some potential metrics/indicators that can be used instead of Growth, Retention and Margins: +Social Impact, Technology Adoption/Breakthrough, Open-source Contributions, Patents Filed, Sustainability Goals, Workplace Safety, Supply chain resilience, Energy Consumption. +These should only be used if it is clear that the company is not one interested in Revenues directly. + +Given the Revenue Goal, there are typically KPIs that directly relate to this goal. Here is a partial list of Revenue Goals, and the types of KPIs that are associated with them. +Note that each Goal has 2 sub-categories of metrics that reach that goal: +**Growth (making revenue): +1. User growth and distribution: +a. Active Users (AU, DAU, MAU) +b. Net Promoter Score (NPS) +c. User Mix +d. Page Visits +e. App Installs +f. Click Through Rate (CTR) +2. Revenue Growth: +a. Recurring Revenue (Annual, Monthly; ARR, MRR) +b. Net Retention Revenue (NRR) +c. Multi Stock Keeping Unit (SKU) +d. Partner Revenue + +**Retention (preserving revenue): +1. Customer Retention: +a. Lifetime value (LTV) +b. Contract Length +c. Time to deploy +d. Time to value +e. Customer Satisfaction (CSAT) +2. Revenue Retention: +a. Churn +b. Average Contract Value (ACV) +c. Gross and Net Dollar Retention (GDR, NDR) +d. Down-sell + +**Margins (sustaining revenue) +1. Product pricing: +a. $ gating +b. Up/down/cross-sell +c. Monetizable account +d. Professional services +2. Service Costs: +a. Customer Acquisition Cost (CAC) +b. Capital Expenses (CapEx) +c. Operating Expenses (OpEx) diff --git a/rules/documentation-product-manager-multiuse-toolkit/helper-docs/list_of_product_metrics_text_only.txt b/rules/documentation-product-manager-multiuse-toolkit/helper-docs/list_of_product_metrics_text_only.txt new file mode 100644 index 0000000..a7d1682 --- /dev/null +++ b/rules/documentation-product-manager-multiuse-toolkit/helper-docs/list_of_product_metrics_text_only.txt @@ -0,0 +1,159 @@ +**Acquisition Metrics + +*Bounce Rate +The percentage of visitors who leave your website after viewing just one page. A high bounce rate may indicate issues with the landing page (e.g., messaging) or targeting. + +*Conversion Rate +The percentage of users who take a desired action, like signing up for a newsletter. + +*Landing Page Conversion Rate +The percentage of visitors who take a desired action on a specific landing page, like signing up or starting a trial, on a specific landing page. + +*Cost of Customer Acquisition (CAC) +The cost of acquiring a new customer through marketing and sales efforts. + +*Channel Effectiveness +The success of each acquisition channel in driving traffic, sign-ups, or purchases. + +*Traffic Source Distribution +The breakdown of incoming user traffic by different sources, such as organic search, referrals, or paid ads. + +* Cost Per Click (CPC) +* Click-Through Rate (CTR) + +**Activation Metrics + +*Time to Value (TTV) +The time it takes for a user to experience the core benefits of your product after starting to use it. A shorter TTV leads to higher user satisfaction, engagement, and retention. In a product-led growth, +optimizing TTV is crucial to ensure users quickly understand the value your product delivers. + +*Onboarding Completion Rate +The percentage of users who complete the onboarding process successfully. +*Onboarding Drop-off Rate + +*User Activation Rate +The percentage of users who successfully complete a certain milestone in your onboarding process. + +*Trial-to-Paid Conversion Rate +The percentage of trial users who convert into paying customers. + +*First-time User Conversion Rate +The percentage of first-time users who complete a desired action, such as creating an account or purchasing. This metric helps assess the effectiveness of the onboarding process. + +*Product Qualified Accounts (PQA) +*Product Qualified Leads (PQL) + +**Engagement Metrics + +*Daily Active Users (DAU) +The number of unique users who engage with the product daily. + +*Monthly Active Users (MAU) +The number of unique users who engage with the product monthly. + +*Stickiness +The ratio of daily active users (DAU) to monthly active users (MAU), which indicates how often users engage with the product. +Stickiness = DAU / MAU + +*User Satisfaction +A measure of how satisfied users are with the product, often determined through surveys or in-app feedback (e.g., Pendo, Gainsight). + +*Session Length +The duration of a user's interaction with the product during a single session. + +*Session Frequency +The average number of sessions per user within a specific time frame. + +*Feature Usage +The frequency and depth of usage for specific product features. + +*Customer Effort Score (CES) +Measures the ease with which customers can interact with your product or service. It is often determined by asking users to rate the effort required to accomplish a task or resolve an issue on a scale from very low to very high effort. A lower CES indicates a more user-friendly product, which can lead to higher user satisfaction and loyalty. + +*Task Success Rate +The percentage of users who successfully complete a specific task or set of tasks within your product. This metric helps assess the usability and effectiveness of your product's features. + +*User Feedback Score +A quantitative measure of user satisfaction gathered through surveys, ratings, or reviews. There isn't a single standardized method or rating scale. This could be a numeric scale (e.g., 1 to 5 or 1 to 10), a star rating, or a qualitative scale (e.g., poor, average, excellent). + +**Retention Metrics + +*Churn Rate +The percentage of users who stop using the product within a specific time period, e.g., monthly. + +*User Retention Rate +The percentage of users who continue using the product after a specific time period. Often monthly. + +*Cohort Retention Analysis + +*User Renewal Rate +The percentage of users who renew their subscription or continue using the product after their initial contract period. + +*Customer Lifetime +The average time it takes for a user to stop using the product. +Customer Lifetime = 1/Churn Rate + +*Customer Health Score +A composite metric that combines multiple indicators, such as usage, satisfaction, and support interactions, to provide an overall assessment of the customer's relationship with the product. + +*Product Adoption Rate +The percentage of users who adopt new features or functionality within a certain time frame after release. + +**Revenue Metrics + +*Average Revenue Per Account (ARPA) +The average revenue generated per account (customer) within a specific time frame. For example, monthly. + +*Customer Lifetime Value (CLV/LTV) +The total revenue a user generates during their entire relationship with the product. +CLV = Customer Lifetime * ARPA + +*Customer Profitability +The difference between the lifetime value of a customer (LTV) and the cost of acquiring them (CAC). + +*Monthly Recurring Revenue (MRR) +The predictable revenue generated by a subscription-based product on a monthly basis. +*Annial Recurring Revenue (ARR) + +*Expansion Revenue +Additional revenue generated from existing customers, through upsells, cross-sells, or add-on purchases. + +*Revenue Churn +The amount of revenue lost due to customer cancellations, downgrades, or non-renewals within a specific time period. +*Net Revenue Retention + +*Average Contract Value (ACV) +The average revenue generated from each customer contract, which can help assess the effectiveness of pricing and packaging strategies. + +*Gross Margin + +**Referral Metrics + +*Virality Coefficient +The number of new users acquired through referrals by existing users. Often expressed as a ratio. + +*Customer Referral Rate +The percentage of customers who refer others to the product. + +*Referral Conversion Rate +The percentage of referrals that convert into active users. + +*Net Promoter Score (NPS) +A measure of customer satisfaction and loyalty based on how likely users are to recommend the product to others. +NPS = % of Promoters - % of Detractors +Warning: NPS measures customer attitude and sentiment, not the actual behavior. + +**Comments + +*Cohort Analysis +Consider comparing user behavior and retention across different groups (cohorts) of users who started using the product simultaneously (e.g., month by month) + +*Engagement Metrics +In the AAARR (Acquisition, Activation, Retention, Revenue, Referral) framework, Engagement Metrics can be considered part of the Activation and Retention. +I presented them as a separate category to emphasize the distinct metrics focusing on user interaction with the product. + + + + + + diff --git a/rules/documentation-product-manager-multiuse-toolkit/product-documents/Contents.txt b/rules/documentation-product-manager-multiuse-toolkit/product-documents/Contents.txt new file mode 100644 index 0000000..6739a95 --- /dev/null +++ b/rules/documentation-product-manager-multiuse-toolkit/product-documents/Contents.txt @@ -0,0 +1 @@ +Product documents are generated here \ No newline at end of file From 2d43971d6346c196c061eb84d39f82ea709a260c Mon Sep 17 00:00:00 2001 From: za-iteraite Date: Wed, 27 Aug 2025 14:27:15 -0400 Subject: [PATCH 2/2] Some grammar corrections --- .../.cursor/rules/RICE-analysis-template.mdc | 4 ++-- .../.cursor/rules/kpi-revenues-template.mdc | 2 +- .../.cursor/rules/lean-canvas-template.mdc | 2 +- .../.cursor/rules/persona-template.mdc | 9 +++++++-- .../.cursor/rules/prd-template.mdc | 4 ++-- .../.cursor/rules/product-context.mdc | 4 ++-- .../.cursor/rules/product-positioning.mdc | 4 ++-- .../.cursor/rules/risk-analysis-template.mdc | 10 +++++----- .../.cursor/rules/roadmap-template.mdc | 2 +- .../.cursor/rules/user-journey-template.mdc | 10 +++++----- .../.cursor/rules/user-story-template.mdc | 4 ++-- .../alternate-templates/epic-alternate | 6 +++--- .../helper-docs/example-product-context.md | 4 ++-- .../helper-docs/extra-copy-context.txt | 4 ++-- .../helper-docs/list_of_product_metrics_text_only.txt | 2 +- 15 files changed, 38 insertions(+), 33 deletions(-) diff --git a/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/RICE-analysis-template.mdc b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/RICE-analysis-template.mdc index 359d15e..e9efa6a 100644 --- a/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/RICE-analysis-template.mdc +++ b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/RICE-analysis-template.mdc @@ -3,12 +3,12 @@ description: RICE prioritization of features using the Reach, Impact, Confidence alwaysApply: false --- # RICE Prioritization Template Instructions -You will be prioritizing a list of features as an experience Product Manager using the RICE method, which calculates a Score based off of 4 metrics that you will provide values for. +You will be prioritizing a list of features as an experienced Product Manager using the RICE method, which calculates a Score based off of 4 metrics that you will provide values for. ## Initial Features Before analyzing feature ideas using the RICE method, you first need to have a list of Features to prioritize. If the user hasn't provided you with a list of features, then you will first need to provide some feature ideas for them. -Be sure to use the @product-context.mdc data for for initial context. +Be sure to use the @product-context.mdc data for initial context. Inform the user that this template can help prioritize *up to 10* feature ideas at a time. If they provided a list of features, then tell them that you will take the first 10 features only. Or, provide a list of 10 feature ideas to be developed for the product. Provide the list in a numbered format. ## Business Goal diff --git a/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/kpi-revenues-template.mdc b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/kpi-revenues-template.mdc index 59e4470..45b9ab2 100644 --- a/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/kpi-revenues-template.mdc +++ b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/kpi-revenues-template.mdc @@ -7,7 +7,7 @@ Before writing the KPI-Revenue Connector, ask a short Clarifying Question to the ONLY THEN, continue with the rest of this document. **Also, advise the user that it may be better to manually switch to Gemini 2.5, which has a larger context window for this** -Be sure to use the @product-context.mdc data for for initial context. +Be sure to use @product-context.mdc data for for initial context. Then, sequentially answer the following sections to help create Metrics for a Product Manager to help explain the "Why" for a product: ## 1. Product Goals diff --git a/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/lean-canvas-template.mdc b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/lean-canvas-template.mdc index ea48322..fa9dfff 100644 --- a/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/lean-canvas-template.mdc +++ b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/lean-canvas-template.mdc @@ -4,7 +4,7 @@ alwaysApply: false --- # Lean Canvas Template Instructions -Be sure to use the @product-context.mdc data for initial context. +Be sure to use @product-context.mdc data for initial context. When creating the Lean Canvas, while you are to take into account the Product Context, you can also modify the responses when thinking through the lean canvas sequentially. Then, create a Product Requirements Document, following this comprehensive structure: diff --git a/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/persona-template.mdc b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/persona-template.mdc index 77a8c24..5037942 100644 --- a/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/persona-template.mdc +++ b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/persona-template.mdc @@ -1,5 +1,5 @@ --- -description: Defining 2 User Personas for the product: Regular and Skeptical Personas +description: Defining 2 User Personas for the product: Ideal and Skeptical Personas alwaysApply: false --- # Persona Template Instructions @@ -19,7 +19,12 @@ For each of these last 5 categories, write 3 short 1-line bullets, no more than Next, write a skeptical User Persona for this product. Assume the persona is one of the listed target customers mentioned above, however, assume that it is someone who is not at all likely to like your product, as they are skeptical, and it doesn't fit their needs and pains. Make sure to list: -1. Their name 2. Overview, 3. Goals, 4. Behaviors, 5. Pains and 6. Needs +1. Their name +2. Overview +3. Goals +4. Behaviors +5. Pains +6. Needs For each of these last 5 categories, write 3 short 1-line bullets, no more than 10 words each. Finally, write 3 short, Key Questions that you should ask potential users to help validate that this product is a good fit for them. diff --git a/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/prd-template.mdc b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/prd-template.mdc index 7b4d40c..479fd53 100644 --- a/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/prd-template.mdc +++ b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/prd-template.mdc @@ -3,7 +3,7 @@ description: Product Requirements Document, PRD, or Requirements Generator alwaysApply: false --- # PRD Template Instructions -Before writing the User Stories, ask a short Clarifying Question to the user about what the Time Frame is for the feature, and what the Specific Feature is (do not provide ideas). +Before writing the Product Requirements Document, ask a short Clarifying Question to the user about what the Time Frame is for the feature, and what the Specific Feature is (do not provide ideas). ONLY THEN, continue with the rest of this document. Be sure to use the @product-context.mdc data for initial context. Then, create a Product Requirements Document, following this comprehensive structure: @@ -72,7 +72,7 @@ Milestone 1: Competitive Analysis, Make a list of 5 competitors and analyze thei In addition, write a single sentence what you think the greatest milestone *Risk* is for this project. ## 10. OKRs -Provide 4 L1 and L2 OKRs to develop the feature or product. Each OKR should be a single sentence, no more than 25 words each. +Provide OKRs as follows: 2 L1 Objectives. For each L1, provide 2 L2 Key Results (4 KRs total). Each line ≤ 25 words. Make sure that the OKRs are aligned with the features and the problem-solution set. Make sure that the OKRs are measurable and achievable, using the SMART criteria. diff --git a/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/product-context.mdc b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/product-context.mdc index 48b3c7a..43dbc08 100644 --- a/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/product-context.mdc +++ b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/product-context.mdc @@ -3,7 +3,7 @@ description: Product Context alwaysApply: true --- # Product Manager Document Generator - Product Context -You are to always consider the following Product Context information when replying about any product document. All documents generated should reference the information provided here, and you will respond as an experience Product Manager. +You are to always consider the following Product Context information when replying about any product document. All documents generated should reference the information provided here, and you will respond as an experienced Product Manager. ## Product Information **Product Name:** [GIVE IT A SHORT NAME] @@ -35,7 +35,7 @@ You are to always consider the following Product Context information when replyi - [SOLUTION PART 3] ## Differentiator -[LIST THE MAIN THING THAT DIFFERENTIATES YOU FROM OTHER SOLUTIONS. TRY AND KEEP IT TO 1 OR 2 SENTENCES] +[LIST THE MAIN THING THAT DIFFERENTIATES YOU FROM OTHER SOLUTIONS. TRY TO KEEP IT TO ONE OR TWO SENTENCES] ## Product Summary [SUMMARIZE YOUR PRODUCT IN A SINGLE PARAGRAPH OF AROUND 100-200 WORDS. IT SHOULD INCLUDE THE ITEMS ABOVE AND CAN ALSO INCLUDE PARTS OF YOUR MISSION STATEMENT] diff --git a/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/product-positioning.mdc b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/product-positioning.mdc index 492c694..837ca41 100644 --- a/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/product-positioning.mdc +++ b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/product-positioning.mdc @@ -5,9 +5,9 @@ alwaysApply: false # Product Positioning Instructions Before writing the Product Positioning, ask a short Clarifying Question to the user about what the Specific Feature is (do not provide ideas). ONLY THEN, continue with the rest of this document. -Be sure to use the @product-context.mdc data for for initial context. +Be sure to use the @product-context.mdc data for initial context. Then, you will write 2 Elevator Pitches using the templates below. -Write only the pitch, no other text before or after the pitch. Try and refrain from using too many buzzwords and jargon, such as 'Say hello to", or "Say goodbye to", or using exclamations, such as "!" or "?!" +Write only the pitch, no other text before or after the pitch. Try to refrain from using too many buzzwords and jargon, such as 'Say hello to", or "Say goodbye to", or using exclamations, such as "!" or "?!" ## 1. Crossing the Chasm Elevator Pitch Write an Elevator Pitch for the product, that is up to 100 words, using the template from the book 'Crossing the Chasm' by Gordon Moore, and follows the following structure: diff --git a/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/risk-analysis-template.mdc b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/risk-analysis-template.mdc index d3dd8a3..28d6a5e 100644 --- a/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/risk-analysis-template.mdc +++ b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/risk-analysis-template.mdc @@ -2,17 +2,17 @@ description: Risk Analysis alwaysApply: false --- -Before writing the User Stories, ask a short Clarifying Question to the user about what the Specific Feature is (do not provide ideas). +Before writing the Risk Analysis, ask a short Clarifying Question to the user about what the Specific Feature is (do not provide ideas). ONLY THEN, continue with the rest of this document. -Be sure to use the @product-context.mdc data for for initial context. +Be sure to use the @product-context.mdc data for initial context. You are performing Risk Analysis as a Senior Product Manager for the product, including all aspects of the product. -Then, write a Risk Analysis for the Feature to be developed, using the this format: +Then, write a Risk Analysis for the Feature to be developed, using this format: ## Risk Factor Categories Given the Product Context and Feature/Product to be developed, what are the three main risk categories involved in such a product? Some examples are: Technology, User Interface, Manufacturing, Logistics, Compliance, Legal and Strategic and others. -Do not list 'Product market fit' as one of them! -List the three main risks categories first. +Do not list 'Product Market Fit' as one of them! +List the three main risk categories first. ## Risks and Mitigations: diff --git a/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/roadmap-template.mdc b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/roadmap-template.mdc index 2085d6f..65bdcee 100644 --- a/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/roadmap-template.mdc +++ b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/roadmap-template.mdc @@ -3,7 +3,7 @@ description: Roadmap planning alwaysApply: false --- # Roadmap Template Instructions -Be sure to use the @product-context.mdc data for for initial context. +Be sure to use the @product-context.mdc data for initial context. Use markdown to write the document, and short bullets for each item. When creating product Roadmaps, follow this comprehensive structure: diff --git a/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/user-journey-template.mdc b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/user-journey-template.mdc index dbe270e..b5bac2f 100644 --- a/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/user-journey-template.mdc +++ b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/user-journey-template.mdc @@ -5,9 +5,9 @@ alwaysApply: false # User Journey Template Instructions Before writing the User Journey, ask a short Clarifying Question to the user about what the Specific Feature is (do not provide ideas). ONLY THEN, continue with the rest of this document. -Be sure to use the @product-context.mdc data for for initial context. -You are writing the User Journey for the feature to be developed as a Product Manager with a speciality in UI and UX. -Then, write a User Journey for the Feature to be developed, using the this format: +Be sure to use @product-context.mdc data for initial context. +Write the User Journey as a PM with a specialty in UI/UX. +Then, write a User Journey for the Feature to be developed, using this format: ## 1. Phases of the Journey First you are looking to define the Phases of the journey, from the user's perspective. @@ -30,10 +30,10 @@ Write them in the first person, as if you were the user, without any extra text. Think about how the user interacts with the Product at each Phase. It could be in terms of how they use the application, or device, or webpage, or how they address service. This is the Touchpoint that the user has with the product. Write the potential Touchpoints that the User has at each Phase. -For the TOUCHPOINTS, make each no more than 1 sentence of up to 12 words. +For the Touchpoints, make each no more than 1 sentence of up to 12 words. ## 5. Opportunities -For each of the Phases, What are the main Opportunities for improvement or development at this point/Phase? +For each of the Phases, what are the main Opportunities for improvement or development at this point/Phase? List 3 different Opportunities as 3 single bullets, each a sentence of no more than 12 words, for each Phase. ## 6. Summary diff --git a/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/user-story-template.mdc b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/user-story-template.mdc index 42bb02b..b9da66b 100644 --- a/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/user-story-template.mdc +++ b/rules/documentation-product-manager-multiuse-toolkit/.cursor/rules/user-story-template.mdc @@ -5,8 +5,8 @@ alwaysApply: false # User Story and Acceptance Criteria Template Instructions Before writing the User Stories, ask a short Clarifying Question to the user about what the Specific Feature is (do not provide ideas). ONLY THEN, continue with the rest of this document. -Be sure to use the @product-context.mdc data for for initial context. -Then, write a User Story and Acceptance Criteria for the Feature to be developed, using the this format: +Be sure to use the @product-context.mdc data for initial context. +Then, write a User Story and Acceptance Criteria for the Feature to be developed, using this format: ## User Story Use the following format for the User Story: diff --git a/rules/documentation-product-manager-multiuse-toolkit/alternate-templates/epic-alternate b/rules/documentation-product-manager-multiuse-toolkit/alternate-templates/epic-alternate index dff6e98..3545dd4 100644 --- a/rules/documentation-product-manager-multiuse-toolkit/alternate-templates/epic-alternate +++ b/rules/documentation-product-manager-multiuse-toolkit/alternate-templates/epic-alternate @@ -9,13 +9,13 @@ Be sure to use the @product-context.mdc data for for initial context. When creating epics, follow this comprehensive structure, which lists the Epics first, and then provides some ideas for user stories. ## Epic Overview -You are to generate the Epics for the product to match the time frame and scope. Try and define no more than *3* epics in total. +You are to generate the Epics for the product to match the time frame and scope. Try to define no more than *3* epics in total. The epics should be different from each other, and should be in a way that is easy to understand. They should also be relevant to the product and feature scope. For each epic, you are to provide the following information: 1. Provide a clear title following the format: "Epic: [Name]" 2. Include a brief description (1-2 sentences) explaining the purpose and scope 3. Identify any major dependencies on other epics -4. List the business unit in charge of this (eg, Design, Engineering, Marketing) +4. List the business unit in charge of this (e.g., Design, Engineering, Marketing) List each epic similar to the Example below for only 2 epics, and additional epics should follow this style. ### Example Epic Output: @@ -32,7 +32,7 @@ List each epic similar to the Example below for only 2 epics, and additional epi ## User Stories After writing the Epics, you will write some ideas for relevant User Stories for those Epics. -Stop and think about the Epics you just wrote, and then come up with *5* User Stories each for each of the Epics. +Stop and think about the Epics you just wrote, and then come up with *5* User Stories per Epic. Use the following format for the User Story: As a [type of user], I want to [perform some task] so that I can [achieve some goal]. The User Story should be written in a tone that uses an Active Voice, and the Story is achievable. diff --git a/rules/documentation-product-manager-multiuse-toolkit/helper-docs/example-product-context.md b/rules/documentation-product-manager-multiuse-toolkit/helper-docs/example-product-context.md index 5918579..5c406c0 100644 --- a/rules/documentation-product-manager-multiuse-toolkit/helper-docs/example-product-context.md +++ b/rules/documentation-product-manager-multiuse-toolkit/helper-docs/example-product-context.md @@ -3,7 +3,7 @@ description: Product Context alwaysApply: true --- # Product Manager Document Generator - Product Context -You are to always consider the following Product Context information when replying about any product document. All documents generated should reference the information provided here, and you will respond as an experience Product Manager. +You are to always consider the following Product Context information when replying about any product document. All documents generated should reference the information provided here, and you will respond as an experienced Product Manager. ## Product Information **Product Name:** AgileGen @@ -19,7 +19,7 @@ An extension for your coding IDE that allows you to use it instead for generatin ## Business Field - Productivity Tools - SaaS Technology -- Product management software +- Product Management Software ## Type of Business B2B diff --git a/rules/documentation-product-manager-multiuse-toolkit/helper-docs/extra-copy-context.txt b/rules/documentation-product-manager-multiuse-toolkit/helper-docs/extra-copy-context.txt index 48b3c7a..43dbc08 100644 --- a/rules/documentation-product-manager-multiuse-toolkit/helper-docs/extra-copy-context.txt +++ b/rules/documentation-product-manager-multiuse-toolkit/helper-docs/extra-copy-context.txt @@ -3,7 +3,7 @@ description: Product Context alwaysApply: true --- # Product Manager Document Generator - Product Context -You are to always consider the following Product Context information when replying about any product document. All documents generated should reference the information provided here, and you will respond as an experience Product Manager. +You are to always consider the following Product Context information when replying about any product document. All documents generated should reference the information provided here, and you will respond as an experienced Product Manager. ## Product Information **Product Name:** [GIVE IT A SHORT NAME] @@ -35,7 +35,7 @@ You are to always consider the following Product Context information when replyi - [SOLUTION PART 3] ## Differentiator -[LIST THE MAIN THING THAT DIFFERENTIATES YOU FROM OTHER SOLUTIONS. TRY AND KEEP IT TO 1 OR 2 SENTENCES] +[LIST THE MAIN THING THAT DIFFERENTIATES YOU FROM OTHER SOLUTIONS. TRY TO KEEP IT TO ONE OR TWO SENTENCES] ## Product Summary [SUMMARIZE YOUR PRODUCT IN A SINGLE PARAGRAPH OF AROUND 100-200 WORDS. IT SHOULD INCLUDE THE ITEMS ABOVE AND CAN ALSO INCLUDE PARTS OF YOUR MISSION STATEMENT] diff --git a/rules/documentation-product-manager-multiuse-toolkit/helper-docs/list_of_product_metrics_text_only.txt b/rules/documentation-product-manager-multiuse-toolkit/helper-docs/list_of_product_metrics_text_only.txt index a7d1682..8a93c2e 100644 --- a/rules/documentation-product-manager-multiuse-toolkit/helper-docs/list_of_product_metrics_text_only.txt +++ b/rules/documentation-product-manager-multiuse-toolkit/helper-docs/list_of_product_metrics_text_only.txt @@ -113,7 +113,7 @@ The difference between the lifetime value of a customer (LTV) and the cost of ac *Monthly Recurring Revenue (MRR) The predictable revenue generated by a subscription-based product on a monthly basis. -*Annial Recurring Revenue (ARR) +*Annual Recurring Revenue (ARR) *Expansion Revenue Additional revenue generated from existing customers, through upsells, cross-sells, or add-on purchases.