Justin Kim is VP, Product at Vimeo, a video creating, editing, hosting, and sharing platform. Before joining Vimeo, Justin spent 12 years at Amazon working on widely used products such as Amazon Fresh, Audible, and AWS, and growing teams of product managers.
In our conversation, Justin talks about the importance of applying ruthless prioritization across the board and curating a clear strategy and vision so as to save time later. He also discusses how the product manager role has evolved from being a jack-of-all-trades to more specialized, and how this trend is reversing course as companies endeavor to do more with fewer resources.
I’ve been at Vimeo for about two years. I run a few areas, including product management for payments and transactions, trust and safety, identity and access management, as well as strategic integrations and product platforms. I have a team of product managers who work on those individual areas. Prior to Vimeo, I was at Amazon for 12 years in a variety of roles specializing in building and growing teams of product managers.
I kind of stumbled into product management with what I would call an amazing stroke of luck, and I haven’t looked back. At Amazon, I was talking to a former manager about rejoining his team. He offered me three roles — two roles that I had done before and then a third role, which was product management. I asked him what product management was because I didn’t know. Once he explained it at a high level, I decided on the spot, interviewed, and here I am.
It’s kind of a mix. Say you’re a large coffee brand and you have coffee shops. Maybe you use videos as part of your onboarding and training for your new baristas, for example. I would imagine that it can be more effective than having to read a handbook. Rather than doing that, you can have either interactive videos or a library of content that your new employees can view and peruse. Those are more medium to long-form content.
We use Vimeo internally for our team as well for things like product demonstrations. We have a reasonably large product and engineering organization, and so as we communicate progress or milestones, we’ll use video. Again, rather than producing this big document or a PowerPoint, now we’re presenting with video. We’re finding it to be a pretty effective means of communication.
It’s a tough environment for sure. We’ve all seen the layoffs across tech, but the work continues. The most important thing for product management leaders to keep in mind is focus and ruthless prioritization. You have to be very specific with your product strategy and you must be able to say no to anything else. You also need to ensure clean, thorough, and detail-oriented execution. The gist is that you have to do the same amount of work, if not more, with fewer resources.
And how do you do that? How do you be efficient? The key to success is to invest time now. Time is precious, but it is worth it. Invest some time now to ensure you have detailed requirements or a fully fleshed-out business case — that’s going to pay dividends down the road. If someone asks you six months from now about why we made a certain decision, you have the documentation upfront.
Even though it takes a bunch of time in the beginning, the ROI on that time is through the roof. Because if you can avoid even just one pivot, one change in direction, or half a dozen meetings with execs because their questions are all answered, it pays for itself.
That’s the million-dollar question. I would say it depends on how defined and how much conviction you have with your product strategy. In other words, if you’ve got the data, customer research, competitive research, whatever it is, and you’ve got a solid plan, it’s a bit easier. You’d be spending more of your time on execution and getting stuff done.
You should always be spending some percentage of your time looking around the corner and ahead to the following year. In product management, you’ve got to keep your engineers occupied, so you’re spending a bunch of time writing requirements and prioritizing. That’s our bread and butter. But you have to pull yourself out to work on strategy because it’s going to save you time. It’s going to be tough, but once you get it and once you nail it, it’s great.
There’s been a bit of an ebb and flow to the scope of what product managers are expected to do over the last decade. When I first started quite a long time ago, it wasn’t as mature of a job family as it is today. Back then, it felt like product managers had to be jacks of all trades. You were doing everything it took to get that product to succeed. Now, product management has become more specialized. Many companies have dedicated go-to-market teams, product marketers, and product analysts, so PMs aren’t solely responsible for all of those things.
So that’s been a shift. As we talked about, there aren’t as many resources available today as there were even just a few years ago. We’re back to the world where product managers are expected to deliver results come hell or high water. But for me, since I’ve been in product management for a while, I’m perfectly happy. I like going back to being scrappy and getting stuff done.
The key to all of this is that you need to apply ruthless prioritization across the board. And ruthless prioritization is not just prioritizing your backlog or what engineering is doing, it’s about prioritizing your own time as a product manager. There’s only so much you can do. You don’t want to burn out. You need to figure out what to prioritize.
When you’re in growth mode, resources are still tight. In profitability mode, resources are even tighter. There’s a saying I like to remember, even when times are good: “You’ve got 100 things you could be working on. 20 of them would be real game-changers for the company, but you only have time to do three of them.” Figuring out what those three are, that’s a challenge because there’s so much that you can do. A target-rich environment would be a better way to put it, you don’t always have the resources to do it.
It all boils down to having a very specific product vision and strategy. The vision has to be data-driven, customer-obsessed, and customer-oriented. All the pre-work is so important. You have it well-documented, it’s organized, it’s compelling, the narrative flows, it’s convincing. You’ve got everyone on board and everyone’s aligned. Great.
Two months later, sales comes in and says, “If we just do this one thing, we can sign this deal.” Well, it doesn’t fit into that product vision. You can recognize the great idea and that we absolutely want to work on this, but if you’ve got that alignment on the product vision, it’s much easier to say no.
If you don’t have that product vision, you don’t have that document, then these are the time wasters. This is where you become inefficient. You’re looking into these requests, and evaluating them, and you have to bug your engineers. You’re spending all this time investigating something that you shouldn’t be investigating in the first place. If you have that product vision, you can say, “Great idea. Thanks for presenting. We’ll incorporate that into our next planning cycle.”
To determine what you need to build to be customer-centric, that’s where the product management skill set comes in. You have to get input from customers, but you also have to think logically. There are all these techniques like jobs to be done and user stories, but ultimately, the main thing is thinking about if customers will use the product. You have to think about what they are trying to do, versus building products specifically to extract money from them. I think that’s shortsighted.
Probably time management efficiency. You still have to deliver impact, but you have less room for unnecessary clarification meetings or changes in direction. The key is being comfortable doing a ton of work upfront. Be thoughtful about the why and what, do your homework, pull together detailed requirements that include the why’s and the what’s, and work on your documentation so it’s clear it flows well. Make sure you include any decisions that have been made.
I had a product manager move over to my team and he had been working on a project for six months or so. There were decisions made back then that were not documented, so now we’re having meetings to talk about these decisions and why they were made. If it’s not all documented, then you’re never going to find out. It saves time in the future when questions inevitably come up so that way, you’re not redoing decisions or having alignment meetings again.
This isn’t to say that you work on a huge requirement book and execute it in a waterfall manner. You just need to be clear on the context of what you know, what you don’t know, what your logic is, the problem you’re solving for your customer, how you’re solving it, and how it works. That’s the secret.
So good writing — I’m talking about long-form writing, not bullet points or lists — is where you really develop an idea. It’s an incredibly important skill for a product manager and a very efficient means of communication. If someone has a question about the project you’re working on, you can forward them the doc and they get all the context.
For example, I was working on an idea recently for a new team. I’m thinking, “What’s going to be the charter? What’s the mission? What’s the composition? Who are the people that are going to be in it? How many resources do I need?” All that kind of stuff. The idea has some validity, but I need to flesh it out. The way I do it is I just start writing.
I’ve gone through examples where I’ll get to a point of a logical inconsistency and think, “This part of the idea doesn’t work because I can’t resolve the flow of the doc.” But it doesn’t mean that I’m a bad writer, it just means the idea is bad. So I end up scrapping it.
Sometimes, I start over and go in a different direction. Then, I can resolve these open issues. Once I get to the end and have a conclusion with no logical inconsistencies, then there’s something there. I can start circulating it for feedback. If someone flags a part that doesn’t make sense, I’ll revise that. That’s how I work on an idea. Working is writing — it’s such an important skill.
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.
Sanjay Modi discusses his role in leading a website security product portfolio through drastically changing customer needs.
The acronym SDK stands for software development kit. It contains platform-specific tools to run and develop software.
If you think about some of the businesses that market familiarity as a selling point, you actually don’t get negative vibes from them at all.