Build Your Career by Collapsing the Talent Stack | Scott Belsky (CPO Adobe)

Well, it's one of my biggest frustrations with a lot of founders I meet with. And to be an entrepreneur, to start something from nothing, whether in a big company or whether you're doing it on your own, there's a bit of a craziness to it. What drives us to do it is having this vision in our mind's eye, this passion for some future state, some future solution, something that we feel needs to exist. And what I've seen all too often is that passion gets people to take that risk, to declare some amazing vision and then build a team and convince them to join you and then set off on years of work. And then when you actually put something in the market, it doesn't resonate and you're like, wow, we built an amazing product. Like what's going on here? And it's just 30 degrees off product market fit, like there's just something wrong. And usually in my experience now that tracks back to a lack of empathy for the customer that they were ultimately serving.

My guest today is Scott Belsky, Adobe's Chief Strategy Officer and Executive Vice President of Design and Emerging products. Scott has advised hundreds of startups and writes a popular newsletter called Implications. I spoke to him about why the talent stack is collapsing and what you can do about it, how to improve the first mile experience for your product and the 4P framework for building generative and AI products. Scott is a leader who obsesses about customer empathy and keeping high performing teams as small as possible. If you enjoy our conversation, please like and subscribe to support this podcast.

All right Scott, well thanks so much for joining me. Yeah, definitely having reading Implications and have a lot of questions we could talk about.

Yeah, well thanks for having me Peter, and thanks for following along. This Implications newsletter project has been a real fun exercise in getting ideas out there and getting feedback and connecting. Connecting dots.

Yeah, it's amazing. So one of the recent issues you wrote is about collapsing the talent stack. Maybe you can just kind of briefly share what you mean by that.

Well, I think the traditional organization has always been a lot of functions and a lot of these folks across different functions working together and yeah, that's just been the way companies have been conceived and scaled for probably, you know, centuries to some degree. And the question, you know, when you're a founder and you're building something very small, you learn that one of the superpowers is when the founder is also the product leader or also the engineer and also has a design background or your co founder also is a salesperson. I mean the Things you can only do in the beginning in a non scalable fashion are actually great advantages for any new company and they actually allow you for some period of time to compete with big companies. And I've thought a lot about that. And I think the reason is of course is that you have tighter conduits in decision making and making realizations and making decisions. And so one of the things I've been thinking a lot about is how does new technology, multiplayer web apps across functions in the enterprise, the role that AI plays in connecting dots, the reduction of a lot of the bloat of these functions as a result of this technology, what you're starting to have is an opportunity where people can sort of do things across different functions, even in a larger team, and maybe can capture some of the benefits of collapsing the stack that are ordinarily only available to super small teams.

Yeah, like, you know, when you're at a startup like you wear multiple hats and you know, the theory is as a company gets larger you have to specialize. But like, I think we should question that fundamental assumption, right? Like what? Why do you have to specialize this.

Whole like producer manager thing where people, you know, you're a great product person and then you are a founder and you start a company and then eventually you're like, oh, well, I have so much management now that I have to hire a chief product officer to do all the product stuff for me, even though that's my superpower and that's how I started this whole thing. Well, maybe in this new world where AI can actually assist you in the management of your teams and can kind of give you the data that you would ordinarily have to get in one on ones every week and it can start to actually guide you in the communications you would otherwise have to spend time doing. Maybe you can actually not hire that product person and continue to lead product as well as be the CEO of the company. So that's just one example. But I think we're going to start seeing it happen and I think it's going to make products and companies better.

How do you, I mean you need like probably a pretty large product org at Adobe. How do you advise your employees to get ready for this new state where teams are smaller, like should they try to learn other function skills or.

Well, I think first of all in the incubation zone of the company where we have smaller groups of people tackling problems and groups of three to five people, in some instances they're able to have the benefits of collapsing the stack that we're discussing when it comes to how larger teams can operate more efficiently. I've been, you know, my latest, you know, slogan I keep using is that that concept of never waste a crisis, you know, as we've gone through a bit of a shaky kind of last few years post Covid world, it's been an opportunity to refactor how we work as a company. We never did mass layoffs. Most companies did. We didn't. Instead, what we did is we said to teams, you have to refactor how you do this. You have to reprioritize and shift resources around. You have to have new frameworks for how you're executing. And I think that those made us a stronger company.

Do you find that. I've talked to some other product leaders and they've. I think people are starting to speak their mind now with this economy. But do you find that actually the smaller teams can get a lot of shit done or execute very well? Smaller, empowered teams?

Yeah, sure. In the earlier days of building, it's always an advantage to again have those tighter conduits and collapse the stack in any way possible and just have fewer people that you have to have agree on anything. But the reality is that when you start to go to market and bring things to scale, there's a lot of folks that need to be involved. If you're going across geographies, if you're selling into the enterprise and need contracts and need certain security measures, I mean, you know, it's very quick, it's very easy to get to the point where you need lots of people to do something. It's about though, just segmenting, you know, and making sure you don't do that until you absolutely need to.

Got it. Makes sense maybe since, you know, you were the founder of Behance and you work for the design company that really cares about the design. Maybe can you talk about, like, what the ideal design to PM relationship is? You know, like how should. Should roles become more blurred or.

Yeah, well, the ideal design, PM relationship, the controversial answer is they're the same person. That's the ideal.

Yeah.

And in Behance, we actually never had PM in the early days for the first five to seven years. And today the leader of design for Behance is the leader of the product as well. So we've always tried to have a tightly coupled system there. And if you can find those are the true unicorns, right. People who can do that, I think that's the holy grail. Short of that, I think you have to have product and there's two types of product managers, right? There's the product manager and the product leader. A product leader sets the flag for where we're going, is constantly telling this narrative about this journey that we're on and merchandising progress and keeping our eye on the prize, so to speak. Whereas the product manager is simply day to day managing the operations and keeping people coordinated and holding us onto our roadmap step by step. But they're kind of walking looking at their feet, as opposed to a product leader who's walking, looking at the flag. I think that it's important to have a product leader. I think a lot of companies make the mistake of just hiring product managers and they end up someplace different than where they had hoped or they don't even know where the flag is planted. And then you also need product managers. You need the people who are just going to be in every meeting and are helping manage the project as well as the sort of product requirements. So that's my take. And design, of course, plays a role in both. But I always like to lead with design. I feel like that notion of a prototype being worth a hundred meetings, you know, is really important in the world of building a product.

Yeah, I think there's been a trend towards less on producing intermediate collateral, like documentation or stuff like that, more than just like building prototypes and playing with the product. It's kind of hard to know what it feels like you have in your hands, you know, I think that's great. Yeah. Okay. And when you say product leader, are you referring to someone, just to be clear, like who has, like, who's managing a ton of PMs or can like a PM be a product leader too? As long as not just too focused on the execution side of things?

Yeah. Well, I think that when I say product leader, I mean it's someone who has the capacity to really innovate and think about the world that this product is going to exist in in a few years and what it needs to be successful in that world. It's leadership. It's bringing people somewhere they don't fully understand. It's convincing people of something they don't fully believe. You know, it's all the leadership aspects. Can you have a product leader that also does the managing day to day 100%? Like, that's an amazing feat. My point though is that oftentimes a great product manager is not a great product leader, and we just have to realize that and be on the lookout.

Got it. And you, you tweeted something this morning saying That I think something about, like, to have a good vision, you have to have empathy first. Right. And maybe talk a little bit more about that. Because a lot of people think, you know, I just have to be a visionary. I just have to know where we're going, maybe talk about the order of operations.

Well, it's one of my biggest frustrations with the founding, you know, with a lot of founders I meet with and, you know, to be an entrepreneur, to start something from nothing, whether in a big company or whether you're doing it on your own, it is. There's a bit of a craziness to it. Right. And how we. What drives us to do it is having this vision in our mind's eye, you know, this passion for some future state, some future solution, something that we feel needs to exist. And what I've seen all too often is that passion gets people to take that risk, to declare some amazing vision and then build a team and convince them to join you, and then set off on years of work. And then when you actually put something in the market, it doesn't resonate and you're like, wow, we built an amazing product. Like, what's going on here? And it's just 30 degrees off product market fit. Like, there's just something wrong. And usually in my experience now that tracks back to a lack of empathy for the customer that they were ultimately serving. They failed to realize, for example, in an enterprise product that that end customer is actually always insecure, you know, with what their boss thinks of them and needs to have some sense of, like, gratification or credit in order to use a product or. Or the consumer that they were trying to engage with their app, you know, is lazy, vain, and selfish in their first 30 seconds of using a new product and has no care about the value proposition of the product in practical reality. So the passion piece, what I was saying earlier this morning, is in some ways a red herring of product. It's like what you think is supposed to drive you, when in fact what really should be driving you is your empathy with the customer suffering problem. And so if you go shoulder to shoulder with customers and you just watch their day and you ask them questions like, why did you do that? Oh, why did you take that spreadsheet and reformat it in a different way and add what you added to it, it's like, oh, because, you know, people oftentimes pass my work on as their own. Oh, yeah, that's interesting. So you would probably feel uncomfortable building a dashboard that everyone else has access to unless you Got credit for it. And they're like, well, I don't care about credit. And you're like, well, you kind of do because you just admitted that you do. Like, this is what I'm talking about. Like, that's tuning into the empathy with like what they're actually struggling with. And I think that those are some of the insights that make all the difference in building products for both enterprise and consumer.

Yeah, I think you gotta have a certain level of humidity because you can has some sort of arrogance. Like, customers know what they want, I know what they want, which doesn't lead to a good place.

Yeah, but Peter, the cheat code of course, is if you're solving your own problem. Like, that's why a lot of founders who are successful solve their own problem because they are the customer. You're, in that sense, you're collapsing the stack of empathy.

Yeah, I think that's why I found like a niche just like working on creator products, because it's like, you know, I'm a creator, so I know what they want.

Yeah.

So now switching gears a little bit, like, you know, I consider myself a pretty customer focused product leader, but I think one of the pitfalls is like, that the core users are the ones who are like the most vocal and complain the most and are willing to spend the most time with you. Right. So like, how do you like going to this first mile experience of the product? Like, how do you even build empathy for like the new users who just like, you know, if they don't like your product, they just leave. How do you even get your empathy for it? Just.

Yeah, Well, I think the, you know, the tragedy of most products is that they start beautifully simple. You know, users flock to a simple product, and then that product takes those users for granted, starts to build new features to monetize, and they also start to only listen to the customers that talk to them the most, which are the power users, the minority, the vocal minority. And as a result stop feeling empathetic for the new customers in the funnel that have no idea what this product is or how it works and how they, whether they want to use it or not. And then they end up building a very complicated product over time, and the whole process repeats itself. And then users eventually flock to a new simple product. And that's probably the Silicon Valley product life cycle that no one really talks about. And so I think you're asking, like, how do you defy that? Like, how do you keep your product accessible to new customers? How do you hold on to simplicity? I think Part of it is an obsession that is not momentary but ongoing around the first mile experience, ensuring that it gets better and better and also remembering that every new cohort of new customers is different. The new cohort of new customers, when you first launch a product is filled with these willing and forgiving lean forward early adopters, right. And they have a higher tolerance for friction. And so your first mile might work perfectly for them. And then a year and a half later the customers that are coming to your funnel are a bit more of the pragmatists and that first mile might be horrible for them. So you actually have to continually change the first mile for that reason. And also just because the world changes, like people's expectations change. People's tolerance for friction is just going down consistently in humanity in my view. And so you have to constantly iterate it. I think that's one of the hacks towards keeping a product simple enough and using tools like progressive disclosure and other ways to make sure it only adds complexity when a customer is ready for it.

Got it. And a lot of the teams that are focused on first model, like the onboarding team I've observed that tend to be very growth oriented. So they like, you know, run a bunch of experiments and like a B test everything. And lately there's been a trend more towards craft or just like believing what you should ship. Do you have any thoughts on that or.

Yeah, well, I think is the question really around as you're crafting that first model experience, how do you tune into what should and shouldn't be in there or.

I think as I've been a PM for more years, I start to have a negative impression of just experimenting everything and shipping MVPs and like I tend to want to like take my time and like do something that I feel proud of. And I don't know, I'm wondering if that applies to like this first mile experience thing we're talking about.

Well, you know, I think the, this question in my mind relates to always the question around the mvp, you know, and what is sufficient versus what do you have to really get right? And you know what, I always believe that we should try to get the minimum of everything that the customer kind of needs. The couple things that make this product different, differentiated in market, like the competitive advantage of your product should be perfectly polished before you ship and test it because that's what you're testing. Like, you know, the data is flawed if you don't get what accentuates your product most. Right. So don't, you know, always polish that to perfection. The second rule of thumb that I use with a lot of teams is, is to optimize for the problems they want to have. So what is a problem you want to have? Well, if customers flow through my funnel and they successfully sign up in droves and they immediately get some satisfaction from the product. But then they start to complain because they want to be able to do this nuance thing or they want to be able to bring in a colleague or they want to be able to roll it out to their whole organization because they love it so much or you know, all those things. Those are problems you want to have, so don't address them before you launch. But problems you don't want to have are things like I couldn't sign up or I couldn't get value out of it. I had too much friction and I didn't find my path my way. Like those are things you should never launch with because they will again destroy and skew your data.

Yeah. And those problems are usually not said out loud. Right. You kind of have to look at the data to understand if that's even a problem or not. Or try to product yourself 10 times, you know.

Yeah, yeah. What's a debate? You know, we're always looking at a roadmap and we're always looking at a feature list. We're always debating what's above and below the line before we ship something. I think these are like helpful frameworks towards making the right trade offs.

Got it. Do you have any? You know, I think you also written about how AI will hyper personalize the first model experience and Adobe has made a big bet on this. Do you have any principles when it comes to building generative AI products at Adobe? Is there any kind of rules of thumb that you guys follow?

Wow. Well, a million thoughts come to mind. But at the end of the day, I also am really focused on empathy with the problems we're trying to solve. I think that's a part of it. We've certainly pioneered a playground first approach where we test things on the Firefly standalone experience first and then we bring them into our products. We do so in ways that are progressively disclosed so you see it when you need it. We again anchor ourselves with customer workflows and pain points. We do a lot of user research. Our design team is our customer zero at Adobe on all of this stuff. So I have a design organization that battle pressure tests all of our stuff and is very honest with a couple things. Not only is the product, is the outcome good enough, is the integration good Enough. But also the ethics of it, like, what are the provocations? What sorts of safety measures should we put in place before we release these features? And our design team has been really helpful in helping us execute this strategy in the right way.

Do you have, like, a specific example of that, like, from a feature that you shipped?

Sure. I mean, we just recently launched a feature called Generative Match. And what this allows you to do is it allows you to. When you're generating an asset using AI, you can use a reference image of your own. So if you want to mimic the style that you did for that client previously, or that same color palette or brushstrokes or whatever, you can leverage that asset. And it really helps people scale their production to meet client demands. And people are pretty excited about it. But it can also be abused. People could leverage someone else's work without permission and sort of rip their style. And that's something we wanted to discourage. And so we not only made customers attest to the fact that they're using their content, we not only decided that we will not identify customers if they use someone else's asset without their permission or something they don't have a license to, but we also actually developed some technology that we made integrated by default into these flows. One is we add content credentials to the asset, and the content credentials actually say that a reference image was used. So content credentials are added to these new generated assets with the provenance and the history of the asset. And that's on, because we believe that people should be transparent if they use a reference asset. And then we also store the reference asset that was used so that if there's any future legal issue or some sort of takedown request or something like that, Adobe is in the position to help some form of law enforcement in some country or something like that. And so these are the types of things that we decided. And the design team had a big role in guiding us around. And there were great active debates in the organization about what's right, what's wrong, how much is too much, how do we make sure we ship this in a way we're proud of? And that's ultimately the bar we hold ourselves to.

That's awesome. Yeah. Whenever a new AI feature launches, there's usually like a segment of customers who are, I guess, very anti AI. So just taking extra time to think about these edge cases and the safety side of things probably helps a lot, I think.

Yeah, yeah, I'm sure. Listen, a lot of people struggle with the speed of technology these days, and if you Go back in the history when the first digital tools came around. Painters were very angry when cameras were invented. Painters were angry. Right when digital cameras were invented, analog photographers were angry. And a lot of photography associations around the world did not allow you to, to submit images or be a part of if you are a digital photographer. So it's just this repeated tendency for us to sort of be threatened and skeptical of new technology, but for good reason. Like this is, you know, this is the healthy tension that makes us do it in a better way. And you know, I've, as I've matured in my own approach to all this stuff, I kind of welcome the provocation and the outrage, so to speak, because it makes us better. You know, it's part of the conversation. We can't hide ourselves from it, we have to engage in it.

Yeah, I think one of the things that I'm really worried about with AI is just like, and I think you mentioned this a little bit. This is like, you know, images or videos become not real. Like, you know, for example, a couple of days ago with the conflict in the Middle east, like, you know, it was unclear who hit the hospital.

Right.

So, yeah. Do you think, I mean, I'm like really worried about this. I mean, what do you think about this problem?

Well, you know, so I've been worried about this problem also, you know, for maybe five years now. I mean, ever since there was this feature called Content Aware, fill in after effects that allowed you to move, remove a moving image or person, you know, from a video in seconds. And as soon as I saw that, you know, I remember thinking with the team, like, we need to launch this with the right narrative and the right safeguards and we need to start being creative of what goes right, not just what goes wrong. I'm sorry, not what goes wrong, not just what goes right. And so, you know, in our case we came out with something called Content Credentials that is an open source effort for cameras and tools and certainly Adobe tools to add information, metadata about how the asset was changed or made, what AI was used. And the intention of this is not to point out the bad actors, it's actually to help surface the good actors and help people show that they can be trusted. And I think that we're going to enter a world now where most things we're going to have to assume might not be true unless we can see the transparency of how it was made and who made it.

That's awesome. And I think there's some other products out there. Like the community knows product on X that kind of help with that too?

Yeah, totally.

Maybe long.

I think we're, you know, we're in the early days, you know.

Yeah. How about, why don't we close with this then? I think a lot of people, you know, creators, PMs, or whoever, want to explore the space. There's a lot of noise in the space too, you know, like, there's like 99 AI tools you must try. So, like, you have this, like, framework. You have this 4P framework, right, for teams or people to explore AI. Maybe you can share a little bit more about that.

Yeah, sure. You know, a common question I get from teams these days is we are excited about AI. We know it is going to impact the way we work, the volume of content we can create, the, you know, the scope, you know, of our business. But we just don't know how to get started. And so I always advise them to think about four things. You know, the first being the first P is play. Like, allow your team to play with this. It's important. And it's sometimes not so intuitive to some companies to like, let their teams just play with new tools that don't have any clear commercial value yet. But novelty precedes utility. We have to be able to play with something to start to discover its use cases. So that's the first thing, I think the second one is pilot. Like find a project that you're going to pilot this technology with and do the new way. But you have to protect. The third P is protect the people that are doing that pilot by giving them a new set of KPIs or measures that are not the traditional ones. Like, the objective of this pilot should not be to make more money than we usually make doing this or to do it more cheaply. The KPI should be whether we learn from it and whether there's something interesting here. And just completing the pilot should be the goal. And so you have to kind of protect the team, otherwise they'll take the risk and they'll be punished for it. And I think the fourth P that we talked about earlier is provocation. You have to invite the provocative questions. You have to allow people to disagree or surface their concerns, because that's part of making sure you do it right and can ship something you're proud of.

Awesome. What's been your favorite AI use case for your personal life? Like, what do you use it for?

Favorite use case for my personal life. I mean, I would say, you know, for my implications newsletters. I actually sometimes want a graphic for one of the points and I just like have no idea how to secure that graphic because it's such like a nuanced thing like old machines versus new machines or something like that. And I love using Firefly to generate assets, you know, for some of those use cases personally. And then, you know, and then I love making poems for my kids using Chat GPT. You know, there's that kind of stuff that I do get a big kick out of.

Yeah, it's, it's really good at explaining in simple words to, to my kids, like how something works. So, you know. Yeah, that's great.

All right, man.

I want to respect your, I mean.

You know, lots of, lots of new use cases to come and I'm sure life will get, you know, more interesting, you know, as they hit the mainstream.

Yeah, it's very exciting. It saves a lot of time and like, it's, it's very fun to use too. So. Yeah.