As product people one of our roles is to ensure people external to our team know what is going on and where we’re heading. That is simple enough as a principle, yet in practice, this is hard.
This week, I’ve trialed an email to share updates across all our products to send to the whole department.
We know people have been asking for more information as to what has been delivered and what’s coming. They told us so in person but also in a survey we conducted. But the question I was struggling with was – how do we know we’re providing the right amount of information?
People are likely to speak up when they have too little information. Maybe not immediately, maybe not obviously. But what struck me is that people never (rarely?) complain about there being too much information. That is also a problem, because too much information makes it harder and sometimes impossible to get to the information that is needed.
For me there’s two imperfect but complementary strategies:
- Understanding our stakeholders, their role and the pressures they face
- Trial and error, and getting feedback
Understanding our stakeholders
If we invest time in understanding the people who need information from us, we’ll be able to adapt our communication. Spending time with them, shadowing them, seeing client meetings first hand can help us understand what type of information they may need. And we should definitely do this.
However, this strategy isn’t perfect:
1 – This takes time, and when we’re new (and product people do tend to move products if not jobs fairly regularly), we can’t wait to fully understand all our stakeholders, before we need to share information. Getting them to trust us and for us to understand their world will take time.
2- Things change and we can’t predict all the changes that will occur. That could be new clients, industry changes, a new tool. We have to try to keep up with them, but doing so in real time is often impossible. So we’ll always have to combine that with the trial and error approach.
Trial and error
Trying something out and getting feedback complements the first strategy. We can make some informed guesses about what would be useful and seek feedback. However, I have often heard people say ‘we stopped sending out that information because we didn’t know whether it was helping anyone’.
For this approach to work, we have to be proactive and persistent. We have to spend at least the same amount of time trying to elicit feedback, than we spend writing the information.
If there’s too little information, people might ask follow-up questions. While stakeholders will not be able to tell us that they need to know about something they don’t know exists, they might tell us that they needed certain information earlier. So we’ll get feedback, even if it’s a bit later.
However, I’ve never heard anyone say : “there’s too much stuff in your update that I don’t bother reading any of it”. Even though I hear people say it about other people’s updates and presentations ALL the time.
And I know I’m guilty of the same. How often do you admit to someone that you don’t read any of their updates or emails because they’re too long, too confusing? Yep. Somewhere between not wanting to offend, and not wanting to look like we’re not doing our job properly, we’ll never say that. We also might assume that maybe it’s just us that don’t find it useful, so we don’t want to be the person to complain about a format that must work for everyone else.
What we can do to prevent this as the people providing the information:
- in doubt, keep it shorter and only add more if requested
- provide easy opportunities to access further detail
- most important: spend time learning to write clearly and format well (or ask someone who can help us with that)
Finally we need to also accept that our communication is never going to be perfect, and therefore we can only strive to making it good enough.
I hope this week’s reflection is interesting for some. I worry a lot about striking the right balance, not wanting to overthink things to prevent me from moving fast enough, while also not wanting to storm ahead and having to deal with the consequences of implementing a half-baked idea. So with the release notes, I went with my experience with what had worked before, plus what I’ve understood our stakeholders need, even if the information wasn’t perfect. Let’s see what the feedback will be!