A user should never start with a blank canvas and be asked to conceive of analysis from scratch.

BI should simplify your story; you probably don't need more than ten chart types.

Sometimes you want your BI to work exactly like code: checked in, run in continuous integration, with upstream dbt models (or other transformation tool).

Sometimes you want your BI tool to work nothing like code at all: one-off charts and queries and totally ad hoc and free wheeling.

Your output isn't a dashboard or a chart, a data model or a single insight – it's knowledge and understanding.

Don't reduce your work to just a "decision factory." It's not only about making decisions.

Many decisions don't need data.

Only start to use data when you have enough of it. When you're early and you only have ten users, you can just ask them what they think.

Data is most powerful when it scales empathy: you can talk to a single user or talk to a single patient. You can't talk to a hundred thousand users. Data can let you talk to 100,000 users.

Think about the end-to-end value of your pipeline: from when data is collected to where it is consumed.

The data pipeline ends in the minds of people in your organization.

Your data team should be distributed and gain as much context on the domain as possible.

People who consume data should get context on business rules and get involved in how data is constructed.

Publish and share once you figure something out

Data has users – you should have empathy for them.

One Big Table, Star Schema and Snowflake schemas are the only suitable ways to model users for broad consumption. Subjecting users to complex joins in a UI is bad for usability and understanding.

Mixing grains in a single data view should be done carefully and intentionally (not incidentally and accidentally).