Leader Spotlight: When long-term and short-term decisions are at odds, with Steve Shepherd
Steve Shepherd is Vice President of Product Management at Indeed. He began his career as a product manager for wireless accessories at Amazon before joining PayPal. From there, Steve served as a senior product manager at Zynga, a gaming company, before becoming Director of Product at VRBO. Before his current role at Indeed, he was Senior Director of Product at TripAdvisor.
In our conversation, Steve discusses the challenge of balancing short-term wins with long-term bets, particularly since short-term decisions often yield positive returns more quickly. He also talks about how AI is breaking the boundaries of traditional product management by introducing new responsibilities, such as high-level design and engineering.
Breaking the boundaries of product management
You are a strong believer that AI is now becoming a part of the product role. How do you see this technology enabling PMs to do more?
The role of the PM is evolving dramatically. The core responsibilities haven’t changed, though. How do you gain insight into the customer's needs? How do you craft a product that meets those needs? How do you communicate that vision to the engineering team to ensure it is built properly and in a way that resonates? All of that still holds true.
Historically, in my role as a PM, a lot of the different responsibilities would be outsourced to individual specialists, and the PM would be a coordinator between them. Get a user research study commissioned? Great, the PM will receive that insight, work with UX to create wireframes, build a prototype, and test it with real users. Using that feedback, they’ll write requirements and hand them off to engineering, and then follow through to ensure that those requirements are executed and tested appropriately. It takes a lot of time, coordination, and friction.
I don't think a PM will, at the outset, be able to play the roles of these specialists, but a combination of individuals can provide insight and guidance to the product. With AI, product people can then do quite a bit of it on their own and leverage more specialty expertise when needed. The goal will be the same, but product will have a hand in all of the creation pieces through the pipeline, and, frankly, move faster.
Does this shift change how you coach newer PMs, especially those entering the field as “AI natives”?
Absolutely. There have historically been a lot of boundaries put on product. Anyone who's been around it for a while has had to learn to avoid going too deep into design or weighing in too much on the architecture. These different roles have been compartmentalized. I foresee this blurring occurring more frequently in the future. This goes both ways — I see engineers and designers now wearing product hats as well.
This new group coming in is not going to have the same boundaries inherently drilled into them the way that legacy PMs have. Instead, they’ll say, “Why not? Why can't I just go ahead and create the mockup?” Then, they’ll hand it to the engineers and have them select the pieces of code that are worthwhile. That's not necessarily something that a product person would have dreamed of before the last year or two with AI. Now it seems like it's going to become standard.
Trading off short-term with long-term decisions
In the same vein of a changing workforce, have you seen an increased challenge in managing people and products in a hybrid or remote environment?
Aside from coming up with ideas for the product, the other chunk of product management work is communicating strategy and influence, particularly in bigger orgs. Can you ensure that everyone around you — including the team executing the plan and senior leadership — is moving in the same direction?
Pre-COVID, most companies operated in person. Everybody I worked directly with was physically in my office, so it was a completely different way of collaborating. We had to adjust. Now, I work in a world where all the teams are completely distributed around the world. I haven't seen anyone who's managing this perfectly, and maybe there's a world where we can achieve better alignment, at least by time zone. We don’t always have that luxury — resources end up all over the place, and oftentimes, you have to make trade-offs for the right resource to work with you.
From there, it’s a matter of tactics to keep people in sync. We’ve seen challenges with decision-making. For example, if I send an email out into the ether, it may not be very clear who is supposed to weigh in, and it can languish out there for days at a time. We had this happen a lot, and our decision-making was slowing down because we didn't have a regular checkpoint.
So, we started stressing an async process. We call it a “decision doc.” It’s a template that compiles all the facts related to a particular decision. The doc includes the timeline we need to decide on and who the key decision-makers are. We've pushed that as a means to make better progress on decisions without physically getting together. It doesn't replace everything, but it has helped with many discrete use cases.
Furthermore, as painful as it is in these kinds of environments, it’s very helpful to be on a call together. It involves sacrifices from everybody, either early in the morning or late at night, but that's the name of the game at this point. We do this with monthly product reviews, and the entire team is invited. We need it to allow everyone to provide feedback and have a fluid discussion. It’s become table stakes for us, alongside some async doc processes.
Does this slower decision-making process make it harder to balance short-term and long-term strategies?
Definitely. It takes courage to make long-term decisions that are at odds with the short-term. And when you don't have a lot of shared understanding or time to discuss the implications of every decision, you end up with a fallback. The most uncontroversial approach is to focus on a short-term metric that we know we can drive. It's measurable. From a scope perspective, it's oftentimes a little bit more manageable. And if it shows a key metric going up, then it’ll look great. That makes it more challenging because those opportunities are tempting, especially when you have to make a trade-off with something else.
From my vantage point, the most successful companies think with a heavy eye toward optimizing for the long term. They’re thinking two years out. What are you going to do today that will set you in a different place two years from now, as opposed to two months from now? If you have that mindset, you make very different decisions. They’re harder to make when you don't have the shared context and alignment that you otherwise would have.
Furthermore, to make those courageous long-term decisions where the short-term is sacrificed, you need buy-in and leadership support, all the way to the top of the organization. With distributed teams everywhere, it's harder for leadership to impart that sort of wisdom, and it's even harder for it actually to get through. Many layers need to come together to make it happen. There needs to be clear and unambiguous guidance.
How do you set milestones that show progress on long-term bets?
From a resource perspective, it is a zero-sum game. How do you get commitment for the long term? It is about breaking it down into small milestones. You need leadership support to make a long-term bet like this. And you have to gain credibility and trust from leadership. I find it important to provide various milestones, the scope, and what you’re delivering in each of them. Give rough timing of when you think they're going to happen and the upside that each of them is going to produce.
Then, you deliver. And every time you demonstrate that you're delivering on time and performing in line with expectations, that bolsters your case for continued investment. If you are not regularly demonstrating value, building credibility, and establishing trust, your project is in danger. Even if you're doing wonderful work, if it's happening and nobody knows about it, then it's at risk.
For example, if I’m working on an architectural project with an engineering team, I try to put some pressure on to deliver something in milestone one or two. Even if it's not the full solution, I want to show something usable to give a nugget of business value early on. Then, leadership can see the potential, even if it’s not the optimal sequence of all the pieces.
There’s also some evangelism involved. You have to communicate success, cheerlead it, and let everybody know that it's moving forward. They can therefore start planning with that in mind so that everyone can sync. Because if they don't have a good understanding of what you're up to, then they're going to potentially do something parallel and not built on top of it. Your focus should be on increasing the likelihood that this initiative is actually delivered and well-integrated into the rest of the company's goals.
How do you handle conflicting stakeholder opinions, especially when people want quick decisions without full context?
I've seen a lot of big, bold ideas come in without enough context of the situation, and they often did not play out well. There are several factors that contribute to not having the proper context, including a lack of internal understanding of the technology, insufficient understanding of the customers or their experience, and misjudging complexity, among others. Of course, everyone wants product to come in and be bold, but that’s not always the right thing to do from a style perspective.
Instead, I take a more pragmatic approach. I lay it all out on the table and show the pieces that we could work on. I explain my view on why I think it should fall into this stack rank and provide justification for each of them. And if someone disagrees, I want them to push back. They may believe this growth assumption is too high or too low, and as a result, the item should be prioritized higher or lower on our list, or it deserves more or fewer resources. That's a debate that's worth having with stakeholders. I love that kind of conversation.
When you put a new idea in, it's pushing other things out. You need to understand the implications. What is being dropped below the line by you pushing something else in? That is the healthy process that a product should drive. We run into some potential landmines if we come in too hot.
The need to prove our value
What’s your approach to balancing resource and autonomy between platform teams and revenue teams?
The teams that have a handle on the levers that directly move the experience typically prove their value very easily. That does tend to be a short-term and long-term play — revenue teams can move the needle in the short run, and in a way that platform teams can't. Platform teams are the long game. That is how you win as a business. A company will not continue to run without horizontal teams supporting, iterating, and building off of them.
It's a mix. There's no silver bullet, so a lot of it’s about trying to show the value that platform teams have. How much of the revenue and sales volume is tied up through systems? If they break, what are the ramifications? If it's even down for a minute, what does that do? Showing the immense scale and impact that they have needs constant reinforcement.
Furthermore, how do you set goals and ensure alignment that keeps them in sync with the rest of the business? There’s always a risk that the platform they want to build will take years, but you don’t have that time. That's the point of failure or disaster that you always have to guard against. Hold regular syncs so everyone can be in the loop on what platform teams are building. The end teams should be asking the platform teams to build things for them. If they're not getting regular requests, then there's a communication problem.
Additionally, platform teams require metrics that they can control and align with broader company metrics. For example, API usage, throughput, or data collected are all metrics over which they have a good degree of control. If those are going up, the business does better. Try to find and identify those metrics for them to own regularly. Of course, they need to look a little bit further downstream when they're thinking about their platform product, and end teams need to put pressure on them to think of the big picture. That kind of healthy tension back and forth is necessary.
What are some common misconceptions you’ve found organizations have about product teams?
It depends on the product teams, but sometimes there’s a misconception that we're solely focused on driving metrics and that we don't care about the experience. Designers especially sometimes feel that product cares more about money, revenue, and conversion, and less about design aesthetics.
There is an inherent trait in product management that we have to take the facts as they are. We can’t be easily swayed by emotion or great design aesthetics, for instance. Oftentimes, the design looks beautiful but doesn't convert as well. Those are interesting conversations to have — “I love your design, but it just doesn't convert.”
Product is oftentimes the bad guy in those situations, because we have to be the fun police. But it's not because we don't like the design. It’s just that we’re closest to the data, and we have to drive our metrics. Of course, we care about aesthetics and things looking good, so it’s helpful when teams challenge us to look at different types of metrics. Perhaps our conversion metric is down, but are there nuggets to be found within it? Is there user research we can incorporate?
Yes, we need a data-driven reason for what we're doing, but we also can’t be closed-minded about what the data reveals. Product is probably more open-minded than we sometimes realize; we just have to have a reason and facts for actually pushing forward on something.
You’ve seen long-term success at companies like Amazon and Indeed. What made that possible?
There are many times when we made some really great long-term plays, and reflecting on them, it’s easy to wonder if I could have done that on my own. And the answer is no, I don't think I could have. It took leadership at the top of the organization to pound that drum of long-term thinking and give product managers the freedom to think that way. It doesn't come naturally. The natural tendency is just to optimize for the short run.
In the case of Indeed, we built out this rich taxonomy of jobs and the metadata associated with each one. This includes users’ resumes, job descriptions, and more, and we built a 100-person team to do this. To achieve this, our CTO personally invested time and resources in hiring a large team and building a cohesive group. That's something that an individual product person would struggle with. The long term is a great place to be if you can do it, but there needs to be a culture that supports it. Not every place can replicate that thinking as a result — it takes individuals to do that.