
# Heading 1

## Heading 2

### Heading 3

#### Heading 4

##### Heading 5

###### Heading 6

This is a paragraph. Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

This is a second paragraph. Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

This is a paragraph with **bold text** and _italics_.

[Link to somewhere internal](/)
[Link to somewhere external](https://www.google.com/)

<button>Button</button>

> Block quote of something really important
>
> Second paragraph of the the blockquote

- UL List Item 1
- UL List Item 2
- UL List Item 3

---

1. OL List Item 1
2. OL List Item 2
3. OL List Item 3

`inline code block`

```
Multi-line code block

const test = 'string'
```


A note on getting to the root causes of customers frustrations.

You must dig

Don't take your thoughts and ideas for something to seriously.

Ideas are wet clay


- Declare what you mean, be bold with your proposals. If you don't present your ideas, then you won't be able to gain the necessary feedback that makes things stronger. [[Zettle/Feedback Loops are the key to motivation and a successful learning process]] and not being vague allows for them to occur. [[Zettle/Sharing your work with others leads to better results]].



- Discovery is not the time to be pitching ideas or getting feedback on designs it is the time for building your customers profiles and giving you more understanding so **you** can decide "Whats in and whats out."
- Customers opinions on whether or not the 'like' or 'dislike' our product is meaningless. We are not trying to get our customers to like us or our product, we are trying to solve their problems. To do that we need to unearth the context surrounding their requests. [You must dig](you-must-dig)
  - This is the time to understand what **matters** to you customer, which helps guide what you build. You are not asking them directly to tell you because [Products should not be built by a committee](products-should-not-be-built-by-a-committee)


Products should not be built by a committee


- We externalize and signal our desired self. Only look at customers past actions. Like [[Concept/The Mom Test]].



- "When you are making a decision as a PM, you are placing bets. You can never be 100% certain that something that you are working on or a decision you are planning to make is going to be successful."
  - **Know** what you are betting. Be mindful of what you are losing by making a specific bet. Something has to give for something to be worked on. Time is finite. You should only be concerned about what you could **break** if something goes wrong.
  - You can never be 100% certain that what you are building will be the next 'thing', so that shouldn't be the goal of your product planning and Product Strategy.
  - You and your teams level of excitement around and idea is the ruler, not the ROI. Trying to calculate the ROI is just guess work anyways.
  - You are after creating **impact**. Motivation should be fueled by the joys of shipping great product.
  - **R-Source**
    - "You can be in a room for hours voicing things back and forth off of each other trying to find solutions to problems that might makes sense, but when it comes down to having to measure the impact of what you built, you'll be lost since to are without a ruler. "
      - "how will you know if what you all did or worked on is better?"
      - "what do we agree upon for the problem? "
      - "what are the things that are out of scope and can't change? these are the things that aren't going to move
- "Since we cannot perfectly predict outcomes, this effectively means that ^^**all decisions are bets we are making**^^" - https://twitter.com/rjs/status/1252780648999161857?s=21



- They should always be open and moldable.
- [Every product proposal is a bet](every-product-proposal-is-a-bet)


An note on bet making in the product strategy process.

Every product proposal is a bet.

- Things should get better over time when you are doing something. Something that stays stagnant should be reconsidered. Could your efforts be more effective focusing on something else where you can get more [[Return-On-Attention]]?
    - You should strive for your customers inputs to get compounded when they use your software 



- If you try to include everyone in the development process you'll end up with a product that works for no one. [Products should not be built by a committee](products-should-not-be-built-by-a-committee)
- "Visuals and product decisions should only match the customer you're serving. Don't fall into the trap of mimicking others that serve other groups. "
  - "You can get caught building for yourself when you are not the target users. Something that makes sense to you might not make any sense to your end user."
- [[Zettle/Trying to serve everyone serves no one]]
  - When people try to design for everyone there is a **constant tendency towards average**"
    - "That's not where great products service."
    - "We are after edge cases"
- "Focus on the Wildly Important"
  - "Be specific about what you are setting out to accomplish"
  - "The more you try to do, the less you will accomplish."
- R-Sources
  - "https://twitter.com/rjs/status/1257820134258827264?s=21"



- Its you and your teams product in the end so you should be the ones advancing your products and ideas, not other people. We can't build everything and nor should we strive to do so.
  - "You cannot just throw bodies at at creative problem the same way that you can with something manual like building physical objects. Inputs from others does not automatically cause things to compound and [Inputs should compound over time](inputs-should-compound-over-time)
  - The purpose of building something is **not to solve something easy,** we are after the things that are **hard**. There is so much noise out there and people love telling you their latest and greatest ideas. Look for the signals. [Trust your instincts](trust-your-instincts).
  - The people that are experiencing a problem are not the right people to be trying to **solve** the problem. If they had the answers, then they wouldn't have the problem.
  - Opinions coming from someone with real experience in **building** a product just like yours **still matters**, so don't wave that off. Those people aren't your customers though.
  - A general best practice is to **not define** a customers problem for them, let them speak and tell you, an in return they shouldn't be allowed to develop your Product Strategy or roadmap.
  - You and your team should be making the decisions on what needs to be built [You must dig](you-must-dig)


Inputs should compound over time

Have confidence in the decisions that you make.

Trust your instincts.


- "You can't **assume** from your own experience that something is going to work. You have to go out into the real world and try your ideas."
- Great ideas must be written down to be interpreted by others. This is the purpose of and where Product Proposals Write-Up shine in their ability to get buy-in and common understanding. People can't crawl into your head and extract your thoughts, so you have to share and give them the same **context that you had** when you were developing your ideas.
- You must invite the criticism of your peers. If you do this too late, your ideas will be too weak to stand up to inevitable adversities that will come later. Ideas are meant to be pressure tested and you shouldn't become too attached to them. If new information feels like a threat, then something is wrong with your research process. [Ideas are wet clay](ideas-are-wet-clay)
  - "Yet if you don't put yourself out there with your radical transparency, you won't learn."



- Only gather others opinions when you need a flashlight when you feel like you are in the dark. Accumulating massive amounts of feedback too early can lead to massive amount of uncertainty.
- Most people are sharing thoughts with you they they themselves are uncertain about. [Sharing your work with others leads to better results](sharing-your-work-with-others-leads-to-better-results) but sharing **too early** and **only** using other peoples suggestions to guide your process can harm your own ability to build new ideas.
- You should not be seeking certainty since certainty can never be achieved.
- Playing with ideas and testing how things fit together is the natural way that we as human express ourselves and our creativity. Don't avoid it.
- "Look within your own experiences if you are a consumer of the product yourself."


Sharing your work with others leads to better results


- Humans are directed by the inertia from the things they are comfortable with. The old––the consistent. The price of change is more than what's on the sticker. By changing they are giving up their time and risking their reputation or emotions.
  - [[Loss Aversion]] is a beast to overcome when building products. Choosing to **not take** any action can sometimes feel less risky than trying something new. People do not like change.
- Companies immune systems are susceptible to attacking themselves when things that are out of their comfort zone or typical ways of doing things. Change can be halted out of fear and consensus of the hivemind.
  - When 'business as usual' is breached, people throw up their defenses.
- A flaw of humans is over-optimism. We claim things that we hope to embody only to later contradict with our actions. We are very optimistic, which causes the things we claim to be unreliable. We produce tons of noise.



- ![](https://firebasestorage.googleapis.com/v0/b/firescript-577a2.appspot.com/o/imgs%2Fapp%2Fbaileysmind%2FTUNQlWjfGM.png?alt=media&token=21a33b89-e490-4248-a5ec-0168fd0aa747)

- Get to the motivations behind a request. **'Something' happened for that 'something' to be acknowledged as a problem by your users**. Customers will rarely be able to point to what true problem is, so thats your job to unearth.Often, users think they are doing a certain action, but really don't understand the 'Why' surrounding their actions.

  - **The Golden Question:**"Can you tell me a story about a time that you wanted to do that and what you had to do instead?"
  - "Uncover the \***\*why\*\*** behind customer choices."

- **Dig down into their actual workflow**. What were they doing at the precise moment they thought something need to change or had their epiphany?

- [Declared customer preference is not something you can trust](declared-customer-preference-is-not-something-you-can-trust). [We are creatures of habit](we-are-creatures-of-habit)

- We need to dig for the gems that caused their frustration in the first place. What were they doing at the very moment? What was their underlying motivation for making the request in the first place?

  - "You must have an intense focus on solving your customers struggle and finding out what they are **really** hiring your product for. Find the [[causal mechanisms]] that caused them to pull the products into their lives."
    - "What state of mind were they in when they came across the issue they were having? Cluster these insights together to build out the full picture of the situation(s). Factor in their entire environment."
  - "**What was happening that showed you the way you were doing things wasn't working anymore?** — via [Keep digging - Signal v. Noise](https://m.signalvnoise.com/keep-digging/)"

- "What are customer doing in place of use your product? If their problem is real then they will take the time to hack together a solution that satiates their needs temporarily."

  - "Keeps these insights on the **individual** level. Avoid grouping your different customers insights together even though it can be tempting to build 'profile' and demographic groups."

- "Ask yourself: What obstacles can your product remove to help them succeed?"
  - We want the edge cases.


We externalize and signal our desired self.

Declared customer preference in not something you can trust

An note on humans natural tendancy to repeat their actions.

Writing

2020