something I've learned, and re-learned over and over -- at @Amplitude_HQ especially talking to so many teams.
It is vital -- absolutely vital -- to understand your product in the *broader landscape* of a customers workplace.
Why? 1/n
...when talking to a customer about your product, you will always trigger the instinct for them to be helpful and provide information about YOUR product. Which is good...
...but also a challenge.
The reality is that your product is a tiny part of their world. 2/n
"What problems are you having?"
Customer: "Um, well, [some task related to your product]"
(remembering to focus on goals)
"Oh no, what is your GOAL?"
Customer: "Um, well, [some goal related to your product]"
All good, except, again, this is a tiny part of their world. 3/n
Meanwhile, have you learned how they spend the other 95% of their week? Incentives? Their career aspirations? Collaboration patterns? Where else the company is spending money? The demands on them work-wise, and personal-wise?
If not....you'll be missing SO much.
4/n
You are very likely to construe lack of adoption, lack of retention, etc. as maybe an education problem (if they just knew...) or a discovery problem (they can't find...) or a feature-parity problem (we need)
When it is highly likely the big challenges are elsewhere
5/n
this is especially important in B2B products that are "optional" for the most part.
Because when we tap into this broader context we can solve big demand issues vs. little optimizations.
It is (almost) never just about your product or a use-case
end
• • •
Missing some Tweet in this thread? You can try to
force a refresh
when you've found your team prematurely converging -- jumping to specifics too early -- what were some contributing factors?
...this is a weird one, but often it seems to happen when the bulk of the team is tied up with something, and a smaller group -- e.g. designer and PM -- are under pressure to "tee up" the next thing
...when the team lacks psychological safety? people just want to get it over with, so they just go with whatever seems like a reasonable deal to make the need to collaborate go away
we often experience situations where we are faced with overlapping problems
it looks a little like this ... 1/n
...except, often no one really takes the time to define the problem(s). Instead they brainstorm a bunch of ideas predicated on implicit perceptions of the problem(s)
the danger here, of course is that... 2/n
...if you bring three people together they might each see different things
One person sees one problem
One person sees two slightly overlapping problems
One person sees a parent problem with three child problems 3/n
Funny thing is that I both agree some people are really good at certain things
AND I also believe that certain environments are conducive to elevating everyone such that one person being really good at something doesn’t mean much (though it is helpful)
1) PMs and designers focus on the "next thing" 2) Developers work on the "current project"
What's wrong with this?
Outcomes suffer, even if it feels more efficient.
Why ...?
2/n While seemingly more efficient -- it causes problems:
1) information loss 2) "resetting costs" during transfer of knowledge 2) distances developer from "the problem" 3) higher work in progress (WIP), less flow 4) split focus for PMs/designer
So...
3/n When thinking about starting together, teams get a little paralyzed because they somehow can't imagine all focusing on research/discovery
You have...
A: The status quo
B: How they imagine starting together
C: How it happens in practice