Product Requirements Document (PRD) and Business Model
Posted on February 19, 2023 — 7 Minutes Read
Throughout my professional career, I have written Product Requirements Documents (PRD) in many different forms. Although its name is an artifact from the age of waterfall development, in the days of agile, it has become a catch-all for that particular planning document that captures the problem, the solution, and everything in between for a product venture. Amazon has its 6-pager, Basecamp has its Pitch, and others either adopt a similar format or develop one of their own. Accompanying or supporting such document is often a business model, driven by the customer values and backed by data, to project the direct and indirect business values of the new product, and to devise measurable success metrics for the venture. What follows will be a sample PRD and business model for a hypothetical Global Load Balancer (GLB) product for a cloud service provider, that distributes inbound traffic to target resources in the nearest and available data centre (DC) over a private backbone network, for geographical redundancy, This new GLB product will be in addition, and complementary, to an existing regional Load Balancer (LB) product.
Product Requirements Documents
Below is the Product Requirements Documents (PRD) for the hypothetical GLB product.
Problem Statement
As small to medium-sized businesses (SMB) scale their workload on virtual machines (VM) and Kubernetes clusters (K8s) beyond the confine of a DC to serve their customers, there arises a need for geographical redundancy between these workloads. Without geographical redundancy, should a VM, K8s, or the DC that it is in, undergo maintenance or experience outage, inbound request will fail and revenue will be lost.
Proposed Solution
The existing LB product distributes inbound traffic to target resources within the same DC. One natural trajectory to provide geographical redundancy between workload on VM and K8s across DC is to evolve the LB product into a GLB. Doing so will however mean, either losing out on the additional revenue that customers are be willing to pay for geographical redundancy, or pricing those who do not need the added benefit out of the LB. To take advantage of customer segmentation, a GLB product is proposed to complement the existing regional LB.
JTBD
Below are the job stories.
| Index | Job Story | Priority | Teams |
|---|---|---|---|
| VM LB | When my VM undergoes maintenance or experiences outage, I want inbound traffic to be routed to the nearest data centre, so I can continue to serve my customers | Must Have | Network Product Engineering |
| K8s LB | When my K8s undergoes maintenance or experiences outage, I want inbound traffic to be routed to the nearest data centre, so I can continue to serve my customers | Must Have | Network Product Engineering |
| VM HC | When inbound traffic is routed to the target VM in nearest data centre, I want to make sure the target resource is available, so I can continue to serve my customers | Must Have | Network Product Engineering |
| K8s HC | When inbound traffic is routed to the target K8s in nearest data centre, I want to make sure the target resource is available, so I can continue to serve my customers | Must Have | Network Product Engineering |
| API | When I manage my GLB, I want to do so through the API, so I can automate the workflow | Must Have | Network Product Engineering |
| UI | When I manage my GLB, I want to do so through the UI, so I can apply changes visually | Should Have | Design/UX |
| Backbone | When inbound traffic is routed to the target resource in nearest data centre, I want the traffic to be routed through a backbone network, so I can ensure it is private and performant | Should Have |
Infrastructure Security |
Out of Scope
Below are out of scope for the GLB.
- GLB does not support L4 or non-HTTP L7 protocols
- GLB does not provide additional DDoS protection
- GLB does not provide content caching
Design/UX
GLB will follow a similar design for the API and UI as the existing LB to ensure a seamless user experience.
Competitive Landscape
Below are the competitive landscape for the GLB.
| Cloud | Product | |
|---|---|---|
| Hyperscalers | Amazon Web Services (AWS) | |
| Google Cloud Platform (GCP) | ||
| Microsoft Azure | ||
| Niche Cloud Service Providers (CSP) | Vultr |
|
| Linode | ||
| Hetzner | ||
| Emerging Challenger | Cloudflare |
Risk and Hypothesis
Below are the risks and hypotheses to be validated.
| Risk | Hypothesis | Risk Level | Validation |
|---|---|---|---|
| Desirability | Customers need geographical redundancy between workload on VM and K8s across DC | High |
|
| Customers want to have geographical redundancy with the GLB | High | ||
| Customers prefer predictable pricing at the cost of performance limits | High |
|
|
| Customers are willing to pay for the GLB | High |
|
|
| Usability | Customers knows how to mange the GLB through the API | Low |
|
| Customers knows how to mange the GLB through the UI | Medium | ||
| Viability | GLB generates direct revenue from adoption | Medium |
|
| GLB generates indirect revenue from customers scaling up or replicating their workload | Medium | ||
| Feasibility | GLB knows the nearest data centre to the inbound traffic | Medium |
|
| GLB can route the inbound traffic to the VM in the nearest data centre | Medium | ||
| GLB can route the inbound traffic to the K8s in the nearest data centre | Medium | ||
| GLB knows if the target VM is available | Low | ||
| GLB knows if the target K8s is available | Low | ||
| GLB can be managed on the UI | Low | ||
| GLB can be managed on the API | Low |
Pricing and Packaging
GLB will follow the same pricing model and metrics of the existing LB that scales horizontally with a fixed price per node for up to 100 nodes. GLB will support all features of the existing LB, and will allow for distributing inbound traffic to target resources across DC over a private backbone network. For the added geographical redundancy, GLB will be priced at a premium over the LB. Each node provides an addition of:
- 10,000 requests per second
- 10,000 simultaneous connections
- 250 new SSL/TLS connections per second
Use Case and Targeted Segment
For any website, web app or API that requires high availability, especially when downtime translates directly to lost revenue, that is projected to be more than the cost of the GLB.
Success Metrics and OKR
Below are the success metrics, and Objectives and Key Results (OKR) with regard to the business model.
| Objective | Leading Indicator | Lagging Indicator/Key Result |
|---|---|---|
| GLB will generate direct and indrect new revenue | By Q3 2023, there will be 104,000 monthly active GLB | By Q4 2023, GLB will deliver a FY 2023 revenue of $25 million |
| By Q3 2024, there will be 141,000 monthly active GLB | By Q4 2024, GLB will deliver a FY 2024 revenue of $74 million | |
| By Q3 2025, there will be 191,000 monthly active GLB | By Q4 2025, GLB will deliver a FY 2025 revenue of $100 million |
Timeline
Projected by Network Product Engineering, the development for GLB will require 6 sprints, or 12 weeks, with dependencies on:
- Design/UX
- Security
- Infrastructure
If development and dependencies begin at the start of Q2 2023, it will be ready to ship at the end of Q2.
Open Questions
Below are some open questions that are still to be discussed.
- Could GLB reuse the IP address from an existing LB?
- What are our customers using today for global load balancing?
- What would motivate our customers to move away from their existing global load balancing solution and adopt the GLB?
Business Model
Below is the business model for the hypothetical GLB product, with the dependencies, the hypotheses, and the total projected revenue for 2023 through 2025, highlighted.
Thoughts
Behind every successful product, there is a dedicated team of talented engineers and product designers, but there is also a succinctly written PRD and a meticulously crafted business model.