2.2 · Customer Success · Product Strategy
Book 1 · Ch 5 · Service-to-Product Fit

Second SKU Spec: When to Add, What to Add

Hill scorecard template for evaluating second SKU candidates sequenced after the first. Six dimensions scored against the first SKU's pull-through data. Candidate names and scores populate once three paying customers are on the first SKU.

2.2 · Customer Success · artifact id: second-sku-spec-v0.html · v0 · 2026-05-28
Format stub. The scoring framework and decision rules are established. Candidate product names, feature descriptions, and scoring inputs populate once three paying customers are on the first SKU (the 3-customer validation threshold from Ch 6 of Shrink-Wrap It). Starting this analysis before three customers are live dilutes focus prematurely.

The 3-customer gate

Ch 5 of Shrink-Wrap It states: "Not every successful service should become a product. Use the six dimensions to evaluate candidates objectively." Ch 6 adds the sequencing constraint: "Don't pursue a second product until your first reaches three customers."

These two constraints in sequence are the gate for this spec. First: reach three paying customers on SKU 1 (not piloting, not LOI, not design partner agreement, paying). Second: run all second-SKU candidates through the six-dimension scorecard below. The candidate with the highest score and the strongest pull-through from SKU 1 is the recommendation. If no candidate scores above 3.5 on five dimensions, the recommendation is to stay concentrated on SKU 1 and expand within existing accounts instead.

Pull-through criteria from first SKU

A second SKU has strong pull-through from the first SKU if at least three of the following are true:

Six-dimension scorecard

Score each candidate 1-5 on each dimension. Maximum score: 30. Minimum viable score for recommendation: 21 (3.5 average across 6 dimensions). Any dimension scoring 1 is a disqualifier unless there is a clear remediation path within 90 days.

Dimension Definition Score 1 (low) Score 5 (high) Candidate A
[TBD]		 Candidate B
[TBD]		 Candidate C
[TBD]
1. TAM Total addressable market for the second SKU, defined realistically as agencies reachable on vehicles NorthAI already holds or can access in 12 months Fewer than 20 potential agency customers 100+ potential agency customers; aligns with existing vehicle footprint [TBD] [TBD] [TBD]
2. Repeatability How consistently can the second SKU be delivered at scale without per-customer customization exceeding 30% of build effort? (Ch 5's core criterion) Each deployment requires major custom work; 70%+ custom per customer Core is fully standardized; configuration covers 90%+ of customer variation [TBD] [TBD] [TBD]
3. ATO inheritance Does the second SKU inherit NorthAI's existing FedRAMP authorization boundary, or does it require a new boundary, new controls, and new 3PAO assessment? Requires entirely new boundary, new SSP, new 3PAO engagement Fully within existing boundary; no new authorization work required [TBD] [TBD] [TBD]
4. Customer overlap What fraction of SKU 1 customers are also natural buyers of SKU 2? High overlap enables contract modification. Low overlap means a separate sales motion. Less than 20% of SKU 1 customers would be SKU 2 buyers 80%+ of SKU 1 customers are natural SKU 2 buyers; contract modification is the primary path [TBD] [TBD] [TBD]
5. Engineering capacity Can the engineering team build and maintain SKU 2 without degrading SKU 1 quality or authorization posture? Ch 6: "Each product carries the full burden." SKU 2 would consume 80%+ of available engineering capacity; SKU 1 maintenance would suffer SKU 2 can be built and maintained with 30% of available engineering capacity; SKU 1 is unaffected [TBD] [TBD] [TBD]
6. Pricing power Can SKU 2 command a price premium over SKU 1 that reflects the incremental value delivered? Does federal budgeting support the pricing model? SKU 2 pricing is a discount or bundle inclusion; no separate pricing power SKU 2 commands 50%+ premium over equivalent SKU 1 seat; agencies will budget for it separately [TBD] [TBD] [TBD]
Total score [TBD] / 30 [TBD] / 30 [TBD] / 30

Decision rules

Total score Decision
25-30 Build immediately. All dimensions strong. Candidate is the clear second SKU. Initiate build and add to sku-launch-plan-v0 cycle.
21-24 Build with risk mitigation. Identify the lowest-scoring dimension and create a 90-day remediation plan before launch commit.
15-20 Revisit at Month 18. Candidate has structural weaknesses. Stay concentrated on SKU 1 expansion. Log for re-evaluation when customer count reaches 5.
Below 15 Do not pursue. Structural disqualifier present. Redirect engineering capacity to SKU 1 ConMon, onboarding, or platform hardening.
Any dimension = 1 Automatic review required regardless of total score. A dimension scoring 1 (e.g., ATO inheritance requires entirely new authorization) may be a hard stop that no other score offsets.

Candidate generation process

Before scoring, generate 3-5 second SKU candidates using this four-step process:

  1. Review customer support tickets and feature requests from SKU 1 customers. Group requests into clusters. Clusters with 3+ independent customer requests across the first three accounts are candidate signals.
  2. Review SKU 1 contract CLIN 0003 orders. If customers are consistently ordering custom development under CLIN 0003 for the same type of work, that work is a productization candidate.
  3. Review the contract archaeology output (from Ch 4's IP extraction framework). Any IP with 3+ uses across different federal engagements and not yet extracted as SKU 1 is a candidate for SKU 2.
  4. Run candidates through pull-through criteria (above) before scoring. Candidates that fail more than two pull-through criteria do not advance to the scorecard.