Know How: You Know Why, But Do You Actually Know How To Do Any Of It?
Know How: You Know Why, But Do You Actually Know How To Do Any Of It?
Start With Why — But Don’t Stop There
You Know The “Why”, But Do You Actually Know How To Do Any Of It?
“Everyone knows they need to test ideas, products, concepts.
They just don’t know how.”
This realisation on a summer afternoon made me pause.
I had asked a rhetorical provocation about testing API products. I was only half-curious.
The responses I got did not go into too much detail.
And that’s ok.
Charlie Munger tells the story of Max Planck, who gave the same lecture about quantum mechanics multiple times around the world after winning a Nobel Prize.
After hearing the talk for the fourth time, his chauffeur asked if he could give the next lecture. Planck agreed. At first, the chauffeur’s lecture went well. But a physics professor in the audience asked a follow-up question that stumped the chauffeur, who didn’t have as much background knowledge as Planck.
Start With Why?
This space of agile, UX, testing, doing research, checking assumptions — it’s a big pot of great ideas, but also unbelievable ambiguity.
We all get the “why” of testing and iterating.
Sometimes I even wonder, who are those “execs” who we complain about?
Who are those evil people who pre-converge on solutions, don’t want to test their assumptions, and cost our dear UX, PM & research cohorts so much grief and stress?
This conversation has been going on for decades. This must be common knowledge by now, even in the dullest of office parks across the world?
But that’s not the point.
Even if it was common knowledge, we know how hard it is to translate theoretical knowledge to reality.
It’s simple to see the mistakes when you hover over a team as a coach, but not when you’re on the team making calls under pressure.
It’s trivial to support “interviewing customers”, but not when you’re in back-to-back meetings & when even reviewing 1 Otter transcript is a mission.
It’s easy to say “let’s test it”, but not easy to design a good test.
Am I a Fraud?
Even after trying the methods that I compiled in prodmgmt.world, “testing with users” is still not second nature to me. It’s not exactly habit despite my awareness.
Recently, I realised I didn’t have hands on experience with the Kano Model in it’s purest form. I knew the basics, but I forgot about the “Indifferent” category (the one that’s parallel to the Functionality axis). I hadn’t run the actual method with the survey, and the analysis after.
Whenever I bring Kano up with my cohorts, they wave it away, mumbling something about Delighters.
No one seems to touch on how exactly you would know which one is which, and what exactly we’d be testing.
Product work is so contextual: what’s yours is not mine.
I can either dive deep into your product (which I don’t want to do, nor do I have the time).
Or I can give you a generic answer.
I also suspect that a lot of us do this so-called product improv, and that’s cool. You can’t have hands on experience with every framework and technique under the sun. I’m not even convinced I need to use the Kano Model.
I’m not a purist. But I can appreciate rigour at scale.
Scientific Product Management
“Scientific” is not an adjective that “product management” gets prefixed with. In our hearts & minds we believe that ALL product management should be scientific.
Lately I’ve been working at a company where research is a dedicated function. I realised that I lost my fire for a fast & scrappy technique.
I no longer feel like a short 1-page document is enough to get going. Everything needs to be set up a certain way, or, if we’re doing something boutique, the boutique needs to be crafted well.
Research is a serious function, and if you’re not in that craft, you might be succumbing to the Dunning-Kruger effect a lot.
I probably do. A lot.
A good experiment is difficult to craft. It has to answer the question(s) clearly, be simple, free of bias.
And simplicity is expensive.
Mastery is expensive.
To quote the viral tweet,
“If I do a job in 30 minutes it’s because I spent 10 years learning how to do that in 30 minutes. You owe me for the years, not the minutes.”
Not true for everyone and everything, but it does take time and effort to learn to do something well.
And how can we learn to apply every single framework and technique under the sun? How can we master even the general loops (e.g. Build-Measure-Learn or the OODA loop for instance) when everything changes so fast?
So what can we do?
Start With 1
Here’s an algorithm:
Pick only one technique or framework. Any will do. If you’re stuck, pick one from here, here or here.
Focus on it for the next 3–9 months. This is important. Don’t let go of it until the time has passed. Don’t switch because you can’t apply it at work. Apply it in a different context.
Deconstruct it, apply it, fail, refine & learn from it. Take notes. Search out more content. Talk to people using it.
As you learn, start constructing a document on how to do it better. Share it with the world.
Move on to the next one.
I guarantee that you’ll benefit in one or all of these ways:
You’ll stop feeling like an impostor & gain confidence.
You’ll get things done, and they will be new & valuable.
You’ll actually find out hidden nuances that enrich your craft in ways you don’t expect.
Good luck!
If you liked this, please consider clapping for it (sounds so weird, eh!)👏🏽👏🏽
2. I write daily on Twitter, and I also publish a short weekly newsletter.
If you enjoy product, design, strategy, testing ideas & concepts — join me & share what’s on your mind!