Jann Curtis is Director of Product Management at Granicus, global leader in customer engagement and experience technology and services the public sector. With a Bachelor’s in English and Public Relations, as well as a Master’s in Corporate Communication, Jann began her career in public relations at the United Cerebral Palsy Association of Greater Chicago. She quickly realized her passion for technology and built on her communication background to transition first to business analysis, and later to product management at CompuSystems and DialogTech (formerly Ifbyphone).
In our conversation, Jann talks about the importance of understanding your audience’s “so-whats,” i.e., their purpose and what they hope to get from the conversation. She discusses how she breaks down complex topics to get everyone aligned, as well as how she emphasizes feedback loops throughout the entire product process.
It’s important to approach every meeting or presentation with an understanding of where the people in the room are at. For example, some great professionals I’ve worked with start meetings by asking, “How are you feeling today? Are you ready to work?” I always appreciate that approach and encourage it. Even though folks may be on your team, you don’t know where they sit at that particular moment in time.
I tend to rely on my early background in communication — I’ve found that the sender/receiver relationship is so important. There’s a lot of nuance in that, but it’s about the understanding that people gain something from each conversation. Before talking to different audiences, ask yourself, “Why are these people listening to me speak? What is their ‘so-what’? What is their perspective?” If you can put personas onto your listeners, you can better focus on why they want to listen to you in the first place.
For example, if sales and support are in the room with you, their so-whats are different. You’ve got to take those personas and loosely clump them together. It’s not about the individuals, it’s more about the role in the organization and why each person cares. Why are they listening? What is their purpose and what do they hope to get from this conversation or presentation? This helps you craft the conversation in a way that provides them with an answer.
It takes a lot of empathy and understanding of the roles in the organization. You’re not going to get into the nitty-gritty of every individual in the room. Instead, you’re going to understand, at a high level, what the group’s day-to-day looks like. I’ve always thought that product managers benefit from having a very clear picture. They’re a jack-of-all-trades — sometimes, they put on their developer hat with the engineering team, their sales hat when they join a demo, and their support hat when they handle an escalation call. That perspective of figuring out where each person is coming from puts the product manager in good stead.
Additionally, if you’re going into a room for an important conversation, you have to look at their data if it’s available to you. What are their KPIs? When you’re going to talk to sales leadership about the product’s sales process, for example, you should walk into that room with the context of where their sales numbers are at. Ask, “How are we doing in your area of the business?” That way, you can understand that they might not be concerned about your win rate, for example, but rather about new legislation that’s changing the landscape of how they’re selling in their market.
I take an ongoing retrospective approach, which comes right out of the agile playbook. In the world of scrum, this focuses more on process than content, but the idea is the same. For example, even when you’re not talking about development, you’re having conversations with your support team. Say you just rolled out three or four features and fixed a handful of bugs. It doesn’t have to be called a retro specifically, but do you have a regular cadence of meetings to touch base on how that went? Are you talking to support and sales leaders about it after the releases?
Also, feedback must be built into the process. In my role, we have a weekly service meeting for one of the product lines that I work with. It’s a massive meeting — every customer-facing team is represented. It’s 30 minutes long, and we start the meeting by asking, “What are the trends? What are you all hearing this week?” It’s like a retrospective, even if it’s not called that.
After discussing trends, we dig into the nitty-gritty of the individual things that we need to prioritize. That’s why we have all those people in the room — when you’re trying to prioritize something, you want feedback from everyone who will be impacted. We definitely look at support trends this way too. We also have a services meeting that focuses on success and implementation, and this just involves group leaders. It’s much smaller, and we open the floor in those conversations.
Yes — I hold office hours on Friday afternoons. This is a great opportunity for people to do important but not urgent work, like strategy thinking. Usually, people pop in or ping me first to let me know they’re going to drop by. I like this method because it books time for me on the calendar. If no one has any questions or stops by, I use the time to do prep for the following week.
I’m also a fan of doing surveys whenever they’re needed. Sometimes, conversations in formal or informal meetings don’t get into the nitty-gritty. Other times, people who are not as outgoing or extroverted don’t raise issues that are important to them. This is why I do surveys to check the tenor of the team and larger groups.
For example, we acquired a company that had its own system for support cases and migrated them into Granicus. It was a big project internally, and there was no way to do a retrospective effectively with the amount of people involved. Instead, I ran a survey about what worked well and what didn’t. I used numerical scales so I could analyze it more easily, and it was very helpful.
I’m a big fan of flowcharts and visuals. Video is another great medium to demonstrate your point. Even if you use a low-fidelity visual, it helps establish a baseline understanding. I also like to break things down into parts focused on the underlying goals or objectives. What are the problems to solve, the jobs to be done, etc.?
I also use examples a lot, often in the form of a metaphor. We’ve been changing our process to launch new functionality in the marketplace. We’re promoting it in a more organized fashion. I had to explain my understanding of what we were trying to do, and there was a series of meetings with a lot of heavy hitters in the room across the organization. Nobody seemed to be on the same page about what we were doing, so I likened it to a newspaper with different sections and columns.
I said, “Think of each product line as a section of the newspaper. You launch things in your own section, which still has the existing processes that we’re doing today, but now we’re adding a front page. You’re still going to do all the work, but we’re going to take one of your stories or features, put it on the front page, and have a headline about it.” Finally, I saw the lightbulbs go off in people’s heads. We’re not changing how each leader puts their section together, we’re just adding a front page.
One of my mentors taught me an interesting technique: say something that you know is wrong and treat it like it’s fact. People will spend the rest of the meeting arguing with you to convince you that what you already know is right. That keeps them engaged. So, if you’re expecting discussion and you want that engagement, start with something that you know to be false, as long as it’s not egregious. For example, say, “I think we should do X,” even if you don’t want to do it. Everybody in the room is going to say, “That’s crazy,” and then you can get the conversation going around why X is a bad idea.
I don’t employ this method often, but if people aren’t engaged in the topic, it’s a great way to get them to care about what you’re saying. Otherwise, if they don’t argue with you, you’re going to do X, and people are going to be mad that you did it when they didn’t want you to.
It depends on the tenor of the group. With my internal close-knit team, absolutely, but with the larger organization, it sometimes helps to let them think they’ve changed my mind. It helps to promote a perception of being open to data and decision-making. It’s a two-fold benefit in a large stakeholder group.
Of course, if you throw out something that’s completely off the wall, you want to acknowledge that you were just kidding. But if you let your audience believe they effectively changed your mind, that’s good, because you’re moving in the right direction as a group. It also gets them to buy into the path that they want to take, rather than you having to convince them and be forceful about it.
Absolutely. I struggle a lot more with modifying language, as I’m not heavily technical, but the tone, absolutely. That goes into understanding the intent of the meeting, as well as how your audience needs to hear your message. That plays a big part in how you talk to them. For example, in our quarterly product update meeting, the intent is to share information. Our goal is to pull people together who have very disparate roles and remind them of what we’re doing as a product. The tone of that meeting is completely different from a product team meeting where we’re talking about the roadmap and saying, “Oh gosh, I can’t believe we haven’t finished this yet.”
I like to start by drafting presentation documents together alongside a team member. They’ll write something on a slide, and I’ll start to pick at it. I’ll say things like, “You know, I’m not sure that’s delivering the message in exactly the way that we want.” I always emphasize knowing your audience and understanding the right level of detail to include.
The other thing I try to impart is to think about the one thing that someone’s going to remember either from a particular slide slide or from the presentation. What do you want them to walk away understanding? Don’t bury the lead.
Within our organization, we have a nice PowerPoint template that has a headline and a subhead. In product management, we’ve made a mandate that every slide needs a subhead. We reserve that section for our so-what. It’s the summary of the slide — you should be able to get the main point across in that one 14-point font section.
I find it helpful to repeat things three times. I also think it’s important to make the main takeaway one of the last discussion points. As you finish the meeting, what is the last thought you want to leave your audience with? Especially in a 30-minute conversation where no one is taking notes, I always try to restate or sum up the key takeaway at the end.
We just held a series of meetings with our executive leadership team about adjusting pricing. We presented all kinds of data and proposals. These execs aren’t in the weeds with individual products. What mattered to them was thinking about the target price uplift in each market. What’s the overall philosophy in terms of our new approach? Why are we making this change and how do we know it’s the right direction?
We made a point to start with those things, and end with them too. Throughout the presentation, we tied each item back to how it supports the overall goal. That helped drive the main points home and helped ensure everyone left with an understanding of what was communicated.
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Cristina Fuser, VP, Product at Buzzfeed, talks about how being tech-led and data-led can be a strategic advantage.
Scaled agile is an approach that allows you to extend agile principles across multiple teams, projects, or business units.
“Disagree and commit” is a management principle that encourages team members to voice their opinions during the decision-making process.
Drew Doman, VP of Product at Apptegy, talks about leveraging tenets in product management rather than strictly relying on processes.