Here's inspo for how to demo Avo πŸ’ƒ But please make it your own, focusing on the value propositions for each stakeholder along the way. And most importantly!

Please make suggestions and/or leave comments for improving this demo workflow. We always want to make it better.

1. Set the demo expectations with an overview of the Avo workflow:

For example by showing this slide in the Avo Intro deck.

<aside> 🎞️ Here's a video of how I typically walk through the Avo workflow before I dive into a product demo

</aside>

2. Review "How you get started with Avo"

Mention that Avo is better than your spreadsheet for your tracking plan management and that you''ll review that better later during the Avo workflow demo.

For now you want to address concerns like "omg how would I get my tracking plan in there, would i need to manually add all my events in there, this seems like a lot of work?". So showcase now that you can import your tracking plan (don't have to go through it, but maybe that's a cool addition if people tend to get impressed by it?)

3. Review Inspector

E.g. "When you install the Inspector SDK, Avo will alert via Slack on tracking anomalies, both based on best practices and based on your tracking plan."

See Guide to prepare Inspector for demo for clarity on what data and issues to highlight in the Inspector review.

4. LARP the full-blown Avo workflow

Go through each step of the Avo workflow, focusing on the value propositions for each stakeholder along the way. Depending on your audience, remember to highlight where people will get value along the way even if they don't adopt the Avo functions.

<aside> πŸ’‘ Pro tip: To customize demos, call things the same names as the prospect does. For example, use the same stakeholder roles as the company typically has involved in each step of the process (data design, review, implement); if a product analyst designs data, then say you're putting on "your product analyst hat". I even sometimes say "I'm putting on my [name of person] hat" to make it even more relatable. Another example: If the company calls them "events and attributes", you should do the same, instead of "events and properties".

</aside>

0. Set the demo stage

Similar to step 1, this is to set expectations for the demo, but this is also to minimize confusion throughout the demo. I've seen people get lost when the demoer switches quickly between windows or code files, so I try to clarify well what they will be looking at in the demo, and then I try to be verbose about "where I am" whenever I switch tabs or windows.

1. PRODUCT HAT: Put on your Product Manager hat to design data.

Note: I literally make a physical "put on my hat" move for these role-switching moments in the demo, so the roles can empathize with their own part of the demo, to emphasize the role switching and collaboration. (And to make it more theatrical engagement πŸ€·β€β™€οΈ*)*