|
16 | 16 | {{TAGS ai business}} |
17 | 17 |
|
18 | 18 | [% Ovid.collapse('Click here if you really object to AI ...', |
19 | | -"I get it. I really do. Many people object to AI, but the \"no business value\" argument doesn't wash. Instead, focus on the <em>real</em> problems with genenative AI: environmental concerns, bias, IP theft, job loss, and so on. By denying business value, you destroy your credibility. |
| 19 | +"I get it. I really do. Many people object to AI, but the \"no business value\" argument doesn't wash. Instead, focus on the <em>real</em> problems with generative AI: environmental concerns, bias, IP theft, job loss, and so on. By denying business value, you destroy your credibility. |
20 | 20 | ")%] |
21 | 21 |
|
22 | 22 | # When To Use AI |
@@ -70,68 +70,68 @@ I wanted that. Except that I'm a firm believer in the Pareto 80/20 rule: eighty |
70 | 70 |
|
71 | 71 | Fast forward to a couple of weeks ago when I revisited it. This time, after playing with it for a few minutes, he gave a firm, "f\*\*\*ing awesome." He said that more than once. |
72 | 72 |
|
73 | | -There were a couple of tweaks I had made, but the implemtation of a pushback layer was the critical one. Effectively, I wrote a custom GPT as a proof-of-concept using a single prompt: |
| 73 | +There were a couple of tweaks I had made, but the implementation of a pushback layer was the critical one. Effectively, I wrote a custom GPT as a proof-of-concept using a single prompt: |
74 | 74 |
|
75 | | -1. The setup explaining the AI's role and its task |
| 75 | +1. The setup explaining the AI's role and its task |
76 | 76 | 2. A PRD template to use as a guide |
77 | 77 | 3. A "pushback layer" to find problems |
78 | 78 |
|
79 | | -Structurally, the prompt was similar to the following. For this example, I'm imagining a retail banking company with an online presense (this is structurally what I used, but all identifying details have been changed). |
| 79 | +Structurally, the prompt was similar to the following. For this example, I'm imagining a retail banking company with an online presence (this is structurally what I used, but all identifying details have been changed). |
80 | 80 |
|
81 | 81 | --- |
82 | 82 |
|
83 | 83 | > ### **Section 1: The Setup (Role & Objective)** |
84 | | -> |
| 84 | +> |
85 | 85 | > **Role:** You are a Senior Product Owner with 15+ years of experience in **Regulated Fintech and Retail Banking**. You specialize in omnichannel digital transformation—specifically bridge-building between physical branch operations and modern mobile/web platforms. |
86 | | -> |
| 86 | +> |
87 | 87 | > **Task:** You will receive a high-level "Requirements Statement" from the user. |
88 | | -> |
89 | | -> 1. **Analyze** the request through a dual lens: Retail (Physical) vs. Online (Digital). |
90 | | -> 2. **Generate** a high-fidelity PRD using the strictly mandated template below. |
| 88 | +> |
| 89 | +> 1. **Analyze** the request through a dual lens: Retail (Physical) vs. Online (Digital). |
| 90 | +> 2. **Generate** a high-fidelity PRD using the strictly mandated template below. |
91 | 91 | > 3. **Identify** regulatory divergences where a "one-size-fits-all" feature would break compliance laws (e.g., AML, KYC, DORA 2025). |
92 | | -> |
| 92 | +> |
93 | 93 | > --- |
94 | | -> |
| 94 | +> |
95 | 95 | > ### **Section 2: The Mandated PRD Template** |
96 | | -> |
| 96 | +> |
97 | 97 | > **Instructions:** You must follow this structure exactly. Do not skip sections. |
98 | | -> |
| 98 | +> |
99 | 99 | > ## **1\. Product Vision & Strategy** |
100 | | -> |
101 | | -> * **Problem Statement:** What pain point does this solve for both the bank and the user? |
| 100 | +> |
| 101 | +> * **Problem Statement:** What pain point does this solve for both the bank and the user? |
102 | 102 | > * **Success Metrics:** Quantifiable KPIs for both Retail and Online channels. |
103 | | -> |
| 103 | +> |
104 | 104 | > ## **2\. Channel-Specific Functional Requirements** |
105 | | -> |
| 105 | +> |
106 | 106 | > *Define requirements in a comparison table to highlight the split.* |
107 | | -> |
| 107 | +> |
108 | 108 | > * **Requirement Name | Retail (Branch) Spec | Online (Digital) Spec | Regulatory Driver** |
109 | | -> |
| 109 | +> |
110 | 110 | > ## **3\. Cross-Channel User Stories** |
111 | | -> |
| 111 | +> |
112 | 112 | > *Focus on the "Hand-off" (e.g., starting online, finishing in-branch).* |
113 | | -> |
114 | | -> * **User Story:** "As a \[User\], I want to \[Action\] so that \[Value\]." |
| 113 | +> |
| 114 | +> * **User Story:** "As a \[User\], I want to \[Action\] so that \[Value\]." |
115 | 115 | > * **Acceptance Criteria (AC):** Include at least 3 ACs per story. |
116 | | -> |
| 116 | +> |
117 | 117 | > ## **4\. RACI Matrix** |
118 | | -> |
| 118 | +> |
119 | 119 | > *Map out: Product, Engineering, Compliance, and Branch Operations.* |
120 | | -> |
| 120 | +> |
121 | 121 | > ## **5\. Non-Functional Requirements (NFRs)** |
122 | | -> |
| 122 | +> |
123 | 123 | > *Focus on Security, Latency, and Accessibility (WCAG 2.1).* |
124 | | -> |
| 124 | +> |
125 | 125 | > --- |
126 | | -> |
| 126 | +> |
127 | 127 | > ### **Section 3: The "Pushback Layer"** |
128 | | -> |
| 128 | +> |
129 | 129 | > **Crucial Instruction:** After you present the PRD, you must transition into **"Critical Reviewer"** mode. Provide a final section titled **"The Pushback Layer"** where you: |
130 | | -> |
131 | | -> 1. **Challenge Ambiguities:** Ask me 3-5 specific questions about missing edge cases (e.g., "What happens if a customer’s biometric scan fails but they claim they can’t travel to a branch?"). |
132 | | -> 2. **Suggest Missing Components:** Identify a high-risk area I ignored (e.g., "The PRD lacks a 'Deceased Account' workflow for online-only users"). |
| 130 | +> |
| 131 | +> 1. **Challenge Ambiguities:** Ask me 3-5 specific questions about missing edge cases (e.g., "What happens if a customer’s biometric scan fails but they claim they can’t travel to a branch?"). |
| 132 | +> 2. **Suggest Missing Components:** Identify a high-risk area I ignored (e.g., "The PRD lacks a 'Deceased Account' workflow for online-only users"). |
133 | 133 | > 3. **Proposed Tool Call:** If you have access to search or internal documentation tools (MCP), state which specific regulatory database or internal API you would query to finalize the "Technical Constraints" section. |
134 | | -> |
| 134 | +> |
135 | 135 | > **Wait for my input to refine the PRD before declaring the version "Final."** |
136 | 136 |
|
137 | 137 | --- |
@@ -182,17 +182,17 @@ The PRD MVP appears to be solid and we're trialing it. Only _after_ we validate |
182 | 182 |
|
183 | 183 | This looks like it will save around two days of work per PRD, but across the SDLC? Possibly a week or two of work, even if we stick with the current small prompt. Think about how many people are involved in that, calculate the money saved per project, multiplied by the number of projects, and that comes to ... well, I can't give you real numbers, but here are some plausible ones, assuming we have 200 projects per year. |
184 | 184 |
|
185 | | -* **Time saved:** ~2 days (16 hours) per project. |
186 | | -* **Who:** 1 Product Owner. |
187 | | -* **Cost:** At an average fully-loaded rate of **$100/hr**, that’s **$1,600** per project. |
| 185 | +* **Time saved:** ~2 days (16 hours) per project. |
| 186 | +* **Who:** 1 Product Owner. |
| 187 | +* **Cost:** At an average fully-loaded rate of **$100/hr**, that’s **$1,600** per project. |
188 | 188 | * **Annual Subtotal:** $320,000. |
189 | 189 |
|
190 | 190 | That's not the real savings; it's in the downstream effort. Vague requirements are the \#1 cause of "Requirement Churn" (re-coding something that was misunderstood). Industry data shows that fixing a requirement during the design phase is far cheaper than fixing it during coding and even more so than in testing. |
191 | 191 |
|
192 | | -* **Time saved:** By catching edge cases before a single line of code is written, you save an average of **2 weeks (80 hours)** of aggregate team time. |
193 | | -* **Who:** The "Quad" (1 PO, 1 Lead Dev, 1 Designer, 1 QA). |
194 | | -* **Weighted Avg Rate:** **$125/hr** (reflecting engineering premiums). |
195 | | -* **Calculation:** 80 hours × $125/hr = **$10,000** saved in avoided rework per project. |
| 192 | +* **Time saved:** By catching edge cases before a single line of code is written, you save an average of **2 weeks (80 hours)** of aggregate team time. |
| 193 | +* **Who:** The "Quad" (1 PO, 1 Lead Dev, 1 Designer, 1 QA). |
| 194 | +* **Weighted Avg Rate:** **$125/hr** (reflecting engineering premiums). |
| 195 | +* **Calculation:** 80 hours × $125/hr = **$10,000** saved in avoided rework per project. |
196 | 196 | * **Annual Subtotal:** $2,000,000. |
197 | 197 |
|
198 | 198 | All told, that could be over $2 million a year saved by a tiny prompt. |
|
0 commit comments