Cross-functional Collaboration

"Cross-functional missions at the Times... include a lot of the same skill sets that you would find at a tech company, PMs, engineers, designers, data scientists, researchers, product marketers. But the big difference is we also have editors, if it's a product space that directly shapes our journalism."

"Product managers at the Times really need to understand the blend of art and science. They really need to value expert editorial judgment as they're also looking at individual KPIs, customer research and insights, et cetera."

"Our designers... have an entire vibe coded side prototype of the Codex app... if we like it, they'll vibe engineer that prototype into an actual PR to land. And then depending on their comfort with the code base... they'll land it themselves or they'll get close and then an engineer can help them land the PR."

"If you approach it with that "Yes, and...", it's often still true. It's like, oh, both of these things can be true at once. You could have a different goal than I have, or you have a system problem local to you that is important to you and it's not important to me. That's okay, both things can exist. So, now that we accept both and can work off of each other, we're more likely to build both a better rapport and energy among ourselves because we're not just saying, "No, no, no, no, you're wrong.""

"If you are CMO and your product leader aren't married at the hip, you're just missing out on just tons of opportunity, and the likelihood of things actually working very well consistently and compounding on each other."

"Honestly, I think learn product development. Go learn agile product development... understanding those skills and those systems will, one, I think make you think differently about how to run your marketing team and, two, make you exponentially better at working with your product organization."

"Personal Operating Manual. And it helps prompt you to talk about working style together... What communication style do you like the best? How do you like to work? Do you like large uninterrupted blocks? Do you like meetings here and there? When I'm trying to get a hold of you for something important, what's the best way to do that?"

"A lot of old contracts and handoffs between traditional roles, like say PMs and engineers and data folks has now been broken and people are really getting adapted to this new way of working together and kind of owning the same feedback loop in a way. Because previously, I feel like PMs and engineers and all of these folks had their own feedback loops to optimize. And now you need to be probably sitting in the same room. You're probably looking at agent traces together."

"One of the things that I think is sort of hard about tech companies is these silos between designers, product managers, and engineers... the common language that everyone shares is code. Ultimately in software tech companies, everything that we're talking about need to eventually flush out in terms of code. And so what if the language becomes actually working prototypes and working applications?"

"You got to be fluid because again, when designers can code and engineers can design, I mean it really becomes, you can't have a lot of structure around that. So you want to build a culture and you want to build an environment or milieu that is really, really flexible, which is uncomfortable for a lot of people."

"I've certainly seen organizations or been in organizations where the product team doesn't necessarily want to be bothered by sales, but I sort of flip that on the head and say sales and sort of the go-to-market teams in general could be your biggest asset to helping you get your job done well."

"If I've got product, marketing, and sales together in the room working on defining what our differentiated value is, then I'm going to get all the good juice out of the product team that deeply understands the product... and then I'm also going to have all the juice from the sales team that understands what the common objections are."

"I really believe in the concept of the full stack builder... I think it's all about the loop, not the lane here. And so I think that whatever function you are, you have to be obsessed with trying to understand the efficiency or the cost of the product, the actual rewards or system design that you're going after, the actual UI, UX."

"It's intentionally meant to be almost at odds, and that's part of the structure of how we want to work. ... It might be, 'Hey, we're going to move the button. Hey let's run the test,' but see the short-term lift. You know we're going to monitor it long term. You know when we ship it, it's going to be high quality, high quality polish. And you trust us to make those trade-offs."

"I think that design is most successful at impacting what ships at the end if design is considered phase zero of the engineering process, rather than a by product or a part of the product process."

"I'm like, you guys tell us what you need us to do, what the features need to be, when they need to be delivered, what the issues are, and then give us the time and space to come up with a solution to those problems."

"For us, product managers are really connectives. They connect the team, ideas, data, a whole bunch of different things, and it's very messy. There's no exact recipe for how to do it, but connecting these disparate areas and moving the team and the technology and our customers to a new place, a new vision is essentially what product managers do"

"Engineers sometimes think that they don't get the credit for their work because the PM takes all the glory and all the credit for the project that they really worked very hard on, right? So making every effort to be credit sharing and inclusive of the engineering team and giving them the opportunity to speak about their contributions when it makes sense."

"When you act like they don't matter and you don't care about them and it's just like, I don't care, just like tell me when you can get this done or why is it going to take so long? My god, this just seems like such a little thing. It just shows a real lack of empathy for the work that engineers are doing and I think it really can be very off-putting."

"If you are being asked questions that you cannot answer because you just don't know or because that's something that involves a level of technical detail that only the engineers have... and you put yourself in this in-between position... I think that is very annoying and frankly, it's a waste of time for everyone."

"When you take the people that are part of the project team out of the creative loop entirely, they're going to find that creative outlet somewhere else and it's actually kind of bad for the product."

"I've always said that the health of an organization, one simple heuristic is how close is engineering and marketing? ... you really want them being enjoined at the hip and you want engineers to be thinking about maybe how to talk about the products that they're building."

"It just be able to bring product team and engineering team, even marketing team like user acquisition, very close to each other... people are structuring, so that's more communications between previously very distinct functions."

"The way to start this... is to actually form a strategy working group. This is an important concept. So the strategy working group is sort of a small team. It typically consists of engineering, product design and data at a minimum."

"Early on, we started bringing in engineers to customer meetings more and more... it's so simple and it's so effective. When we started doing it, the response from the engineering team was great and then also it helped us dig into a different side of the customer while we were on call sometimes."

"I'm using CPTO for short code of running product and engineering design functionally together. There should be no debates over what's best for product or what's best for engineering... What is best for the organization?"

"Nityesh... built a Claude Code command that just uses that prompt, and checks through the entire code base for all the copy edits, and then creates a pull request on GitHub, and then sends the pull request to Kate... suddenly your engineering team is writing marketing copy in the style you want."

"The best PMs, I think again, create those frameworks that bring everyone else along and those frameworks also have a point of view and a strategy associated with them. So you're able to take the strategy, take the point of view, wrap it all up in a framework, and then make it so that everyone knows what the destination is and how to get there."

"The trend that we've been seeing for the past five years is the trend that is going to accelerate in the next five years, and that's a shift in emerging of roles... We're all product builders and some of us are specialized in our particular area."

"In the product-led sales, product acquires and activates a customer and product creates pipeline for sales... the collaboration here is between product and sales, but that means the product has to take on accountability over pipeline."

"It's like how do you get the marketing to product handoff right? And if it means you have someone that owns onboarding, it's in a hybrid role, then great. If it means there's a committee sort of situation with one person at the DRI, that's great too. So I think my answer is, I don't think there's one way to structure it, it's just highly dependent on the company overall. And I think you need both skill sets."

"We'll first design something without even having any idea of what or why we're doing it, but we'll design a bunch of different things and then we'll sit down with the PMs and look at the designs and just go over one and the next."

"I just think that that concept of collapsing roles, everybody needs to become more full stack to do the ... being more outcome-oriented... I just think it's a new operating mentality overall for every AI native company"

"One of the biggest things we've been tweaking is like how do we do more of a tech spike at the beginning to be like, 'Do we have a good sense of how difficult this is going to be? The unknowns? ... another problem could be like, 'Hey, it's just so difficult to work with cross-functional partners and doing a little tweak in the process where you bring them in a kickoff meeting.'"

"Performance marketing and brand marketing in a lot of organizations are two different things. And the designers that occupy brand teams bandwidth and whatnot often don't have a sense of how paid acquisition works. And so one of the pitfalls of working with certain companies or the mistake that they make is the design team will hand off a file full of random assets for paid acquisition without any sense of how the channel works."

"The solution is simple but not easy to me. It's that we need to restructure the way we make products in a way which integrates research much more fully. It looks like consistent relationships in which researchers, and the work, and the insights they provide are a part of the process from beginning to end."

"We need to dissolve the boundaries of these traditional roles... we can drop all of these different role distinctions and call ourselves builders. I think that's sort of the most general purpose way of thinking about what we can all be."

"We have design and engineering and our product partners and product marketing work really, really closely on this. Actually, it's one of the few teams where all of these things report, well, not all of them, but most of those functions report into one place. So, engineering and design actually all report up into the design organization when they work on the website. Together, quite literally, as we were talking about earlier, if we were physically together, they would be sitting side by side and they're batting ideas back and forth."

"One of my biggest points of feedback and points of consternation was the structure of the company in that we had a functional organizational model... the combination of that model and the type of leader that Jack was wasn't working in my view. I think if you're going to have a functional organization, you need to have a GM or a CEO who's extremely leaned-in to tiebreak and resolve conflict."

"The people side of this is such an incredible aspect of what product management is. What I find... is people realizing that when they're put in a position where they're expected to have impact and realizing that they haven't developed the skills, they haven't developed the capability to actually be able to manage and work through all these people."

"I think a lot of that, this craft for us happens when we give the project team this ownership and the project team is just engineering and design. Then, when they start building that feature they start seeing these opportunities that this thing could be better."

"Yes, for every project there's a project lead. That lead can be engineer or designer. It's not a formal role or it's not based on your whatever level... It's more like an assignment that now you are responsible getting the project started and working together with the team, figuring it out, and then communicating changes or communicating how that progress happens."

"The best products are going to be ENG product design and research working together as a single team to build novel things. So that's actually how we're trying to operate with basically anything that we build."

"PM should be doing everything in their power to draw the perimeter of the space, of the problem space. And it's within that, eng, design, everyone else that you're working with, they can go as crazy as they want, push up against the bounds and it's fill the box to its maximum capacity."

"You will need to get comfortable with having a partner that's a research scientist and you will need to understand that these people can produce a smart model. They'll be able to do some automation, some personalization, some recommendations on. In a lot of people, truly uncomfortable, a lot of people don't know how to approach the researchers."

"You can't be a good PM if you're not willing to do the hard boring unglamorous work of customer support, sales, marketing, writing, copy, project management, you have to do that stuff."

"Second, product manager needs unencumbered access to the engineers. If you're not working every day with a set of engineers on solving problems, you are not a product manager. So again, there's these helpful people called product owners or project managers or all kinds of different variations where they think their job is to interface with the developers and to play a mediator role."

"We created a flying formation when we were first starting the growth team at Webflow... product growth is accountable for all the metrics downstream of signups. Growth marketing is accountable for signups. They're also driving or have goals around CAC."

"You're taking the building side of the organization and the selling side of the organization and bringing it together. You're taking all of the commercial motivations and goals of the company and making sure that what you build actually solves for those goals... it's the PM in the middle, and then you have engineering, product design, and then sales, marketing, product management on the other side."

"The exercise that I often do is I generally have an idea of what I think the roles and responsibilities are and the expectations across these four roles, but the exercise especially with leaders in an org is to have them sit down and write them for each other."

"I as a product manager, I write what I think my role is and also what I think what my expectations of my counterparts are and they do the same, and then we review it together."

"if you have someone that's dedicated to a zone or an area of the product, then it's much easier for them to spot patterns as opposed to attempting to understand what's happening every time a ticket comes in."

"You bring that person together with the product person who deeply understands the backstory... And then a designer in the room and they’re whiteboarding and wrestling with each other to get to what’s a version of this thing that we believe in that’s real that we can actually finish in that time."

"I discovered that the engineers, the development team, they had a lot of people vying for their time. And if I didn't figure out how to get them to give me way more than my fair share of development, I wasn't going to have any products to make next Christmas and then I was going to be out of a job."

"The trio is the product manager, the designer, and the software engineer. If you've never worked in a well-functioning trio, this breaks people's brains, because they say, 'Well, what are we going to do when we disagree?' You're going to find an option where you don't disagree."

"we've evolved that to five legs of the stool... product eng design and we've got our insights partners. So research and analytics, and we've got our marketing partners really working in a tight team to build the best products possible... treating that as the core leadership team I think is really valuable."

"I've made it a point to bring in my tech lead and engineers along for this product discovery ride... When our engineers are able to understand our journalists' needs at the same level as we are, they're able to define the how to do it with so much greater clarity and precision."

"We said, 'Hey, we can actually do the next three months of projects about any design,' which was a kind of controversial thing to say, 'but we're doing this so that you can take three months with a set of designers and go think about the system architecture of the product, and we'll wait for that to be done before we do any architectural things that might impact the architecture.'"

"I really see it as this partnership to enable that much as possible. And I think that's what, to me, product growth looks like at Figma, is that. ...the face of Figma is not the sales team, but in fact, it's the internal designer. And so that's the mental model that I think we've been using it. We're fortunate enough to have people inside companies who are so passionate to want to play that role. And so when you take that lens on, then you start to understand, okay, how can we help set this person up for success?"

"We pick the best person who's most capable of driving an initiative forward, regardless of the function to be the DRI. We're a lot more metrics-oriented."

"Do you know your engineering manager's birthday? It's the day they showed up in the world. It's the most important day for them... Do you know their work anniversary? Do you know why they're doing the job they're doing or what they want to be?"

"I also believe that the best go-to-market orgs on the planet are equal parts revenue driving and R&D... if we can do an excellent job of translating all of that feedback into signal and then feeding that into the road map, we can be actually an extension of the product management org."

"They will apply a first principles product mindset to their understanding of the law, and they will push the lawyers to make sure that they're not being overly conservative, which sometimes they can be."

"A PM is a conductor. It's as though the team that you are a PM on is an orchestra. There are many different functions in your team that includes legal policy, comms, data analytics, engineering, design... your job is to make sure everyone's playing their part correctly, every section in the orchestra is playing their part, but at the same time, they're playing together"

"Slack has this really great feature called huddles where you can just quickly get on. It's just audio. So there's no video. And you can just have a 30 second conversation. It's good for standups and things like that... trying to be asynchronous, using Slack, making sure you're following up in very visible ways where people can see."

"One of my obsessions has been bringing design earlier into the process of product development... Having the designer hear these things and contribute gives them a golden gut as they are then sitting down later and going through possible interfaces to solve the problem."

"Make sure you go somewhere where you have a good engineering partner. Because if you have great ideas of what to build but you can't get them built, then you go nowhere. So that has to be part of your evaluation criteria that you meet and value your engineering partner before you join. And then I think what's really important is that you're aligned. You understand your roles and responsibilities and where you're going to divide and conquer and where you're going to be aligned. You don't want any of this ... Like people in the organization, they ask mom, they asked dad and they got different opinions and playing one against the other. That doesn't work."

"If somebody would ask me something that it was in Cal's domain, I'd be like, 'Did you talk to Cal?' I would never try and go around him. So we were very clear on, you're going to drive this, I'm going to drive this. And if it was unclear, we'd talk and we would say, 'Okay. Who's going to take this one?'"

"We call our org, it's called AMPED, A-M-P-E-D. This is actually going back to our earlier point... removing barriers or silos cross-functionally. AMPED stands for analytics, marketing, product, engineering and design."

"My fundamental approach to solving that is to ensure that the product leads who are working on these capabilities can instantly raise their hand and call out that there are challenges that they are running into. Then the job of the leadership team... is to essentially go and quickly resolve those issues."

"My biggest advice to both the EMs and the PMs, is before you try to solve the conflict, it's like pushing to ship this feature, pushing to change the approach. Just make sure you actually understand what they care about... if you really deeply understand what everyone wants, there's usually a compromised solution that gives everyone exactly what they want."

"I think this idea that same perf rating for both drives a level of one pain, but the right perspective... you all get graded the same score based on your ability to evaluate and solve for the entire set of constraints, not just your functional constraints."