Month: January 2023

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:

1. 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.
2. 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.
3. 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?

In my first job as a PM, I was asked by our CPO to formulate the product vision for the product that I was responsible for. Being new to the role, I did what I assume many junior PMs would do: I googled. And sure enough, I found more fill-in-the-blank templates for constructing a product vision than there are days in a year.

Sure enough, I filled in the blanks.

But I had no vision for the product, yet now that it was in writing, I believed I could check off the task “Define product vision”. My boss seemed satisfied. All good, then!? Far from it.

Contrast this with my current situation, six years into the role. I now manage a part of a product for which I have a strong sense of direction, a ton of context, and a high level of ownership. But I have yet to fill out a template for our “product vision”.

The learning for me from these two experiences is: Defining a product vision is not something that can be mandated as a to-do. Especially when the person responsible for driving the vision creation “does not feel it” yet. It takes a lot of time of ingraining yourself with the problems of the users, their daily lives, and the role the product plays in that (or the role it could play in the vision you’re chasing).

You need to soak up the context of the product. This takes time. You’ll feel it when you have a vision. It’s the moment when talking about the paths into the future feels effortless and natural to you. Then you won’t need a template.

At least that’s how it’s turned out for me.