Author: David

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.

As I’ve mentioned in my previous post on a DIY JTBD Workshop, there are a lot of great resources freely available on the web about Jobs-to-be-Done interviews. However, I’ve found a surprising lack of material on the analysis steps that ensue after that round of interviews. The Disruptive Voice podcast has an episode in which the debrief is explained roughly, but that’s as much as I could find until recently. That’s why I am going to share the steps we went through at store2be when doing a JTBD analysis project on “Why do brands hire Live Marketing?” from March to June 2020.

Continue reading “Jobs-to-be-Done Analysis: A Better-Than-Nothing Guide”

If there’s one thing that’s stuck with me from attending a JTBD interview workshop with Bob Moesta and Greg Engle, it’s this mindset of how to approach customer interviews: You’re trying to uncover patterns across different stories – and not to find the needle in a haystack!

Continue reading “There’s No Needle in the Haystack”

Two weeks ago I participated in a digital JTBD workshop with Bob Moesta and Greg Engle. The workshop was designed for JTBD practitioners who’d had some experience doing this kind of research and wanted to up their interviewing skills. After discovering Bob’s flavour of Jobs-to-be-Done during my parental leave in 2018, I had become enthusiastic for this way of doing product research. But so far, I had been entirely self-taught – based on freely available resources like conference talk recordings, podcasts, blog articles and so on. Since I’d had so much free time during my parental leave, I had enjoyed sifting through a huge mountain of podcast episodes and conference talks. But I know that there are also people who would like to learn about Jobs-to-be-Done, and do so in a more structured way while still leveraging resources that are freely available on the web.

Continue reading “A DIY Jobs-to-be-Done Workshop”

On the face of it, Shape Up is a framework for IT project management. It talks about backlogs, how developers and designers should slice projects and about stubbing an interface to figure out affordances before a complete visual design. Beneath that surface, though, lie basic truths about work and project management that I believe could have tremendous effects on the work in other business functions and teams.

Continue reading “Your Time Is A Finite Resource”

I’ve recently asked several internal stakeholders for feedback on a new product idea pitch, to build a first version of something that potentially has a high return, but also contains a lot of unknowns for us (in terms of business value). A classic bet.

As our team is using Shape Up to build products, the pitch mentioned a very specific appetite of 3 weeks, 2 developers and 1 UX designer.

Can you guess what happened?

Exactly.

And it reminded me just how much I love trade-offs. This will be fun!

Side note: I mean this with absolutely zero sarcasm. Problem-solving within constraints, making hard and deliberate decisions about what to do and what not to do, steering discussions and lobbying for understanding – I cannot image a more fulfilling role.

There was a time in late 2018 where we were having real trouble shipping the things we had planned to ship within the timeframe we’d estimated. I remember a particularly gnarly project where we wanted to enable our users to book multiple spaces within a given location – instead of being able to book just one space per location at a time. What we’d originally estimated to take roughly 3 sprints ended up taking around 5. Some people on the team will still shudder if you mention “multi-space bookings”.

For context: At store2be, we’re building a platform where brands and live marketing agencies can book promotion spaces in physical locations such as shopping malls, train stations, universities, airports, public spaces and more.

Since then, we’ve started to implement Shape Up – a product development framework developed at Basecamp and put into writing by Ryan Singer a few months ago. For the purpose of this post, I’ll assume familiarity with the framework. If this is your first time hearing of Shape up, you best get started by reading the book (online or PDF) or by listening to some of the podcasts linked here.

Continue reading “Implementing Shape Up: A Case Study”