product development super-skill:
making instrumentation/telemetry just "how we work" vs. some bolt-on process, telephone game, as-a-PM-I-can-see user story craziness.
I see this with super successful customers at @Amplitude_HQ . It is just how they work.
How do you do it? 1/n
making instrumentation/telemetry just "how we work" vs. some bolt-on process, telephone game, as-a-PM-I-can-see user story craziness.
I see this with super successful customers at @Amplitude_HQ . It is just how they work.
How do you do it? 1/n
First, you have to get the people who 1) understand the decision domain, 2) understand the customer domain, 3) understand the product surface area, and 4) understand "data" ... in one place.
Sometimes you get lucky and that is one or two people. Sometimes not.
Gotta do it 2/n
Sometimes you get lucky and that is one or two people. Sometimes not.
Gotta do it 2/n
Usable data starts with domain knowledge!
It is so tempting to just instrument abstract clicks or page views and hope to clean it up later.
But instrumenting clean, understandable, domain relevant events from the start is SO MUCH BETTER.
Then...3/n
It is so tempting to just instrument abstract clicks or page views and hope to clean it up later.
But instrumenting clean, understandable, domain relevant events from the start is SO MUCH BETTER.
Then...3/n
You have to get away from imagining you're going to figure out every question in advance, or "spec" the perfect dashboard.
Sure, keep reference questions in mind
But focus on "things that happen that we care about"
The nouns, verbs, adjectives, adverbs
That skill...4/n
Sure, keep reference questions in mind
But focus on "things that happen that we care about"
The nouns, verbs, adjectives, adverbs
That skill...4/n
...is the foundation for making instrumentation just part of each and every new interaction.
Instead of an extra ticket, you just ask yourself with each new design/flow/interface
"what is actually happening here?"
and instrument as part of the "story"
5/n
Instead of an extra ticket, you just ask yourself with each new design/flow/interface
"what is actually happening here?"
and instrument as part of the "story"
5/n
The code takes m/secs to write. With the right testing env you can validate it works in minutes.
The muscle you have to build is figuring out how to integrate this into your workflow.
That's what makes this feel heavyweight at first.
Tools help 6/n
The muscle you have to build is figuring out how to integrate this into your workflow.
That's what makes this feel heavyweight at first.
Tools help 6/n
Tools like @iteratively get you out of spreadsheets and into a repo-like environment.
I know this from my adtech days...as versatile as they are, spreadsheets are terrible for event tracking plans.
So tool up 7/n
I know this from my adtech days...as versatile as they are, spreadsheets are terrible for event tracking plans.
So tool up 7/n
Finally, this is a habit like any other.
Before you start it feels heavyweight. There is a big temptation to decouple this from "the work".
Resist that and start thinking about instrumentation is core as writing tests. Bake it into your "definition of done" by default 8/end
Before you start it feels heavyweight. There is a big temptation to decouple this from "the work".
Resist that and start thinking about instrumentation is core as writing tests. Bake it into your "definition of done" by default 8/end
• • •
Missing some Tweet in this thread? You can try to
force a refresh
