Jake Sisskind is Director of Product Manager at American Kennel Club (AKC). He began his career as an IT project manager at Pure Grown Diamonds before transitioning to New Avon as a digital product analyst. Jake then joined American Kennel Club as a senior business intelligence analyst before moving up to his current role as director.
In our conversation, Jake talks about how, within a product or organization, small changes can make a significant impact, even though they don’t seem like a big deal. He also discusses how he’s tweaked and implemented lululemon’s 360 feedback model to promote transparency and openness.
American Kennel Club, or AKC, is the biggest name in dogs. We’ve been around for over 140 years, and we are responsible for the preservation and advancement of anything dog-related. For example, if you’ve ever watched the National Dog Show around Thanksgiving, AKC is behind that. We are experts in dogs. If you want to learn about a breed, find a purebred registrable dog, or if you have a question about your own dog, there are hundreds of articles on AKC that will help you through your dog journey.
Absolutely. Each role contributed, in one way or another, and helped lead me to my current position. IT project management taught me about timing — specifically how the development process works from the IT perspective. I worked with IT developers hand-in-hand to understand their needs, and timing was a huge part of that. It gave me the empathy that I needed to understand where developers are at. A lot of times, when project management comes in, they’ll say something like, “I need this by tomorrow.” Having the empathy to understand that not everything is a one-day turnaround goes a long way.
Digital product analysis enabled me to understand the data that I’m reading and make important decisions based on that. That background has been useful for inferring what data is significant and correct, as well as which questions to ask to get the data that I need.
All these experiences combined helped me along my career path, but I believe we should never stop growing. No one is perfect, so it’s important to be open-minded and learn things as you go. I want to continue to draw on these experiences and also learn from new ones.
I went through an MBA program that was focused on technical product management. In my classes, we reviewed a lot of case studies, one of which covered the lululemon 360 feedback model. The 360 feedback model is very simple. It starts from the top — when they come out with the product, and they say, “This is what’s going to be best for my customer.“ Then, it goes down the chain — from the CEO to directors, managers, corporate employees, store managers, store associates, and finally, to the customer. Next, it goes right back up — all the way back to the back CEO.
It’s a very valuable loop because no feedback is too small. Everything has its place. The fact that feedback makes it back to the top and doesn’t get left at the corporate or store level really struck a chord with me. It shows that people at the top are willing to listen to those who are more junior and that the people at the bottom have as much of a voice as those at the top. I don’t know a better way to grow than listening to everybody, accepting all feedback, and then putting that into practice.
It’s different in that lululemon is a brick-and-mortar store with an online component. You go to a store, buy their leggings or another item, and give feedback on that physical product, which they can then relay to their teams. Those teams can then come up with something tangible based on that feedback. With digital, it’s a little different. Everybody’s going to have a different digital experience, and there’s no tangible product.
The way I’ve dealt with this is to treat our digital product like a tangible one. If somebody was holding it in their hands, what would they say? What would they do? What would they feel? Get that feedback and implement it. This applies not only to digital products but to internal teams as well. Your internal team is a product. People often forget that because they’re so focused on the external-facing product, but customers also include internal stakeholders, so you have to cater to those people as well.
I implemented that mindset within my dev team and with my stakeholders because it’s just as important to improve our internal product — our organizational structure and day-to-day working environment — as it is our external product itself. In the same way that people can give lululemon feedback on its physical products, I take feedback from a user survey or feedback and implement it. Even if it’s small, knowing that someone is dealing with something significant to their experience on our website and then changing it according to that feedback is crucial.
When people listen to the experiences that other product managers go through, they’re expecting to hear a revolutionary change. But, I think the most important thing to remember is that small changes can be a big deal.
I saw this in practice when I instituted a feedback loop in my internal team of developers. Previously, most feedback came from the highest level — directors and senior VPs. They would tell me what they thought their team was trying to convey. It ended up being unhelpful because they’d say, “There’s nothing really to talk about this week,” or, “Well, they said this thing, but I don’t think it’s that big of a deal.”
But when I started talking directly to the developers, I learned it was significant to them. They’d say things like, “I can’t handle a ton of questions and my development work at the same time. I’m getting a lot of questions from stakeholders, which are great questions to answer, but I have to take time out of my development work to answer them for you and then get back into the development zone. That creates more issues for me.”
We wanted to put the questions in a place where the devs could respond at times that were convenient to them, instead of constantly disrupting their flow. It was something as simple as implementing a Q&A Slack channel where folks put questions in the channel, and whenever devs were done working or taking a break, they could answer them. Unless it was an absolute emergency and someone needed an answer right away, they could just leave it in that channel.
We immediately saw productivity increase. Devs could work their full day or do what they needed to do without having interruptions for quick questions. Not only did we get better feedback in morale surveys, but we also saw an increase in the amount of tickets that we could resolve at a certain level.
Slack is our main form of communication, but this could take the form of email or face-to-face conversation. We also use Jira, which is a great product management tool.
With that said, a lot of times, things are documented in Jira because we need to create a history. As the director, I own many of the Jira reports and get a lot of notifications. Sometimes, they’re not necessarily relevant to my product specifically, but developers would tag me without knowing which ones actually applied to me. I’d get so many notification emails from Jira, and it was impossible to go through them all. So, some simple feedback I gave to the team was to tag me in Slack or in an email if you need an answer from me quickly instead of relying on a Jira notification email.
With this change, I’m able to respond much faster and the time that it takes others to act on those responses has significantly decreased.Previously, if I didn’t check a ticket for just one day, things could get held up. So I started using a platform that provided immediate notifications or reminders of a notification, and that simple feedback allowed me to be much more responsive.
It’s been great for team morale. We had a little bit of a regime change when a principal left and a new person assumed the role. Previously, we had a bit of a “CYA” culture. Product and IT were divided and everybody was very defensive about their work. It was a culture of blame that created animosity behind the scenes. People became resentful of each other and didn’t feel like they were part of the same team.
When I stepped into my role, I decided that I didn’t want it to feel like that anymore. We have to work every day together. I instituted a feedback loop, which involves three meetings. The first is a weekly meeting with the principal and the lead engineers. It focuses on the day-to-day operations, like how to improve ticket velocity on the day-to-day or change a process in a way the entire team.
The second meeting is monthly and includes the junior developers. This is a much bigger picture but has to do with the more junior folks’ day-to-day. In those monthly meetings, we go person by person and ask, “What did we love about the past month? We praise people who did a great job at certain things, and on the tail end of their time to talk, each person shares something that’s an opportunity for improvement. We avoid being negative because that creates dysfunction. Instead, we frame it as how we feel in a certain situation and what we could do differently in the future.
The third meeting is a status update to talk about tickets. This is daily or weekly depending on what we have going on, but it helps everyone understand how things are progressing. It’s more of a project management kind of meeting, but it still gives us that feedback that we need.
It’s gotten much better over time — it’s like night and day. At first, people were still in CYA mode. They felt like they had to protect themselves because they were going to get in trouble. They didn’t want others to know if something was going on out of fear, but as I got buy-in from the principals and their managers, they started being a little bit more vulnerable in those meetings. The new principal, in particular, started feeling more comfortable.
When I started asking for suggestions on things that I could improve on and saying, “Hey, that’s absolutely a concern. I’m going to take that feedback,” and then actually followed through on it, they knew that their feedback was being heard. Everyone felt more trusting and realized that this was a safe space and that anything shared there would be taken to heart and implemented productively.
The more junior developers were definitely willing to participate, but they were hesitant to ruffle any feathers. That’s how every employee feels, but junior folks have more to lose. They don’t want to make their boss angry, right?
Giving them the opportunity and voice that they didn’t have previously was wonderful. It was just a matter of finding the way to do that, whether that was trickling down from the top or showing them my fervor for making sure that I understood and took action on their feedback. Eventually, this initiative allowed them to come out of their shells. Instead of saying, “I’ve got nothing this week,” they’d start by saying, “Actually, there’s something that I’ve been thinking about.” Everyone leaves with a good feeling after those meetings.
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?
The decision to go product-led or sales-led has such a tremendous impact not only on the product itself, but also on your company.
Parminder Mann talks about how Flutterwave works to build technology across Africa and the importance of creating localized experiences.
Quality function deployment (QFD) helps you validate whether you’re on the right path to satisfying your customers.
Learn how to use Fibonacci story points for Agile estimation, avoid pitfalls, and explore alternatives like T-shirt sizing and #NoEstimates.
Learn more →
