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.
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?
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.
### 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?
### 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?
Dsruptive innovation vs. Continuous innovation
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.
Disruptive innovation’s customers are converted at different stages in the technology adoption life cycle. They are…
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 |
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
Inspecting into the technology adoption lifecycle, we can see
two cracks
and one CHASM
Early adopter-to-majority chasm. Because their needs are different
The compatibility above leads to two key points
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.
Learn startup engineering anywhere, anytime