When interviewing customers

If only they had been with me in this interview, they would understand the importance of solving this need!”?

I cringe every time I joined a customer call without a counterpart of the product trio, either design of engineering.

You may argue that not every member of the product trio should on every call with customers, and I believe it is true. Nonetheless, I would argue that being in most of them reports majors benefits that otherwise.

One of my favourite people in product, Teresa Torres, has spoken A LOT about this particular topic about interviewing together. She has defined (continuous) interviewing, as one of the keystone habits for product discovery. It means that by starting interviewing, the team can unlock other habits that reinforce the idea of discovery, such as assumption mapping, discover opportunities, and solution ideation etc.

Benefits of interviewing together

Most of us, even engineers and designers could come up with a list of benefits the entire team would benefit from. However, in practice most of the times the PM is found him/herself in those conversations alone.

We all have our own biases, and we bring them to any single interaction we have. Having at least two people running an interview helps a lot with challenging those biases, the understanding we have about the user / customer problem, and create a common level of empathy.

This is critical, because the only person participating on an interview has to translate in words that they rest can understand, and we know that some things are lost in the translation. Furthermore, we tend of emphasise the part that we feel more comfortable with or that is more appealing to us.

Another great point is that, by immersing yourself in the customer space / struggling moment / cause of discomfort; each of us can do their job better. PdM can reinforce the importan of tackling that problem, ho. Design can think and imagine the new world for that customer is the problem is solved, and engineering can push for a better solution, even if it is costly, because if would help the customer to get more value out of it (this last one would be a dream come true).

When the level of collaboration is high, especially when the trio is framing the problem wearing the customers’ shoes, we are co-responsible of getting the whole thing right, not just our own single part. Although product must ensure value and business viability, we can create a space where we can participate in design or engineering task.

Probably the easiest benefit, and I’ve suffered myself many times is what our mates of Botify mention here:

By collaborating early with the maximum relevant stakeholders, as the product trio concept recommends, not only saves time (avoid bottlenecks, duplication of tasks, sharing of information) but also provides well-being (delegate a task, learn, be autonomous).

The above is a very

Nurturing the space

I haven’t had the chance to see a trio flourish with a bottom-up approach, but I believe you need to following for such a practice becoming into a habit:

• You need people that either have worked like these and don’t want to work in another manner,

• or someone from the leadership team who has worked like this and s(he) is convinced it is the way to go,

• or the team is really struggling to get the things done, and they try a new approach.

Regardless of the context, I think there are things that leaders can do to reinforce the idea of interviewing (and starting) together, such as:

• Avoiding the big-bag approaches, such as “Hey, from now on we are working in trios” and no guidances is provided whatsoever.

• Leaders expect the entire trio to be communicating decisions on what the team will do, the struggling and/or problems they have discovered, the solutions they came up with and tested, the learnings and insights they have acquired.

• Busting the figure of the Super-PdM that has everything under controlled and knows every single little detail about everything. This kills collaboration and opportunities to innovate within the team.

Sync + Async work

Most of the complains and arguments I’ve heard from team members to avoid participating in interviews together is the time that is consumed on meetings.

I would strongly advocate for team members to not attend every single meeting that the PdM has with a customer. However, the main point to understand, is the trio doesn’t need to sync many times. Most of the job can be done asynchronously. In fact, I would dare to say that the steps of forming an opinion about the discovery work, can be done individually.

Then you synchronise with the rest of the trio (discuss), and eventually the person in charge of making the decision can do it individually, and communicate the result.

In my job, I encourage the designer and tech-lead who attend the discovery interviews to jot down some notes, digest what has been said by the customer, then we sync to create a shared understanding of the interview, and eventually we end up documenting the most important nuggets.

Trio moments of sync work:

• Discuss about discovery work (once a week)

• Sync with leadership (once every month)

• Ad-hoc meetings to share something very critical (it depends on the message to communicate, sometimes not the entire trio should be here)

Spend time smartly

As I previously mentioned, time is one of our most precious assets and we should invest it wisely. For that reason, we have come up with a series of meetings that we have agreed upon not participating all, unless someone of the trio deliberately asked for it.

Some of the meetings are:

• Discussions with our own bosses about discovery work (each of us provides updates to our bosses about what we’re doing)

• Updates with customers about roadmap (mostly responsibility of the PdM)

• Introduction of a new feature (mostly PdM considering that the feature has bee already validated)

• Sales calls with new customers (this is one of the situations where mostly the PdM is involved)

• Technical conversations about a bug

Conclusion

At this point you should have a clear picture about the importance of getting different members of the product team to participate in discovery calls.

The easies way to start with is choosing the next customer call and involve either the designer or tech-lead, and get them just to listen, ask questions if they have, and write down the most important insights for them. Ask them to reflect on that individually, and then sync up with the other interviewer to create a common understanding of what the customer said. I ensure it would be very eye-opening for designers and engineers to understand how much they can impact the customer situations through the product they are building.