Episode 69: Empowering an Organization Through Product Operations with Scott White
Melissa Perri welcomes Scott White to this week’s episode of the Product Thinking Podcast. Scott leads the product vertical at AirTable, so he shares how his own organization puts into place the tools and processes AirTable supports. Melissa and Scott discuss the many benefits of product operations and how it evolves as a company grows, “global alignment with local autonomy,” Melissa’s dream product ops set up, automated roadmap review, and product management in platform companies.
Subscribe via your favorite platform:
Here are some key points you’ll hear Scott and Melissa talk about:
Scott talks about his introduction to the product management field, his professional background, and what led him to AirTable. [2:02]
Scott shares why he entered the product management sphere, how his product works, and the versatility of AirTable. [4:25]
AirTable’s product development process and how product operations are conducted.
Product development should be a company-wide concern and not solely the product team’s. “Great ideas can come from anywhere within an organization as long as people have the visibility and the context into why the organization is prioritizing what that they are,” Scott says. [14:44]
The evolution of product operations and when it is most essential to organizations of varying sizes. Scott says that there are two major points where your product operations should metamorphose: “One is when you need to improve your product desperately ….. Number two is when you're drastically increasing the complexity of your business.” [17:39]
Scott shares how his product operations team sets goals, monitors strategy, and tracks the goals and metrics, to ensure that they're tackling the task at hand so that they can achieve their goals. [21:07]
Scott reveals what he believes to be the most crucial practice that a product leader can implement when conducting product operations. “I think ultimately [as a product leader] it’s critical to understand the voice of your customers when you're building products.” [37:00]
Melissa asks Scott about his transition from CEO to product leader and what aspects of his former role he carries into his new one. [38:58]
Resources
Scott White | LinkedIn | Twitter
Transcript:
Melissa:
Hello, and welcome to another episode of the product thinking podcast. Today I'm joined by Scott White. Who's a product lead of the product vertical at air table. So welcome Scott.
Scott:
I'm Melissa. Happy to be here. Thanks for having me.
Melissa:
Great. So you have had a very illustrious career in product, um, worked across a lot of different stages of companies, um, big companies in Silicon valley and all over the United States. Can you tell us a little bit about how you got into product management, um, and what led you to Airtable?
Scott:
Yeah, absolutely. So I've been working in and around product management for about a decade now and like a lot of folks of my vintage. Uh, there wasn't really a clear path for product management when I started out, um, there weren't really as many, you know, associate product manager programs or things like that, except at the really big companies started, uh, at a role at Dropbox actually working on a whole bunch of things. I worked on sales, I worked on marketing, I worked on corporate development, kind of like the era of the Swiss army knife business person, uh, inside of startups. And it was awesome because I got kind of across a lot of different teams in the organization and how they solve problems and how they roll into the larger company strategy. And like a lot of product folks, I sort of fell into the role, uh, through a manager who went to a different company called wealth front, which is a consumer FinTech business.
And I got hired as a product manager there, uh, initially thinking about their marketing strategy, acquisition strategy and sort of paid marketing, uh, management. And then over time I transitioned more into a core product manager role managing a lot of their new vertical business lines and new product offerings that they would put out on top of their platform. Uh, and then from there, I, uh, went back to the kind of growth side at Instacart in more kind of retail, consumer marketplace type environment. Uh, and then after that experience, I started a company actually, uh, in the low code, no code DevOps space, and then the founding team of that company, we were acquired by airable, uh, last year. And now we're really focused on delivering the vision of, of no code, low code within, uh, the broader context of democratizing software development, not just making it easier to test software, but really making it easier for anyone to build software, uh, for business applications in the context of what they're doing for work.
Melissa:
And I guess that's how you led into doing this product vertical at air table, right? Because now you've created a way for people to have different tools to do product management. A lot of flexibility I've noticed, um, I've always been a really big fan of air table because I find that my process doesn't fit neatly into any other framework that's quite out there. So I try to create my own, but how'd you get, um, the idea to start all of these tools within air table? Like why enter the product management space and, and what does your product do now?
Scott:
Yeah, absolutely. So I think that, you know, what we've seen an air table is a very flexible, that is something that we often described ourselves as kind of a Lego kit, where you can adopt any kind of primitive, like a, uh, view, a timeline or a calendar and visualize specific data in any ways that you want to, without being super opinionated about precisely how you do that, leaving that kind of up to you. But over time, what we saw is a lot of our most successful implementations and our happiest customers, uh, adopted us for specific use cases. Uh, and so we kind of developed this hypothesis by seeing it in the market and seeing for successful in terms of sales perspective and an adoption perspective. And so we went out and we talked to those teams and one of the big areas that people were really trying to solve on air table is this concept of product operations.
Because right now, so much of this historically has happened across a mishmash of tools. Engineers might work in something like JIRA where marketers might work in something like Marketo, sales people are working in sales for vendors are sort of responsible for pulling all of this data and all of these signals into a cohesive strategy, uh, and then figuring out what they need to do and then orchestrating the process. And if you do that across all of these different tools, it's immensely challenging. Cause oftentimes product managers won't even have access to those things. And so, uh, at airtable people get a lot of value in pulling all of this data into one kind of source of truth, where they have a lot of flexibility about how they can manipulate it, uh, per the process that they wanna set up in their organization and how they feel like they wanna manage their cycle while still being able to work with all of these other tools across all of these other systems. So if engineers to, they can still work in JIRA, but the most recent status related to those things can get piped into air table and then visualized at a level of abstraction above JIRA. So it's really that flexibility that has enabled teams to adapt the tool to their process, uh, while also plugging into all of the other tools that they're already using as an organization.
Melissa:
Great. That sounds awesome. I mean, one of I used to do when we worked for insight, venture partners was try to find something like a Tableau or whatever to like pipe all the data into. So it sounds like air table is actually taking the place of something like that, that you can directly put your JIRA data or other data into that and then create your views off of it. Is that true?
Scott:
Yeah. We think about applications as kind of a few different layers. There's sort of a data layer to applications, which is what's the that's you're actually interacting with within an app. So if you're in something like greenhouse, it's the candidate and all of their attributes, uh, of their profile, all of that data layer. And then on top that there's sort of a logic layer that exists, which is if this happens, then this happens. And then on top of that, there's sort of an interface layer, which is how do I interact with this data? How do I visualize this data? And at Airtable, we're trying to solve on sort of each of those layers of abstraction with different functionality. So at its core, it's a relational database. So you can pull data in from JIRA. You can pull data in from Zendesk, you can pull data in by just putting it into the system itself, like a spreadsheet, uh, and then via an automation layer, you can kind of say, okay, well, if this Zendesk has been pulled in and it's tagged as a bug, let's now go and create a ticket that is tracked here, and then might also, if we want to get piped out to JIRA, uh, for an engineer to track there, but we're able to visualize all of that in one place and kind of see those connections in one place.
And then if you want to, you can, uh, then go one layer above that in terms of the UI layer and say, well, let's visualize this all in a kanban, or let's visualize this all over a timeline view so that we know how we're sort of, um, burning these bugs down over time. And so we allow you that flexibility to pipe the data in that you want and kind of shape it the way that you want, and then automate the process of kind of how that data is flowing and moving around on the logic layer and then visualize it however you want per the process that, uh, fits you the best.
Melissa:
I'm, I'm definitely gonna go play with this right after this call to see, see how I can plug all my things in there. Um, so we were talking a lot about, and you mentioned product operations, right? Being a huge part of this, um, the importance of it, especially in scaling companies and, uh, air table and what you're building for. It has a key role there. How does air table use the data that you have that you can actually, you know, use yourself in your product operations teams and across your product teams? Like what, what does your product operations look like?
Scott:
Yeah, so absolutely. I think if you think about product development generally before thinking about product operations, it's sort of a, a life cycle. So you have a company strategy and something that you're trying to do, and then you have access to all of this data about your customers and your market, and kind of what's happening in terms of the usage and adoption of the products that you're selling. Uh, and at the same time you have all of this qualitative data that's coming from customer interviews, that's coming from, uh, user research experiences. And so you formulate sort of a hypothesis, a product hypothesis based on what you're seeing from all of these different signals. And so that's like on the very early side of this cycle, you come up with an idea or a hypothesis based on some signals, and then you have to go and figure out how do we actually build something that aligns with, or tests this hypothesis.
So then you build out a bunch of ideas. You maybe run a bunch of brainstorm, you come up with, uh, all of these potential initiatives and then you have to figure out, okay, when do we wanna build these, let's go and create a roadmap, uh, around these and sort of plan. When we think these things are gonna happen, then you might break those specific projects down into things that are actually achievable for engineers and designers and various stakeholders to work on. They may process through things like sprint planning or something like that. Uh, and then you actually plan the launch of the thing and you launch it and then you have to learn how it did. And did it actually validate your hypothesis or did it not validate your hypothesis? So if you think about that as sort of the, the life cycle of product development, it's actually immensely challenging both to manage any one of those processes, uh, but more importantly, to manage the connection between those processes in that whole cycle.
So when we think about the data that we're using in our product development process and that lots of teams use and their product development processes, uh, we can start with something like customer feedback. So this kind of customer feedback might live in a place that product managers are not even in on a day to day cadence. Like it might come from something like Zendesk, where your customer support team, uh, is managing, um, you know, tickets and those tickets might have really valuable customer feedback within them. Or it might come from something like sales calls that are recorded in gong. And these are the types of, you know, signals or data that is super valuable in determining, okay, what is the voice of our customer and what are they sort of asking for? What are their pain points or problems that we think we're now, but we're maybe not solving well enough.
So these are a couple of the pieces of data that we've created kind of off point of centralizing into one place, piping out to the people who we think are the right stakeholders based on keywords and tags, uh, of that data so that they can look at that and say, okay, based on kind of seeing a bunch of trends, uh, across a couple of different areas, I'm gonna generate a product hypothesis based on this. And then now I'm gonna sync this over to my backlog and start to run a brainstorm on it. And then once I have that in my backlog already tied to all of that feedback that is coming in, in an automated way from those tools, I can now pivot this into something that's actually on the roadmap. And when you have the layer of that connection, really beautiful or amazing things start to happen.
An example is maybe like a salesperson will submit, uh, a piece of feedback based on something they saw in a sales call that's recorded on gong. So they'll go and pipe a piece of data into this system. And then when you are the product manager, and you've kind of generated an idea based on that piece of feedback, and you put it onto the roadmap, you can create sort of like an automation or a system or something that now alerts that salesperson, that the piece of feedback that they gave you is now actively being worked on, on the roadmap. And that salesperson can now go back to the prospect or the customer that they were talking to and say, with confidence, we're working on this. This is something that we're gonna build. And that develop relationship with one individual and organization like a product manager who might be making decisions based off of it from a product perspective, but the availability and the visibility of that data is actually very empowering to other teams who use that data as a source of truth, to power their workflows, whether it's a salesperson talking to a customer or a marketer who needs to plan their launch.
And so I think that things like feedback, things like insights, uh, around analytics, those are a couple of the areas that we think are super valuable to generate product hypotheses. But then once you turn those into items like ideas or roadmap items, or sprint tasks, they can then power all these other kind of orthogonal or related workflows, uh, from all of these different team members. And that's kind of the power of having that data exist in the first place, having the flexibility to pivot that data into something else, and then having the kind of connections to these other workflows and the visibility for these other people.
Melissa:
So one of the biggest pushbacks I've been getting re product operations is, um, you know, isn't this just a communication problem. Like can't, you know, product, just go talk to sales and figure this out on their own. Can't everybody just like get together in a room and talk about it. Um, I'd love to hear about, you know, your thoughts on that. Like, is this just, you know, putting a stop is product operations to you just, I know it's not to me, but like, is it just putting a stop gap in, you know, failed communications or, or why is it more powerful than that?
Scott:
Yeah, I think that, I mean, in the old days, uh, of product management or in the early days of, of my career, I think a lot of this did happen in those conversations, but it was very lossy. And so, you know, if you are, you know, we used to run, um, weekly product reviews, where stakeholders get in a room and they sort of, uh, talk about key decisions that they want to make and they hash it out with executive stakeholders. And then maybe they'll say, okay, the product manager is gonna now make the call with all of that context and then sort of go and communicate it to the team. Uh, and, and you kind of call it a day. I don't think that flies anymore for a couple of reasons. I think one is with the sort of move to remote work and the way that the world is changing, not as many people are always in those rooms, right?
You can't always get those people into those rooms at the same time. They might be in different time zones. Uh, and so there's one thing which is from a pragmatic standpoint, it's, it's almost not realistic to have that, uh, kind of model anymore. And I think the second thing is not even from a pragmatic, you don't want that model because great ideas can come from anywhere in an organization, as long as people have that visibility and the context into why the organization is prioritizing what they are and trying to, uh, achieve what they're trying to achieve based on the goals they have and have the availability or the access to the data to formulate a hypothesis or an opinion, you actually want that diversity of thought as an organization. And that can only happen when people have visibility and availability of the information that's necessary to make those decisions.
And so, you know, engineers knowing what the company goals are because they're well documented in one centralized place, knowing where to look at that customer feedback based on the thing that they're shipping, that empowers various people across the organization to generate these ideas that can then get prioritized and built. And I think you want that connective tissue so that anyone can have that impact. Possible. If you have one sort of central point of failure, which is the product manager running around talking to various people, and all of the context is only in their head. And so I think that availability of data and structure of data is extremely empowering to the overall organization. And it's not just a function of, you know, the making communication easier between a product manager and these other people.
Melissa:
Yeah, I agree. And I, I don't think it scales, right? Like you scale communication on a one to one type of, you know, talking about all of these things, um, especially in a really large organization, like you've worked across multiple stages of organizations, really large organizations, when you are looking at, um, you know, the evolution of product operations, you had your own company startup sold it to air table. You've been at growth stage companies that were pivoting rapidly at wealth front. You've been at Instacart, you've been at Dropbox. How do you see product operations kind of evolve? And when is it needed at what stage of company?
Scott:
Yeah. So I think a, an interesting example from my career is at wealth front. You know, I joined in, I think 2015, and this is when the market was doing really well. And wealth front for context is sort of an investment management platform. And at that time was really only doing, um, passive investing that you could give it money and it would invest in a bunch of ETFs. And the market had been doing really well, but because the market was doing well, it was sort of a rising tide that lifts all ships and the company was doing it well as a, as a result of that. And they didn't really need to understand why they were doing well because they were doing well. Uh, and so you don't really ask questions when, when things were going great. And in, I think late 2015, the market really tanked, uh, and as a result of the market tanking, um, you know, the revenue stream started taking a hit of the business because they charge on assets.
So both the market was going down, so the assets were going down. And so the revenue was going down, but also people got scared and didn't as much money as they were before because the market wasn't doing as well. And so I think that, you know, as a result of that wealth front realized that it both needed to understand what the underlying mechanics of the kind of revenue, uh, you know, engine were and understanding the customer mindset around why they were, or weren't deposited, uh, money at different times. And then they also realized they needed to broaden their value proposition and diversify their portfolio of product investments. And so I think that these are, it highlights two really natural points where you need to get rigorous about understanding your process. One is when you need to improve your product, uh, desperately in a way that you need to move really quickly as an organization to make high quality decisions, because things are not going well, or you need to, uh, pivot your strategy.
That's kind of one, and number two is when you're drastically increasing the complexity of the business that you're in, or you're adding new business lines, entering new markets or entering new verticals. Because if you're just doing one thing and kind of optimizing a system, that's a whole lot less complex than managing multiple product lines and the connections that exist between those product lines, because they might be serving different customer segments and very different types of people are solving those different types of problems. So I think that those are two times that are very natural in need to get serious about product development, uh, and sort of product operations to understand things like why are, are, you know, withdrawals going, uh, up and who is that now coming from? Like that question going great. But when they're not, you actually need to answer that question. And if you don't have the right analytics, if you don't have the right sources of customer feedback in place, if you don't have the right process to make decisions quickly and kind of go through a prioritization exercise as a business, then gonna be able to adapt, uh, and, and sort of pivot, uh, on the fly.
Melissa:
Yeah. I think that's incredibly important. Um, you know, the transparency of being able to see that information that you need, but also see the strategy and the goals that you're going after. Um, I'm curious, how do you, um, either at air table or in your previous companies, how have you set up those views so that you can actually like monitor your strategy, track the goals, track the metrics and see where you're at and how did that company kind of come together to evaluate, like, do we need to make a change or, or are we going in the right path?
Scott:
Yeah, absolutely. So I think it, it starts from, I think, two different ends of the spectrum. I think one is really thinking about from a business standpoint, what is the business strategy? What are our goals and what are objectives and sort of key results that we're, we're tracking against. And so let's come level things that we think are really important. And then that becomes a lens through which can start to evaluate or think about customer problems, which might really ladder up to, or index on those goals. And so on the very kind of like high end high level business end of the spectrum, it's about understanding and breaking down and creating visibility around what those objectives and those goals are. And then on the very low kind of level or granular end, it's about understanding the voice of your customer and the problems that they're having using that kind of organizational lens as an, an understanding or, or a lens through which to view those customer problems or prioritize the ones that you're trying to solve.
And so I think step one is creating some sort of framework and adopting something like objectives or key responsibilities for what the business is trying to execute against. And then from there, you can create the various levels of hierarchy necessary to actually make sure that your initiatives are laddering up to what you think is important. So once you have those objectives, those key responsibilities, you can then start to think about, okay, what are ideas or projects that we think actually key into these, you know, um, objectives or these key responsibilities. And that's when you can then go really low and say, what are we seeing from the data and, you know, related to these objectives. So at wealth front, it might be something like, you know, we need to reduce withdrawals and that's an organizational level objective. And then you actually go and look at the data and you say, okay, where are our withdrawals coming from?
Oh, they're all coming from. Or a vast majority of them are coming from this specific customer segment, which might be a really high net worth individuals. Then you need to generate a product hypothesis about why that's happening. Well, let's go over to the tickets and the customer feedback and user research repositories. We have to say from high net worth individuals that we have tagged as that, what are we hearing from them in, in these tickets on a consistent basis is the problems they're having in the reasons that they're withdrawing money. And then you can start to say, okay, I'm hearing a few different trends based on these segments. I'm gonna now run a bunch of customer interviews and go and talk to these people and document that in, in sort of one place, uh, so that we can start to come up with an idea, oh, it looks like these people are withdrawing and then subsequently putting money in because they have these large expenditures.
Well, we think we, there's a product line that we could build that would solve this specific problem for them, maybe a short term loan product or something like that. So I think you can only really get to that level when you have the visibility around what those objectives are. And I think the structure is something like you could provide something like OKRs, then you just make sure that your system kind of reflects that hierarchy. And then you have the availability of the data, which you can then, you know, generate a product hypothesis on top of, and then start tracking in, in relation to that hierarchy. So I think that both availability of data structure and hierarchy are, are some of the things that I think about as really important ingredients for building a good product ops product
Melissa:
Like that at air table now where you've got, you know, like a view of your whole strategy that comes up and down, or, or how do you guys monitor that or track it.
Scott:
Yeah, absolutely. So we have an awesome product operations team at Airtable. And I think one of the things that we talk about a lot is this concept of global alignment or global, uh, sort of visibility with local autonomy or local flexibility. And so we have a centralized repository or roadmap, uh, where as you kick off a new project, there's a standardized process for going through like an intake, uh, form. It gets put onto the company wide roadmap. And as a result of doing that, it spins up an automated workflow around, okay, well now you're gonna go and have a product review, and it's automatically gonna schedule a bunch of meetings with all of the stakeholders who are on the project. And then you create sort of a templatized product requirements, documents, and then you go through a very rigorous process of, okay, we're gonna now break this down into something like features.
And then we're gonna start to break this down into things like tasks that we're gonna plan on the sprint level and create autonomy or, or sort of visibility across teams to be able to see all of that in one centralized place. So that sales knows they can go and look there and they'll see the most up to date information marketing can go and look there and extend that data to start thinking about how to build out a launch calendar, uh, or something like that. So that's, we have this sort of global visibility process that's dictated at the project level and then goes all the way down to the task level. But then we have a lot of local flexibility where you can take that data and then extend it and pivot it on the team level to manage whatever process you want to. So one team might really want to have their stuff visualized in a view or something where they wanna have a weekly meeting where they're shuffling things across these various views where another team might want to think about something much more from a longer term, quarterly planning resource allocation perspective.
And they wanna view, you know, swim lanes of people on a timeline. And we enable people to do that on the local level because the data is all tied to these higher level kind of abstractions or constraints via these, what we call linked record relationships. And this is an air table concept. And it's because we use our own product that we're, we're kind of, um, doing that. And so you can update all of that data. And however you want to on the local level updated status of it, you know, pipes into these higher level abstractions that other people can see, and that's really important for inconsistency across the organization and making sure that everyone's always looking at in one place cross functionally, where they can, you know, see the most upstate information and make decisions based off of it.
Melissa:
Sophisticated. I love it. , it's like, it's like my dream set up. I would love every company to have exactly what you're talking about because I wouldn't spend like three months trying to get all the data together. Every time I come into one, um, you must have seen, you know, some really drastic changes in what leadership has been able to do, how fast you've been able to set strategy, you know, how product managers make decisions with a sophisticated setup like that compared to not, you know, what do you observe about how product management works differently when you can have these tools right in your hands?
Scott:
Yeah, I think that one is I think the autonomy of decision making and being able to move faster with decisions and not have things like meetings, uh, or sort of committees making decisions become a bottleneck for the pro, um, process overall. And the second thing is having a process to automatically sort of communicate decisions and communicate changes to this roadmap to cross functional stakeholders is something that exists in scaled organizations and is why product operations is super valuable if you're at a big company, uh, and you don't have robust product operations, there might be people working across the organization on solving the same problem and having no idea that someone else is solving that same problem as them. And so I think one of the things that we do a great job of at air table, and that's kind of a first that I've seen that is added on the roadmap, as I talked about, there's kind of this automated process of reviews that are scheduled in an automated way.
And then based on going to those reviews and then going back in and adding sort of the key decisions and things that were discussed, it automatically gets piped out and emailed to all of the stakeholders or sent in a slack message to all of the stakeholders in an organization so that people can see and hear about what is being worked on across teams and what decisions they are making that might influence you as a product manager or a cross functional stakeholder in a way that you can say, oh, I didn't even like know that that person was working on that. I now know that they're working on that. There's something really closely related to what I'm doing that they're doing within that project. I'm gonna go and talk to this person about that and figure out if there's a way that we can design this with some small changes to adapt, uh, and solve kind of both of our problems that we're, we're trying to solve.
And so I think that a big part of it is by virtue of having that process, it makes that communication happen by default, where it would have to be, uh, a decision before where you go and, you know, schedule a meeting with someone to go and tell them that you're working on something just would have to be lucky to be in the same room with you, uh, when they're making that decision, or they're doing that product view by virtue of having that process and having it automated and baked into the, the flow, uh, you know, that visibility and availability of information just becomes a default thing. And then people can use it to make better decisions or to inform their roadmaps by virtue of what other people are doing. And if you're working in silos and you don't have that standardized process, you're never gonna get to that level of visibility.
Melissa:
Yeah. Oh, that sounds wonderful. I'm sure everybody listening to this right now is like, why can't we do that right now? and you can, you can, so, um, that sounds great. Also, I wanted to get into a little bit that might have something to do with what we were just talking about with roadmaps air table is a platform product. Right. And you verticalize it with a different tools on top of it. I always get a lot of questions about, you know, how do you do product management in a platform company, right? How do you set the roadmaps? How do you balance those trade offs? How do you think about, you know, somebody building the front end pieces that go into the platform and the back end, H how does it work at air table? Like how do you structure yourselves and how do you think through aligning and prioritizing your roadmap?
Scott:
Yeah, absolutely. So I think that, you know, there are a couple of different layers here. I think one is, uh, how do you think about the customer segments that you're sort of approaching and the problems that you want to solve, and then something is around, how do you build the right capabilities that are going to be extensible enough across enough of these customer segments? Um, if you're building sort of this, this platform and how do you think about focusing on different personas? And so from a company strategy perspective, I think one of the things that we've seen and this kind of aligns with, I think the overall theme of this conversation on sort of the product development life cycle and, and needing understanding insights and the priority, or the sort of opportunity of different initiatives when we clear. And we were looking at, uh, okay, you know, we have now gotten some product market fit, building this platform, and we have sort of enough scale to look at our customers and understand how they're using it.
We looked at the most successful implementations of air. So where are we from a data perspective, closing the most deals? Where are the people the happiest, where are people really doing a great job, solving their problems on air table? And with the availability of that information, we're able to see that there are a couple customer segments that people are having a lot of success with. So based on that sort of data, uh, that we, you know, was more of a structured piece of data, we could then go and have conversations with those people and say, what are the problems that you're trying to solve? You know, what kind of verticals are you in? And we started to see a couple that popped up as really, really successful for air table. And they're solving problems that are sort of very, um, unstructured in nature, where they're managing work across a lot of different tools.
They have very sort of bespoke processes that need to exist. And, uh, you know, how, how they solve those problems or go about them is never quite the same in an organization and teams like product teams, teams, like marketing team sort out these processes. And so we said, okay, now we need to understand what these workflows look like, how we think about orchestrating the key phases of these workflows. And I think one of the big things that we've learned at air table is it's not about replicating the entire workflow in one place. It's about becoming the orchestration layer or connection layer between these various aspects where we don't, you know, always wanna replace JIRA, but we wanna be cognizant that people, you know, a product manager might not always be in JIRA, but the information that is in JIRA is very valuable to, uh, sort of, you know, um, making decisions based on when things might land on the product roadmap, for instance.
So I think when you think about a platform organization and how you think about prioritization, I think you have to get serious if as particularly if you're enterprise and you sort of wanna scale your, go to market motion, you have to understand specific articles that might get unique value out of your product and where you might want to specialize your go to market motion as well. But you wanna make sure that you're not overbuilding, uh, for only those verticals and not giving yourself the space to be, you know, appealing to the more long tail, uh, of users or the broader market that might not be solved the same problems as those verticals. And so I think that an important thing at Airtable is that we're not only ever solving for one. Uh, and so I think two really big ones that we've seen a lot of success on that we're really focusing on a lot are digital product development and, uh, digital marketing teams.
And if you design for multiple verticals, you sort of get the right mix of, okay, well, here are the primitives that we need to build that are horizontal in, in nature enough that it's gonna solve for both of these two, but then we can leverage things like integrations to be hyper specific on the sort of vertical layer to integrate well with and get the data from the tools that people are using. And so that's sort of how we think about prioritization, a, a vertical versus horizontal perspective in, in the primitives that we wanna build. We always wanna make sure that we're not only designing for one vertical and sort of overfit our product, uh, design for multiple. Then it sort of is a good constraint that forces to design in a horizontal.
Melissa:
That's really interesting. I like thinking about, you know, solving multiple things and then figuring out how can you fine tune it. You came from wealth front too, which was not a platform, uh, you know, product company. What, uh, have you found it harder to do platform product management or what's different about it? Or how have you changed the way you think besides just thinking a little more horizontally there?
Scott:
Yeah, absolutely. I think that they're, they're really different. Uh, and, uh, I would say that probably platform, product management is a little harder, cuz I think you always have this tension that is, you know, how horizontal do we want to be versus how vertical do we want to be? And, and that's just something that I think all platforms really, uh, face particularly in the B2B sphere. Um, but I think that when you, when you're in sort of a consumer environment, uh, the equation is super different. Like ideally you have a very specific customer profile that you're going after and you can sort of identify who that person is, what problems they have, uh, and sort of sort of develop deep empathy for that persona. And so, you know, it, you know, in some ways, uh, something like product operations, you know, you can kind of fluff it a little bit more in that context because there's just a lot more organizational alignment between, you know, or on who this specific persona is, which is why I think in a B2B context and a platform context, it's really critical to have product operations to force you to, to bring more structure to that kind of debate or, or I do think they're, uh, and, and kind one key, a lot more into something like analytics from a consumer perspective, like how you, you can start to do things like AB testing and hypothesis testing, uh, and, uh, specific things functionality that you might wanna build is that we're moving different metrics and you need a whole different set of tools and systems to manage a process like that.
And so, uh, yeah, I do think that they're quite different. Um, both, both on the persona that you're sort of targeting and the processes that you need to put into place to, um, to automate that product development process.
Melissa:
Yeah. That's really interesting. Um, so when we're talking about, uh, operations in this case too, you know, wealth front versus, um, having it in a platform product, more like airable, uh, where would you, if you were able to let's say design your product operations at either company, all these different scenarios, where would you start? Like what's the first thing you would try to implement that you found the most leverage in?
Scott:
Yeah, I think that, and this is something that's shared across any kind of, um, product that you're building. I think ultimately it's critical to understand the voice of your customer when you're building products. I think you don't wanna just say, okay, we're trying to increase revenue by 5%. Let's just come up with hacky ways that we think we can get around. Uh, you know, you wanna solve customer problems. Like that's ultimately the job I think of a product manager is to understand your customer, understand the problems that they have and sort of orchestrate the process of coming up with ideas and solutions and then managing the process. So delivering the solutions to those problems and staying close to understanding what those customers' problems are correlated to or viewed through the lens of what the company's strategy is, I think is the really critical process. So the two things I would do at both sides of the spectrum are build out the system and the way what the voice of the customer is through marrying things like feedback collection in areas like sales calls, Zend desk, tickets, and user research sessions.
So you have a, you know, voice of the customer library, where you can to really dig into that feedback, triage, it tie it to specific things that you might wanna build. And then on the flip side, getting rigorous about documenting company objectives and the strategy that the company is pursuing so that you can take the highest level stuff, marry it with the lowest level stuff, and then teams can have a lot more autonomy in thinking about precisely what they need to build that aligns with the company, stress, the voice of customer. So I think I would start on those two areas.
Melissa:
So important. And one last question too curious too, to hear how your experience has been as well, going from founder right now, jumping back into a company and being a, uh, product lead on this, uh, you know, what types of things do you take with you from the startup or what types of things do you bring with you from the bigger company into the startup?
Scott:
Yeah, I think a, a lot of it comes again down to the voice of the customer. I think when you're in a startup context and you're starting something from scratch feedback loops are the most important thing that you can get to sort of validate your hypothesis and figure out what you think you need to continue building or prioritizing. And when you have, you know, no customers, there is no feedback. And so as you start to acquire customers like staying close to those people and understanding their problems is like the lifeblood of startup, like absolutely critical. And every founder, either B2B or B2C should know by name their first, you know, a hundred customers and have talked to those people, uh, ideally on some sort of recurring cadence. And so I think taking a lot of that mindset of customer first thinking and marrying it, or, or thinking about it in the larger company context, both in terms of creating processes to, you know, automate at scale, the collection of that customer voice.
Uh, but then, you know, nothing replaces in person or on the phone sales calls with customers. So as a product person, I am still often in sales calls, uh, to understand the problems that they're trying to solve, why the things that they're doing right now are not solving those problems. Like what happens in sales is particularly for a B2B context like that is where you could solve a massive amount of your job as a product manager. If you just spend enough time in those sales calls. Now, the problem is it's impossible to do that, uh, and spend, you know, you have a lot of different things to do and you can't always spend a hundred percent of your day in sales calls, generating those hypotheses. And that's why at scale, you need to set up those systems to start, uh, aggregating that information and, and sort of decentralizing it in a way that people can, um, make better use of their time or just, you know, do, do more things. But yeah, I think that that has certainly carried over is, uh, most of the customer, um, is something that's regardless of the company size is, is absolutely small company and it's super small startup. You only have a handful of customers. You can talk to those people every day. And it's when you're a big company, you need to find ways to scale that.
Melissa:
I hope that for everybody listening to go, uh, you know, pay attention to your sales process, talk to your sales people, start to dive into that data. I is so valuable. Uh, so thank you so much, Scott, for sharing your journey with us and sharing, uh, you know, what you're working on with the air table and all about product operations. Uh, if people wanna learn more about you or connect with you, where can they find you?
Scott:
Uh, you can find me on Twitter. Um, my, uh, my name is Scott White and my handle is S C a H H.
Melissa:
Okay, great. And then, um, if you, anybody here, listening wants to go check out air table, definitely go to air table.com and check them out. Um, otherwise if you enjoyed this podcast, please, uh, subscribe to us, leave us a review, let us know what you think and otherwise we'll see you next Wednesday with another episode of dear Melissa. Thanks for listening.