Giving Context
In my role as a product manager, I frequently have to transport insights, requirements, news, and other pieces of information across diverse parts of the organization. What I’ve learned is that the amount of context you give matters greatly in how your communication is received, and maybe even more important: how efficient downstream communication of your kernel of information is.
Let’s consider two examples. Names and specifics have been altered, of course.
First, an invite for a meeting between an ops team lead, a BI analyst, a backend engineer, and myself:
Hey y’all,
Bob, team lead in the Super Duper team, and Jane, our esteemed BI colleague, reached out to me to inquire about tracking the adoption of a feature that the Badass squad and Emily launched just before Emily left the company, in mid-October.
The feature is called “Item Preview”, and it’s a view that can be accessed by users before the sale of their item starts, so they can check how their listing would look plus even edit data and thus contribute to the listing creation.
A major goal of this feature is to reduce the number of “listing edit requests” that the Super Duper team receives, because these are operationally heavy tasks that cause a lot of noise and manual effort in the team. The idea: If users can edit the item pages themselves, they won’t ask us to change things later.
Unfortunately, the Badass squad didn’t manage to fit the technical backend setup in to make the desired kind of tracking possible, and this is where we come in.
Basically, Bob and Jane would like to be able to track, on item level, if any change was made to the listing using the “Item Preview” feature. Ideally, we would log each time that an update to the listing is submitted, i.e. saved, plus which fields got updated in the process.
Then BI could query this data to perform the following analyses:
- What % of Items have at least 1 change submitted via the Item Preview feature (=general feature adoption percentage)? This can also then be compared to “Which items had manual change requests?” to understand if the Item Preview really is substituting change requests.
- Which fields do typically get changed by users in this feature? This can then be contrasted with remaining manual change requests, to see if these concentrate on certain other fields, for example.
- How many fields do users typically contribute, if they make a change via the Item Preview? This is more just interesting, but not really driving any obvious actions, I think. Maybe indicative of the level of data present until this point (i.e. how correct was the data entry until then).
If you’re interested in checking out the feature in action, you can go to [a URL] and select the “Add Item” scenario. In this, you will find a navigation item labeled “My Items”. This is the feature we’re talking about here.
So in this meeting, I’d like to align BI and Backend around how we should set up the tracking in the best possible way, to specify a ticket together that the Incredible Squad can then prioritize for one of the upcoming sprints.
Hope this time works!
–David
Now, let’s contrast this with a recent sample of Slack messages that I receive on a daily basis, which have similar intentions and are printed in their entirety:
Hey David, can we attach the user in CC of this transactional mail?
Mary (Director Ops)
Hi David, I need to pick your brain for a second. Is it technically possible to send an email in the name of our user, straight out of the app?
Larry (VP Ops)
Hello David, I hope you are well. I wanted to ask you something: I know that we have not started even discussing what we need from Product, but to have a rough estimation, how many developer or designer hours are needed to: Decommission a status in the funnel? Create a new status in the funnel?
Howard (Analyst)
What do you make of this?