What this canvas is

This is a template for describing an analytics project (a research): a list of connected questions, arranged in a chain, that you should ask yourself in order to understand the task. It helps data analysts solve tasks better and explain their findings to others more easily.

The template has three goals:

• not to miss important things in the task;
• to build a habit of thinking about these things when solving a task;
• and to explain to others how you think about the task and what you know about it.

The goal is NOT to fill out a big checklist for every task every time. Fill it out 2–3 times — you'll get used to it, and in simple cases you'll run through the checklist in your head, writing it out in text only for complex and large ones.

Where to get the template

Copy this page to your Notion:

Data Analytics Project Canvas — Template

Over time, templates for Google Docs, Logseq, etc. will appear here.

Examples

Data Analytics Project Canvas — Examples

How to fill it out

The template assumes that you will come back to it and extend it — thereby rethinking the task.

So spend no more than an hour on the first pass. Write facts and figures from memory — you'll add links later. If it's going slowly, fill in as much as you can within an hour and come back in a day.

The template can be filled out in any order; you can go back or skip ahead. Stuck on stakeholders? Try filling in the pains or the "What we know" and "What we don't know" sections, then return to stakeholders.

If filling out the checklist is hard — that's good! It most likely means you understand the task poorly. The earlier you discover your lack of understanding, the easier it is to fix, and the lower the chance it will shoot you in the foot later. Forewarned is forearmed.

If filling it out is easy — congratulations, you understand the task well and have simply confirmed that nothing important was lost. It will also be easier for you to explain your understanding to fellow analysts and customers: in data analytics, it's not enough to do the research — you also have to convey its results to colleagues and achieve business impact.

Blocks and formulations

The template includes two spare blocks: "Processes" and "Metrics". Early on you may have neither metrics nor processes, so skip them at the start. As you work on the task, you will discover/create processes and understand which metrics are needed — then fill them in.

The formulations in the template may seem clunky, but on the first pass still try to squeeze your thought into them. What matters is not the beauty of the text but the clarity of thought. Later you'll return to the template and rewrite and shorten where needed.

Pay special attention to the situation description (the first block) and to the formulation of hypotheses.

Describing the situation

The "Situation" block should be written from a third-party position.

Suppose you joined a product to build up the user base and generally grow it in every way. There's a strong temptation to describe the situation like this:

"We need to find growth points and increase MAU to X people."

By writing it this way, you immediately box yourself into this requirement. Worse, you shift from a researcher's perspective to that of a detailer, an engineer. After that, the whole template stops working for you, and you lose the ability to impartially figure out what's going on. So take a step back and write as if you were an outside observer with no stake in the situation or in what happens to the company.

"Company X does such-and-such, has this many users and is growing this way. It operates in a market with players A and B; they have these problems, and the company solves some of them. The company has these goals, and they must be achieved because of this and that (investor requirements, cash runway, competitors, etc.)."

You'll have time to formulate the solution. That's a familiar train of thought, a familiar role — we all know how to write "what to do" statements. For now, hold yourself in the researcher's role.

Hypotheses

The easiest way to explain hypotheses is through examples:

• "Why don't users buy?" — not a hypothesis but a question; its place is in the "What we don't know" block.
• "Users don't buy because it's too expensive for them" — not a hypothesis but a statement, and one phrased as truth. If it really is true — move it to the "What we know" block and link to the fact confirming it (a customer development interview, a chart, a table, a dashboard, etc.). If you're not sure — formulate it as a hypothesis and test it.
• "I believe users don't buy because it's too expensive for them" — better, but still not a hypothesis; it's a belief. It's unclear whether it's true.
• "I believe users don't buy because it's too expensive for them. To check this, I'll run a pricing A/B test." — getting good, but still not a hypothesis. First, explain how the test will be designed (put this on a separate Notion page and link to it from the hypothesis block). Second, suppose we ran the test and the statistical criterion gave a p-value of 0.06. Does that mean the hypothesis is rejected?
• "I believe users don't buy because it's too expensive for them. To check this, I'll run a pricing A/B test. If purchase conversion in the discount group is X% higher at a significance level of 0.05, we accept the hypothesis; otherwise we reject it." — this is a good formulation.

A hypothesis has three parts: 1) the statement we believe in; 2) the ways to test it; 3) the acceptance and rejection criteria.

It's good when there are several testing methods using different approaches: A/B tests, surveys and customer development interviews, descriptive data analysis, collecting external statistics. In data analytics we usually work with complex systems where it's rarely possible to isolate all influencing factors, so any confirmation is probabilistic. If a hypothesis is confirmed by several independent methods, the probability of error is lower.

Note: our hypotheses are not hypotheses about changing the product ("We believe that by doing X we'll see Y"), but hypotheses about how reality around the product works ("We believe users behave in such-and-such a way"). We're not changing anything yet — only investigating. The line here is thin, but with time you'll feel it.

Working cycle

The last four blocks form something like a cycle:

1. Based on what we don't know, we formulate hypotheses;
2. Hypotheses dictate the next steps to test them;
3. Once these steps are done, the hypothesis stops being a hypothesis and becomes a fact — we remove it from the "Hypotheses" block and write the discovered fact into the "What we know" block. If along the way we learned something valuable that we hadn't planned to check, we add it to the "What we know" section (and possibly to "Processes", "Metrics", "Stakeholders", "Pains").
4. At the new level of understanding, new questions appear (we realize there's something else we don't know) — we put them into the "Don't know" section. The circle is complete.

There's a temptation to build a kanban process with cards around this cycle. Although that can be useful at some stage, I don't recommend doing it from the very beginning. Keep your focus on the task itself, not on dragging cards around. But if you've done it and it works for you — great.

Map size

Keep the map short: it should fit on one screen, two at most. If some item has grown too large — for example, the "What we know" block has many facts and charts — summarize them in a short statement and link from it to a page where that statement is expanded and substantiated.

A short map fits in your head, it's easier to think about, and it's easier to explain to others.

Additional blocks

The map can be extended at least at the "What we know" point. The "Metrics" and "Processes" blocks grow out of it: you know about certain processes and metrics, but they're such important entities that it makes sense to set them apart. Similarly, your task might develop, say, "Data" and "Models" blocks. Add them next to "What we know" if a) you've accumulated quite a lot of facts about data or models, and b) you've tried hiding them in a subpage of the "What we know" block but want them in front of your eyes at all times.

Another place where extending the map seems logical is the project description. At some point you'll understand the situation well enough to set a task "to do something" and "to arrive at some result" — then add a "Vision" block (briefly describing what problem your system solves) and a "Milestones" block (listing the stages of work and the definition of done for each).

Remember: by adding blocks you make the map heavier. Make sure it still fits in your head.

Feedback and development

This template is not set in stone — I keep improving it. Fill it out and tell me how it went: what was especially hard, which formulations were confusing, which sections were redundant, and which were missing. Together we'll make the perfect template :)

Bonus

I'll give you a free consultation on your task if you come to me with a filled-out template for it 🙂 To get one, message me on Telegram and attach a link to your task description written using the template (ideally in Notion). We'll pick a time for a call and discuss what you've come up with.

Legal notes

The author of the template is Kirill Krasnoshchekov. I publish the template and its documentation under the CC-BY-SA 4.0 license. Please feel free to use it in any projects. If you adapt it, publish your version under the same license and credit the author.