JP is a Group Product Manager looking after the developer experience at Contentful, which is a popular Content Management System. Prior to Contentful, he was with Intercom where he built out their app marketplace.
Before we get going, note that document templates mentioned in this post can be found in this eesel folder.
How do you set and track goals?
We use 15Five which is a HR tool to track weekly goals and check in with managers.
Each Friday, we do the following and this gets sent to our manager:
- Mark last week's goals as completed or not
- Answer “What went well”
- Answer "What’re your biggest challenge right now and how can I help”
- Give High fives (a way to thank someone)
- Do a pulse check in (1 to 5 overall score of how you feel)
This was something I was doing before with my manager already, and not as a company thing. We used to have a Google Doc for this instead. To avoid duplication we decided to move everything to 15Five.
You can find this template in this eesel folder
I find 15Five better because it feels more like a two way communication. I get a notification when my manager sees my update, my manager has to mark my goals as ‘reviewed’, and he can leave comments or emoji reactions. There’s more of a positive feedback loop and I can feel confident that my updates are being read. As a manager I get a pulse for how my team is doing and I can bring some of the topics in next 1-1 conversations.
How do you track your daily todos?
On a day to day, I use Bear to track actions. I have one main list and group things like so:
- “Important” where I track things I’ll do this week
- “Next week” which is a catch all for everything else (I’ll get to this...one day)
- “Weekly updates” where I track things for my weekly update as they happen
- Groupings like “Small tasks”, “After holidays” that make sense based on the context
“Important” is mostly what I really keep up to date.
Let’s talk strategy. How do you create a strategy for your product group?
All strategy starts with talking to customers.
From there I roughly follow a high level structure. When starting with a blank document I start simple with scribbles and thoughts in bullet points. The goal is to share early and frequently so that you can collaborate with a few individuals in shaping ideas.
Let’s talk through a specific example for a recent strategy doc. I first started with 10 bullet points and shared that. These bullet points were a rough strawman proposal to see how aligned I was with some of my closest peers. At a high level, it included an idea of what success looks like in the future, the big premise (“the challenge we need to overcome”) and what are a few directional goals. Strawman proposals are a great way to bring people together early. If you are far off, you’ll hear why quickly.
Then I started getting more detailed and fleshed out the actual strategy document. Here is where I dug deeper into the data and validated some of the assumptions made. I also looked at comparing 2-3 scenarios we could take. The whole process is iterative, so as you have new findings you continue to seek feedback from your working group.
At this point, I had an exhaustive document that covered what market we operate in, who our customers are, what are they trying to achieve, our challenges as a business and what we need to do to address this market opportunity.
In this example, I also used the 3 Horizons Model from McKinsey to split our investments in protecting our core business (Horizon 1), nurturing emerging business (Horizon 2) and genuinely creating new business (Horizon 3)
McKinsey's 3 horizons
From here, one of the last steps is to trim the content down to a concise, readable document. No more than 6 pages (excluding anything in the appendix). This is the rough structure I ended up with in this doc.
You can find this template in this eesel folder
That's only the start of course. Don’t forget the other half of the job is communicating that strategy and making sure you have the right incentives for individuals or teams to execute on it.
Scribbles to strategy sounds quite poetic. How do you approach hairy decisions in this process?
Guiding principles are a helpful tool for making decisions. If you run into a discussion of opinions, one way to resolve the conflict is by taking a step back and asking “What are we optimizing for?”. That will help you bring the conversation from the “what” down to the “how” and “why”. I’d even encourage defining principles early on a project, so that everyone is on the same page.
This is why when writing an important document, I sometimes include 5-6 key “tenets” at the start to frame how we’re approaching our conclusions. We’ve found these really helpful for some of our toughest decisions (think: pricing). These principles are also helpful to build the narrative when communicating decisions to others in the company (in an all hands or so).
That reminds me of Atlassian’s decision sliders. On another note, what’s something you’ve worked on you’re really proud of?
One of the first projects I worked on at Contentful was to improve how we were getting insights from customer success, developer relations, and sales engineering. I wrote up a “What is a Customer Signal” document that explained to those teams the importance of writing in exact wording what the customer is asking for and explained how product teams need multiple signals to figure out insights (and root problems). We set up a Jira Service Desk portal for these teams to share specific customer signals with different product teams directly.
We report on these signals monthly (number of submissions, themes), and there has really been a broader culture that’s formed around this with lots of people consuming this page and sharing customer signal emojis on Slack for specific customer stories.
What’s something you’d like to improve about how you work?
A lot of my work is with documents and I worry that sometimes the trade off with “business case culture” is that you will gravitate towards things you can write up with good confidence and you can clearly measure. You won’t gravitate towards risky, more disruptive ideas that are harder to document with confidence. I’m curious to see how we can keep leaving space to take meaningful risks as a company.