here's a bit of advice I give to a lot of companies at my day job (@Amplitude_HQ ) re: analytics

Start By Counting Things

Skip magic metrics.
...goal setting and success metrics.
...trying to "justify" a strategy.
..."benchmarks" and what your competitors do.

...focus on counting things that happened that you care about. Stay firmly grounded in the customer domain. Name things sensibly. Add extra context with human understandable properties. Decouple counting from the interface-de-jour.

Start By Counting Things

Why? ... (2/n)
...this is the muscle you need to build.

When you can count things, the rest falls into place ... especially with a product like @Amplitude_HQ which handles the nitty/gritty of making that data useful for you.

too many teams jump straight to a silver bullet (3/n)
...they end up in a state of perpetual data snacking

...not really trusting the data, scrounging up whatever they can find, opting to "track everything" w/o domain context and getting even more confused.

Instead, you need to slow down and build the right habits...(4/n)
If an executive walks in and says "ok, we need success metrics, and I want to know the magic metric explaining retention, oh, and a health score, oh and ..."

...the team is liable to forget the basics. And ... (5/n)'s the rub (and secret). Our most successful customers at @Amplitude_HQ didn't wake up one day to find a magic metric or insights.

They had the right habits, explored good data, tested hypotheses, refined questions.

They knew how to count things (6/n)
It starts with counting things. Once you can do that -- and there are products that help here -- the rest falls into place.

Don't worry too much about the rest. Anyone who has all that started by counting things too (7/end)

• • •

Missing some Tweet in this thread? You can try to force a refresh

Keep Current with John Cutler

John Cutler Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!


Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @johncutlefish

5 Jan
"The engineers on my team just want to code. They don't want to have anything to do with product. They just want specs. What do I do?"

1/n Are you asking them do to X *and* do their "day job" as defined by their managers (and frankly your roadmap) ?

If so, start there...
2/n Do they have a reason to believe that doing X will in any way improve the quality of the product and make their lives easier? Have they ever seen X "work" ?

Show don't tell.
3/n Is there average day/week a quagmire of unnecessary meetings, wading through tech debt, struggling to get *anything* to work ... and jumping through process hoops to prove their worth?

If they will not have bandwidth.
Read 9 tweets
3 Jan
the product manager is responsible for the product's success...

simple. But....wait....

1/n There are many $ successful products that are terrible for humans (both inside/outside a company). Is that success?
2/n Conversely, what about "great products" that end up being "not successful" ?

Did the product manager do their job? Where does their role begin and end?
3/n Success over the lifespan of the product? next quarter? until they leave? while company exists?

There are many ways that short term success can come at the expense of mid/long term impact
Read 10 tweets
2 Jan
something just occurred to me...

I think ppl look at [popular tech co] product management advice and think "oh goodness...the rigor!"

...when in fact it is really about the intentional reduction in process overhead and leaner governance/budgeting
... this is especially important for bigcos believing they "don't have the 'talent'" to operate like X

...when in fact they don't have an environment where talent can flourish like X. They have trouble letting go.
... part of this is pure $.

They might be a money printing machine, but highly highly risk averse.

They talk about "innovation" but it is in the context of a massive amount of inertia to shave off %pts in cost and a very shallow excel-drag-to-right revenue forecast
Read 4 tweets
22 Dec 20
I'm going crazy trying to explain this seemingly basic concept, but striking out. Any ideas appreciated!

At the day job (@Amplitude_HQ) I meet teams who imagine the following...that there is a linear relationship between analytics instrumentation "work" and insights ... (1/n)
Meanwhile - the teams that are actually doing the work (and integrating it into day-to-day product work), see something that looks more like this...

A quick pass at instrumentation unlocks a lot of valuable insights. Integrating it into day-to-day work unlocks even more (2/n)
Can't put my finger on the why

With a self-service analytics product, it is 1) easy to add new events, props, etc. and 2) you have a whole variety of insight variations.

With just 2 events, 5 props each, and a handful of user properties you can answer LOTS of questions (3/n)
Read 5 tweets
20 Dec 20
How should product managers and designers share certain responsibilities?

wrong answers only.
Pm: I pick the right things. You build them right ...
Pm: oh hey for that work we’ve been talking about that is five months out ... do you mind just whipping up some mocks? Nothing serious. Promise. Will not hold you to them.
Read 8 tweets
19 Dec 20
I frequently encounter leaders who believe their team(s) aren’t “ready” for taking a more outcome focused approach. They talk of “baby steps” and “learning how to crawl before...”.

Here’s what they are missing
... to learn something, it is important to practice the thing (1/n)
You don’t learn this by running a (or working in a) feature factory, cranking out the stuff sprint by sprint.

You learn by doing a version — albeit probably more controlled/structured — of the thing ... (2/n)
What might that involve?
- direct contact w/customers
- some ability to “sense” outcomes qualitatively/quantitatively
- a feedback loop

Instead of
(Someone else learns) - build - build - build - build - build

Learn - build - build - measure - learn - build - measure (3/n)
Read 7 tweets

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!