Jason Kirby is Chief Product & Technology Officer at Magic Memories, an international entertainment technology company. He began his career as an engineer and worked for companies such as Sitel and TD Ameritrade. During his time working at Solsoft, he transitioned to product management and later joined LogLogic. Most recently, he served in various product management leadership roles at Infoblox and Cradlepoint before moving to Magic Memories.
In our conversation, Jason talks about how to instill a lightweight product delivery process, including removing rituals and dogma, and implementing frameworks that work best for the team. He discusses best practices for how to handle the difficult — and all-too-common — situation of saying no to stakeholders. Jason also discusses the importance of shadowing customers and looking for microexpressions as they navigate a product.
Magic Memories sits in the retail photography space. We partner with many large attractions, such as museums and aquariums. For example, we partner with the Natural History Museum to capture photos and videos of attendees and then create custom memorabilia, like having a T-Rex chase them in a photo.
The digital and physical products we create are sold directly to customers. They can be pre-sold as part of the customer’s entry ticket, purchased during their visit to the attraction, or bought online after their trip. We operate in 13 countries, including mainland China, with a couple hundred locations worldwide.
One universal concept is that nobody knows what product management is! The definitions of the role and responsibilities can vary dramatically depending on the company, segment, and market. Sometimes, the PM role is structured to be creative, but other times, it’s positioned to be more akin to project management. Often, what you’re expecting to do when you enter a PM role ends up being much different from the things you actually need to do.
Another universal element relates to the idea that though we address the needs of the customer, that’s usually the fourth priority for the business. The first is always going to be revenue generation. The second and third priorities are market awareness and customer attraction. Also, the definition of “customer” is much broader than just the person buying the product — it also includes all of the support and internal organizations that facilitate the product purchase, such as sales, marketing, operations, etc.
Lastly, it’s almost certain that you’ll have to say no to nearly every single person in the company at some point in time. The challenge is that you need to build high levels of trust and confidence with the people you’re saying no to so it’s not poorly received.
A big part of successfully saying no comes down to people and relationship skills. Just be direct and honest about the reason why. Saying, “Because it’s on the roadmap” is a pet peeve of mine — it means “sod off, we’re never going to address it.” It’s better to directly explain why something was decided and the rationale behind it.
I like to also incorporate folks into the decision-making process. When you do that, they’re better aware of how an answer was determined and that these decisions don’t happen in a vacuum. At the end of the day, product managers don’t usually make the decision. The buck is always going to stop with the executives and the board, so the art of saying no comes down to informing people about what led to that decision. That way, they know it wasn’t a personal reaction to their ideas.
In my opinion, it’s always worth talking to and conducting interviews with existing customers. Talk to the budget holder and their boss, as well as the people who are actually using the product. Often, their opinions of it could be very different from each other.
If you have a sales team, lean into them — part of their role is account management. With that said, be cautious in this approach. Salespeople can be unintentionally biased toward their favorite customers’ needs, so leverage your sales folks for leads rather than analysis. And if you don’t have a sales team, network as much as you can. Reach out to salespeople outside of your business, even if they’re in an adjacent market.
The other nuance is that it’s helpful to get pain points and problem sets to solve, but it’s important to realize that this approach doesn’t necessarily cover market expectations. It’s human nature — we’re great at grumping about the weather when it’s horrible but saying nothing when it’s beautiful out. This is because we expect it to be great, and the same goes for products in the market. This is why I typically find myself leaning into the marketing teams — ultimately, they know what sells.
It’s always worth calling out those limitations. The first step is asking, “What do we want?” The second question that follows is, “What can we afford?” This is essential for startup companies in particular, but it does apply to behemoths too. Then, you have to ask, “Do we want to spend all of our money on that feature? Is there another, more valuable feature?” Essentially, it’s important to consider the trade-offs.
With that being said, there’s a difference between claiming that a product is innovative in order to just sell it versus actually creating an innovative product that addresses a problem in a new, elegant way. My advice is to avoid trying to be innovative just for the sake of it.
Remove rituals and dogma. I see a lot of organizations try to shoehorn in processes, roles, and so on because a book tells them to or because the order came down from above. The key here is to ruthlessly iterate over the product delivery process, making it as lean and as lightweight as possible.
More importantly, do what works best for the team — whether that’s agile, scrum, kanban, or a combination approach. I worked with a team where we did a hybrid of agile and waterfall, which did not go well at all. Then, we went full agile because we thought that was the next best thing. Unfortunately, that led everyone to be unproductive because we were forced into an unnatural pattern.
The biggest issue in a lot of companies comes down to the responsibility of why and how it is split between different teams. Typically, product will own the why and engineering will own the how, and if that relationship is poor, that’s where everything breaks.
This is where I typically disagree with many of the usual standards. For example, I don’t believe that a user story is useful without a functional requirement or that a functional requirement is useful without a user story. This is because the user story should communicate the why and the functional requirement should communicate the how. There needs to be a conversation between the product team and the engineering team about how the functional requirement enables the user story.
Yes, but the problem persists. Sales, marketing, and engineering all prioritize different facets of the same goal, but there’s a language shift between these three areas. As a product leader, you have to be fluent in all three of these languages. Specifically, the area between product and engineering is where things break down the most because it’s the most sensitive area. As much as some might say that structure is about tech and processes, it’s actually more about communication and relationships.
I typically use the RICE framework for prioritization, and, by extension, communication. The reach and impact portions of the framework typically cover the why, and the confidence and effort portions cover the how. This way, you get a good visualization of both the why and the how. Complexity is an important factor in this and will lead to questions like, “Why or how do you think it’s complex?” Essentially, you’re doing a sniff test — are these conversations happening? How well are they happening? Are we challenging assumptions? You’re basically uncovering misunderstandings.
And then, of course, there’s the prioritization and scoping of it all. If you’re looking to reduce the scope of something, that’s hard to do without having conversations around complexity.
Sometimes, folks assume they know who the customer is. There have been so many times when I’ve heard, “We don’t need this feature because Jane would never use it in a million years.” Well, Jane’s already a customer, so whether or not she’d use the feature may not be critical information for us. What we need to say is, “Will Jill, who is a potential customer, pay more for our product if this feature appeals to her?”
Another assumption is that the product is the full journey. Sometimes, folks never stop to ask, “Does the customer need to use another system?” Or, “Do they need to do something in between steps? What happens if they get distracted?” A perfect example of this is dashboards and reporting for third-party tools. My CEO is never going to log into an account’s payable reporting tool to see what the status is. Instead, he’ll log into Power BI, which kneads that data from NetSuite or another system.
Effectively, many products exist in an ecosystem, but people can assume otherwise and then the user journey doesn’t reflect that. They often don’t embody the sales process either.
The third assumption is that the customer knows your product as well as you do. This is where shadowing and looking over the shoulder of someone using your product is the best, most informative action you can do. And if you really can’t do that, I recommend performing the full user journey as if you were the customer using your tool, as well as every other tool that they use, to complete their task.
I always assess which of my engineering teams actually used the product themselves — not built UI or made sure the buttons worked, but actually went through the user journey. Because when they do that, they encounter steps in the journey that makes them ask, “Why are we doing this specific action?” Or, “Why are we putting this thing here?” I’ve seen this so many times, especially with engineering teams.
If you’re not mortally embarrassed about your features and where the pains are, then you don’t know how well your product works. Every product is painful and could be improved, but you don’t uncover that unless you use it yourself.
When I was working with Intuit in a previous role, I watched a customer go through a process using our network management software and said, “Wait, why are you going through these 20 steps? This seems super painful.” They were like, “Oh yeah, this is just how to do it. It’s not a big deal.” But I thought that actually, it might be a big deal. It’d be awesome if that process was only one step, and they agreed.
When shadowing, I especially like watching a person’s face while they’re using a product because a third of our brain is literally dedicated to recognizing facial expressions. These are called microexpressions — it’s where your body unintentionally reacts to something emotionally. This is especially important for feedback or figuring out pain points because interviewing can only get you so far. When you’re interviewing a user, you’ll only get conscious, top-of-the-mind responses. You want to also get that emotional response without the filter of conscious thought.
Yes, and I worked with someone on this yesterday. The main things I tend to coach and direct people on have to do with roadmap slides for various departments, as well as feature releases, campaign proposals, and so on.
The first and most important thing I always tell people is to clarify what the ask is. Typically, I’ll suggest that the person build their proposal, and then we’ll review it together one-on-one. I pretty much know what the other department’s number one pain point or concern will be with this proposed change, so the first step is to address those concerns immediately. This helps prevent the person I’m coaching from being blindsided and then reacting defensively. To be fair, that’s a normal reaction, but it shuts down communication.
Effectively, every slide should include this basic outline: situation, problem, solution, and impact. First, what are we trying to achieve with this whole presentation? Every slide and every bullet point should reinforce this initial ask. I highly recommend reading the AP guidelines for good headline writing and putting every bullet point into a neat headline.
Then, I’ll review each bullet point and ask, “What are we trying to say? Why are we saying it? Are we saying it well?” In addition, I tell them that they can’t just state an opinion, they need to validate it. What data do they have to back up their points?
Finally, a really simple learning I like to share is to avoid using red when presenting to executives or the board. Red means emergency. I’ve seen this derail more meetings than not, so that’s a tidbit I like to share.
All of these tips are simple but can help you go from good to great while demonstrating your product leadership potential.
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.
Want to get sent new PM Leadership Spotlights when they come out?
Role-definition frameworks like RACI, RAPID, and RASIC take a structured approach to assigning roles and clarifying accountability.
Jann Curtis talks about understanding your audience’s purpose and what they hope to get from the conversation.
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.
Learn more →
