TBM 20/52: Questions and Context
My friend is a chef.
She has two modes: the don't worry, it will be great mode, and the ask a million questions mode. Either way, the food is amazing.
I will always remember when she helped us with a special party and asked us a million questions. What fascinated me was that she didn't ask things like "ok, do you want chicken or beef?" She asked us for stories about memorable meals, our families, and our guests. She asked about guest allergies (of course), but also asked about favorite wines, and music that captured the mood.
She took all that information and put together an amazing, almost poetic, meal. Which shouldn't surprise anyone. My friend is a chef! That's what she's great at!
Back to product and the beautiful mess. An experienced architect was grilling the product team on their product strategy. He was getting frustrated. A product manager Slacked me something like "He doesn't trust us at all, does he?" I tried to stay curious. It turned out that the architect's questions were coming from a very good place. He was contemplating a difficult-to-reverse system design decision. To make that decision he needed non-obvious information about the product strategy (even if the answer was "we don't know").
Once I knew the why of HIS questions, I was able to give him the information we had (and detail what we didn't have).
I don't regard these two examples as all that different. In both cases, you had an expert asking questions so that they could do their job. The difference was that we were good friends with the chef. We trusted her and her questions. Meanwhile, the architect was in conflict with the product team, and didn't explain his line of thinking.
It occurred to me recently that so many challenges in product development spring from what Amy Edmonson refers to as professional culture clash. An executive saying "build this" may not have the background to understand the product development nuances. It is easy to assume the worst, but they are trying to help by telling you exactly what the customer wants! The trouble is that when a designer asks meaningful questions to get the information they need to do a good job...it starts sounding SO COMPLICATED.
Until you work side-by-side people and hear them talk in depth about their work, it is very hard to understand all of this nuance and very easy to end up communicating poorly. Some construe this as mistrust — “they should respect me to do great work as a designer, and I shouldn’t have to prove it” — but I am not sure it is really like that. In many cases, it is just confusing.
Here's something you can try immediately to explore this dynamic.
Pose this question to your team:
What must you eventually know about this work to make good decisions at the right cadence?
Whenever I ask this question, I am blown away by the context people need to make great decisions. It helps break down walls. You start to understand their calculus. This post is actually related to my last post on drivers, constraints, and floats. As we gain experience, we are able to elicit more meaningful drivers.
The next thing you can try is to start with the Why of your questions. What decision will your question inform? This seems so simple, but people forget to do this all the time.