Faith triangle + IOZ Growth Loops
Infuse the IOZ personal growth loops with a triangle of faith.
Infuse the IOZ personal growth loops with a triangle of faith.
Template for writing an investment memo to capture the learning process before spending a large amount of money.
## 20XX-XX-XX Company Name Investment Memo
| Attribute | Value |
| -------------------- | ----- |
| Category | |
| Round | |
| Raising | |
| Pre-money Valuation | |
| Post-money Valuation | |
| Allocation | |
## Summary
The decision is yes / no with an amount of X, because of the most significant argument Z.
- highlight 1, could be pros and cons.
- highlight 2
- highlight 3
Ratings: X out of 5 (benchmark against past deals)
| Attribute | Value |
| -------------------- | ----- |
| Traction | |
| Team | |
| Product | |
| Social Proof | |
| Pitch / Presentation | |
| Total | |
## Introduction
- What does the company do?
- What is the problem the company solving?
- How does the world work now in relation to this problem?
- How does the company solve the problem?
- How does solving the problem change behavior and make money?
- What is the scale of the opportunity?
## Traction / Metrics
- Discuss traction up to now (include a chart).
- Discuss main related metrics, such as churn, ACV, rake.
- Discuss revenue drivers.
- What does the go-to-market look like?
## Challenges to Growth
- What's prevented you from growing even faster?
- How will raising money solve this problem?
## Market
- Who are the customers?
- How do those customers think / act?
- How big is the opportunity these customers represent?
## Future States
- What happens to the market as the company starts to win?
- How does the company change the market and where does that lead the company?
## Compatitive Landscape
- What is the competitive landscape and how does the company defeat it?
## Team
- Who are the team and what makes the team special?
## FAQ
- The main objections the company is likely to face, and eloquently knock them down. Data is good here.
- This is probably the part where the memo is most powerful relative to a deck.
## Use of funds
- How much have the company raised in the past?
- How much the company is raising and what are they going to do with it?
- [ ] sort qualitatively
- [ ] apply filtering criteria
- [ ] create market map
- [ ] assess risks at each life stage (TAL)
- [ ] quantify uncertainties
| Stage | Early Stage Success | Cross Chasm | Mass Market Success | Mass Market Share |
|-------------|---------------------|-------------|---------------------|-------------------|
| Market | | | | |
| Product | | | | |
| Team | | | | |
| Financial | | | | |
| Total | | | | |
- [ ] perform sensitivity analysis
- [ ] calculate risk / return
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 and modified from this article.
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 start with customer and 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.
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.
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.
Prediction | Validation | |
---|---|---|
Item 1 | ||
Item 2 | ||
Item 3 |
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 -->
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:
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.
@[toc]
What interesting and useful martial arts techniques or moves have you encountered in Silicon Valley? Feel free to fork our GitHub repo and submit a PR, or star it to follow future updates.
External
Internal
Internally
Externally
Beancounters traditionally use command-line tools or self-host servers with private networks, where they have to operate through a computer or a general-purpose text editor on mobile. Beancount.io reduces hassles by bringing open-sourced Android and iOS mobile apps and a secured cloud so that your ledger is now a few taps away from your fingerprint.
Beancount is a computer language that enables double-entry bookkeeping in text files. Once you define financial transactions in the file, it will generate various reports. Martin Blais, the designer of this language, argues that command-line bookkeeping has many advantages - It is fast, portable, open, and customized.
We strongly agree with the argument and share the feeling of empowerment brought by beancount language. And we wanted to do more - introducing the technology to more people. It means that we have to improve the usability and make it more accessible to a broader audience.
Not everyone is a command-line enthusiast, and this is why we build Beancount.io - the personal finance manager for everyone. Here is how it works:
For heavy-duty work, beancounters could still use their computers to edit or view the ledger with their browsers visiting https://beancount.io or syncing with Dropbox. This keeps the flexibility of the command-line tools, while not losing the cross-device access of the cloud-based solution.
For daily light-weight operations, such as instantly adding an entry, beancounters could use the mobile app to connect to the secured cloud.
Mike Thrift, a backend engineering working on this product, says
I used to set up a reminder every day for myself to open my laptop and input records to my bean files. Now, with beancount.io, it is way easier for me to modify my ledger whenever I need it, even when I am outdoors purchasing something in the store.
Zhi Li, a software engineer from Facebook, tells us
I have migrated all my beancount files to beancount.io, and now it works perfectly for my day-to-day usage. I have paid for Pro features like automatic data backup, but I feel there are more things you guys could do to improve the service.
You could sign up now at https://beancount.io/sign-up/ or download iOS or Android App. We streamlined the registration to collect as minimal information as we can from you to bootstrap the service. Then you will get a preset empty ledger that is ready for you to add an entry right away.