Templates make it easy to think and design clearly and rule out blind spots. (Though it may also introduce blind spots…) Here is a collection of templates that help you build better products.

1. PRFAQ - Press release and frequently asked questions
2. ADR - Architecture decision record
3. OKR - Objectives and key results
4. Eng Design Doc
5. Github Issue and PR

Guiding Policies

1. Keep it simple, easy to be refer to, and easy to be measured.
2. Separate core objectives from stretch objectives.
3. At least 60% of them should be defined by the executors.

OKR Template

20XX Yearly OKRs

* Core Objective 1:
* Core Objective 2:
* Core Objective 3:
* Stretch Objective 1:
* Stretch Objective 2:

20XXQX OKRs

* Core Objective 1:
  * KR:
  * KR:
* Core Objective 2:
* Stretch Objective 1:

ADR means Architectural Decision Record, a mini-doc to capture significant architectural changes that are not worth a full design doc.

# [short title of solved problem and solution]

* Status: [proposed | rejected | accepted | deprecated | … | superseded by [ADR-0005](0005-example.md)] <!-- optional -->
* Deciders: [list everyone involved in the decision] <!-- optional -->
* Date: [YYYY-MM-DD when the decision was last updated] <!-- optional -->

Technical Story: [description | ticket/issue URL] <!-- optional -->

## Context and Problem Statement

[Describe the context and problem statement, e.g., in free form using two to three sentences. You may want to articulate the problem in form of a question.]

## Decision Drivers <!-- optional -->

* [driver 1, e.g., a force, facing concern, …]
* [driver 2, e.g., a force, facing concern, …]
* … <!-- numbers of drivers can vary -->

## Considered Options

* [option 1]
* [option 2]
* [option 3]
* … <!-- numbers of options can vary -->

## Decision Outcome

Chosen option: "[option 1]", because [justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force force | … | comes out best (see below)].

### Positive Consequences <!-- optional -->

* [e.g., improvement of quality attribute satisfaction, follow-up decisions required, …]
* …

### Negative Consequences <!-- optional -->

* [e.g., compromising quality attribute, follow-up decisions required, …]
* …

## Pros and Cons of the Options <!-- optional -->

### [option 1]

[example | description | pointer to more information | …] <!-- optional -->

* Good, because [argument a]
* Good, because [argument b]
* Bad, because [argument c]
* … <!-- numbers of pros and cons can vary -->

### [option 2]

[example | description | pointer to more information | …] <!-- optional -->

* Good, because [argument a]
* Good, because [argument b]
* Bad, because [argument c]
* … <!-- numbers of pros and cons can vary -->

### [option 3]

[example | description | pointer to more information | …] <!-- optional -->

* Good, because [argument a]
* Good, because [argument b]
* Bad, because [argument c]
* … <!-- numbers of pros and cons can vary -->

## Links <!-- optional -->

* [Link type] [Link to ADR] <!-- example: Refined by [ADR-0005](0005-example.md) -->
* … <!-- numbers of links can vary -->

PRFAQ means press release and fequently asked questions. People at Amazon adopt it to write down requirements and important features of yet to be developed products.

Why does it matter?

1. it is customer-centric - Starting with the Customer and working backward.
2. it clarifies uncertainties early on and simplifies the following-up work of engineering, product, design, marketing, and sales.
3. it tests people’s excitement of the product.

Press Release

Copied from this article.

## **Heading: short name for the product that the target customers will understand**

**Subheading: One sentence saying who the market is and what the benefit is**

Summary: 2–4 sentences that gives a summary of the product and the benefits. _Should be self-contained so that a person could read only this paragraph and still understand the new product/feature._

Problem : 2–4 sentences describing the problem that a customer faces, which this product solves. _Tests your assumptions about the pain-points that you are addressing._

Solution : 2–4 sentences, describing how the new product/feature addresses this problem. _Tests your assumptions about how you are solving the pain-points._

Getting started: 1–3 sentences describing how someone can start using this product/feature (if it’s baked into the existing product, say this explicitly). _Tests your assumptions about how easy the ramp-up is for your customers to take advantage of the new product/feature._

Internal quote: Someone within your company being quoted about what they like about the product/feature. _Tests your assumptions about the value you are creating for your customers and how you position this product within your broader product offerings._

Customer Quote(s): a hypothetical customer saying what they like about the new product/feature. _Tests your assumptions about how you want your customers to react to the new product/feature and your ideal customer profile. They should be doing something that they couldn’t do before, doing something much quicker and easier, saving time and effort, or in some other way making their life better. Whatever the benefit is, their delight in the benefit(s) should be exhibited in the quote. This should be multiple quotes from different customers if you have multiple profiles of ideal customers, example: mid-market and F50 customers._

Call to action: 1–2 sentences telling the reader where they can go next to start using the product/feature. _Tests your assumptions about whether this is a feature that is automatically on, something they need to turn on, a beta-release, etc._

## FAQs

A set of public frequently-asked questions and their answers. This should be a comprehensive list of everything that a customer might want to know about the product. It should include any reasonable question that comes up when discussing the new product/feature with customers and customer-facing teams during the development of the product/feature.

## Internal FAQs

A set of private, internal frequently-asked questions and their answers in a format that can be understood by every other stakeholder. An FAQ might include wireframes of a product with a strong UX component, or a link to separate wireframe documents, but the PR should rely on text alone. This will allow all internal stakeholders to get clarity on the product/feature.

Internal FAQ

### Why is [this product] important to us?

### What are the objectives [this product] trying to achieve?

### How to evaluate the success of [this product]?

### How can [this product] fail? Would it cause customer dislikes?

### What is the rollout plan?

### What are the dependencies?

### What are the risks?

Customer FAQ

### Why does [this product] matter to me?

### How to [use this product]?

### How do I know if [this product] is a right solution to my problem?

Is the innovation disruptive?

Dsruptive innovation vs. Continuous innovation

• Whether it changes our current mode of behavior or to modify other products and services we rely on.
• Between continuous and discontinuous lies a spectrum of demands for behavioral change.

High-tech industries introduce disruptive innovation routinely, during which people are converted into customers by following a pattern of normal distribution. The product’s user growth follows an S-curve.

When will people buy a high-tech product?

Disruptive innovation’s customers are converted at different stages in the technology adoption life cycle. They are…

1. Innovators
2. Early adopters
3. Early majority (pragmatists)
4. Late majority (conservatives)
5. Laggards

Segment	What They Want
Innovators	novel, cool and experimental things
Early Adopters	gaining advantages or getting products before others
Early Majority	proven ROI, instant access, low transition costs, support available
Late Majority	adopting as minimal as possible or only when everyone else has adopted
Laggards	avoidance to adopt new things

What is the high tech marketing model?

This cycle provides guidance of the high tech marketing model: the way to develop a high-tech market is to work the curve left to right, focusing on each group one by one, because groups on the left promote products for the right ones in a momentum.

Momentum is vital because it can

1. save costs
2. make it fast so you won’t miss the window of opportunity before next disruption or competitor

Where is the CHASM?

Inspecting into the technology adoption lifecycle, we can see

• two cracks

  1. Beneficial usage crack between innovators and early adopters. E.g., Esperanto, VRML, second life, 3D printing. To cross this, we need a flagship application.
  2. Competent majority crack, between early and late majorities. E.g., home automation.scanning and project management software. To cross this, we need to make it easier to adopt.

• and one CHASM

  1. Early adopter-to-majority chasm. Because their needs are different

     1. Early adopter is buying a change agent - they expect to get a jump on the competition. Having bugs is fine.
     2. The pragmatic early majority is buying a productivity improvement. They want technology to enhance, not overthrow, the established ways of doing business.

  2. The compatibility above leads to two key points

     1. early adopters do not make good references for the early majority
     2. And because of the early majority’s concern not to disrupt their organizations, good references are critical to their buying decisions.

  3. Who did fall into the early adopter-to-majority chasm in 2014? E.g., holograms, pen-based tablets, fuel cells, QR codes (in the US), Massive Open Online Courses, Segways, Motorola iridium.