Megan Quinn: A venture capitalist's views on how to scale a team

Thank you so much for having me.

Sure. So I joined Google about six months before the IPO, working as more or less a gopher in marketing on the IPO, not really frankly knowing what an IPO was or understanding or appreciating the momentous occasion that it was for the industry when Google did go public. But quickly thereafter, I moved over to the Maps organization as the company acquired another company called Keyhole, which ended up serving as the underpinning for Google Earth and Google Maps. And it just so happened, as you mentioned, that I am a historical map collector and a map fanatic, and so I was personally really interested and curious about how we could build the next generation of maps online. And this was before the sort of WYSIWYG Google Maps drag-and-drop satellite imagery kind of experience that we all know today. So I spent the rest of my time at Google, about another seven years from that point, largely focused on building Maps, specifically building Google's Maps in-house. So we originally started by licensing third-party data to get a product out into the market, and we licensed from two companies, Navteq and Tele Atlas, that were shortly acquired by Nokia and TomTom. And we don't think about this now, of course, but at the time, Nokia was quite a significant competitor for Google, a real threat we thought to the core business. And we decided that we needed to have true data independence as it related to Maps, not just for the sort of consumer product experience that you think of for business search and driving directions, but also for location-based advertising and for Android and all of these other products and projects that were underway. So I led the effort there from the product side about developing our own Maps internally, which took me across the business development organization and the operations organization. And frankly, it's still a project going to this day because once you start building maps, you can never stop. And after about almost eight years at Google, I transitioned over to be the head of product at Square. It was a transition that I made with quite a bit of hesitation. I loved my time at Google, but I started to have these recurring nightmares that I was going to be the 50-year-old SVP of some product group at Google and would have never worked anywhere else or seen any other kind of business model or worked with other types of people. And so I went out and looked for the exact 180-degree opposite experience. And to the extent that Google was at that point a fairly large company, Larry and Sergey really pushed decision-making to the edges and they themselves as personalities stepped back, and it was a very engineering-led organization. I went out to find the startup that was the opposite, and that was Square. Square was largely a cult of personality at the time around Jack, and it was obviously hardware, which I had not done before, and it was a very design-intensive, design-led organization. And so I wanted to have another experience to learn from and landed up there as the head of product. And while I was at Square, I think I joined when it was about 20 people. I oversaw our hardware and software development and built up the software product team. We eventually hired a head of hardware who was much better and smarter than me, Jesse Dorogusker, who's still there today, who came over from Apple. And I ended up leaving when the company was 400-some-odd people to go into the investing side, as you mentioned.

It was a really educational transition. So when I was at Google, I only ever met one designer. We had one designer in all of Google Maps, which was at the time the second largest Google property after google.com. And she's fantastic, the designer that we had. So she was really truly wonderful and a real thought partner in developing the product, but it was still one person to a few hundred engineers at that point. Transitioning to Square was the exact opposite. It wasn't so much that design was just a thought partner; they were really a driver of the overall product innovation process. And so we treated the engineering, product, and design orgs as this triumvirate that worked very, very closely and collaboratively together at Square to design, define, and build the products as they went to market. And that was a new experience for me. A lot of the design ethos at Square came from Apple. A number of the Square designers had previously been at Apple. That was a new culture, both around design thinking but also in terms of cadence of shipping and expectation of engineering, than what I was used to at Google. So it was an extremely educational experience for me. It was really valuable to see that you didn't always have to ship tests and experiments and lots and millions of little iterations to get to a good product, that there was a role for intuition and customer interviews and behavioral interviews, and really appreciating the notion of having a point of view from a design perspective about how a product should work and look. I mean, I think at the end of the day, design is not how something looks or feels. Design is the abstraction of the technology to the end experience for the consumer. And that's really something that I learned when I was at Square.

Well, data certainly played a role at Square too. I don't want to make it seem like it didn't. We were very focused on analytics, and in fact, the company was famous, I think, for in some ways starting the trend of having big screens all over the office. We call them radiators of real-time performance of the company across a number of different variables. So at a macro level, we really thought and cared a lot about data. But from product development and release process, it wasn't a lot of iterative testing. It was really coming to a point of view, building something beautiful and functional, and putting that out to the consumer and getting feedback in a sort of ongoing way. I have a good example though of that tension, because you're right, there is a certain amount of tension between data and intuition. And it sounds simple, but it's something that we really wrestled with internally for a while. Square was back in the day when it first released the first product where you could sign with your finger. And we don't think much of that today because we probably all do it multiple times a day, but at the time it was kind of fun. It was this experience that people remembered. And you don't typically remember your transaction experience standing at a point of sale and running a credit card. You remember what it is that you purchased. But when people paid with Square, they would take pictures of themselves signing with their finger and they would post their signatures to Twitter and Facebook and talk about how cool it was to be able to do that, because it felt like they were really engaging and touching with the product in a way, and it was just fun. It was really kind of one of these delightful moments in an otherwise fairly boring process. But around the time that we released Square, both MasterCard and Visa came out with a new rule that said for transactions under $25, you no longer needed to collect a consumer signature. And a lot of the customers that we served, basically their average transaction was less than $25 because they were serving muffins or coffee or donuts or whatnot. And for our customers, those merchants, speed of processing was what was really important. And we learned that very quickly. They didn't love these amazing beautiful transitions and animations with flying stars everywhere that we thought were so cool. Our merchant customers were like snapping their fingers saying, no, I just need to get to the next customer. There's a line, I feel very high tension. Why are you showing me these beautiful stars in every transition? Just get me through this line. So we knew from a customer perspective, and that customer being the merchant, that they would appreciate the fact that their end customer didn't have to sign with their finger because it would make the whole transaction process faster and they could get on to the next customer. But at the same time, we knew that for Square and for the overall ecosystem, that moment of delight was really powerful. And it wasn't just brand building for the company; it was an association that that end customer had with the merchant that was unique and positive. And so we wrestled with: do we do away with signatures for transactions less than $25, because the data will tell you that that's faster and that our surveys of our customers will say they want faster processing? Or do we keep that element of signing with your finger because it is so delightful and unique and people clearly like sharing it and experiencing it? And so what we ended up doing is keeping it, keeping the signing with your finger. So even to this day, it's probably something that people do quite frequently now. But we did make it an option deep inside settings that if you were really motivated, you could go find and you could turn it off for transactions less than $25. But that is a bit of editorializing that frankly we did on behalf of our overall customer base that was more intuition than data focused.

Yeah, it's one of the more tactical things that I work on with the companies where I'm an investor, because I do think as potentially trivial and tactical as a product roadmap may seem, I think it's a very clarifying document for the overall organization, not just people that are in product and engineering and design, but it really defines and reinforces the priorities across a company. And I think that that's really important, especially in fast-growing companies. So when I work with companies on their roadmaps today, there are a few things I'm looking for. One is I want to have an understanding of priority. I'm a big believer that launches actually shouldn't be pushed, that you should not delay a release but instead drop features. And I think that that's because it's very important to have a cadence and a sense of rhythm in development, particularly in startups. There's so much uncertainty in a startup that anytime you can extract away some level of uncertainty and chaos, it's actually really beneficial to the overall health of the organization. So I'm a strong believer in sticking to launches, but understanding that that may mean that you have to take out some of the features or functionality that was originally planned to launch. So for that reason, I look for specifically priorities of each feature or function that is within a launch and expect things to be sort of P0 through P5, defining what is going to drop first so that there's no debating towards the end of the cycle of what's not going to make it and what's going to make the cut. I also look for DRIs, directly responsible individuals. I'm a believer that at the end of the day, engineering, product, and design as a collaborative group are responsible for the development and launch of any features or new products. But I think when you have a fast-growing organization, it's really helpful to identify a single person that anyone in the organization can turn to if they have a question, if they need something, if there's something that's not working the way they think it should, if they're just curious. So I always look for DRIs, or these directly responsible individuals, as it's associated with each feature function that's launching. The other thing I look for is some sense of past, present, and future in roadmaps. I think it's very easy in startups to basically ignore your tech debt. You're building so fast, there's all the things that you want to exist in the world, your customers have all of these requests, and so you can accumulate tech debt very quickly. But at the end of the day, big companies and successful products can't be built with two Popsicle sticks and gum. And so it's something that you need to continually address. And if you just say we'll get to it eventually, like a lot of things in life, you'll never get to it. So I advocate for every launch to have some element of past, present, and future. And past is some element of tech debt. Present is what you're hearing back from your customers, really specific feedback, basically a direct channel between customer support or sales and the product organization. What are your customers banging on the door demanding? And future is where you have a point of view on what needs to exist in the world, where the company is defining the future for that product or that category, where the real innovation shines. But I think it's important to have an element of all of those into every release and to have that spelled out quite clearly on a product roadmap. So those are three things that I look for. There's some other elements I like to see too, but I do think roadmaps can be a really unifying and clarifying document for large organizations.

Yeah, I think often the why is more important than the what, and it's also one of those things that bears repeating over and over and over again within a company. The why are we building this is something that you frankly can't over-communicate. And so the really tactical ways that I've seen that done effectively: one, incorporating it into the roadmap, so linking off to a write-up of some type that explains in a really thoughtful way the experience that the company is trying to enable with that release or with that product. I'm not personally a big fan of personas, i.e., Jenny is a 25-year-old designer, she lives in New York City, she spends $5 on her coffee. I think that you can get down a little bit of a rabbit hole that's unnecessary. But I do like documents that explain what a moment in time or a situation looks like when that feature or that product is in the world. And sometimes that looks more like a business case study, which is the very Bezos Amazon way. Of course, they write out long memos about what they're building and why. And sometimes frankly that can look more like fiction, it can look more like a narrative of an experience or an exchange. But I find that by having that down in some written form, it enables anyone in the company to access that vision and understand the why directly from the roadmap, from the tactical launch schedule. The other thing that I'm a big believer in is having regular company all-hands meetings, weekly ideally, but otherwise at other intervals. And I think that those are really great times to both reinforce what the company is building and why, and to highlight people in the organization that are making that happen. So not necessarily the VPs and the leaders, but who are the people really building and working on the designs, or who are the first at the front of customer service, the first line of defense in some ways. Having them get up and talk about their experience with what they're building, I think can be super powerful. And especially if you can do that while showing work or showing data. Some of the most effective why conversations that we had at Square, for example, came from having people in customer support get up and talk about interactions that they had with customers. They would talk to taxi drivers all day long who really depended upon tipping. I mean, it's hard to believe this, but Square didn't have tipping for the first two and a half years of its life. And when you understand that this is how people really make ends meet and that this is a real source of income for a lot of people, it makes that feature addition that maybe doesn't feel like, oh, that's not innovative, adding tipping, who wants to work on tipping? It makes it really impactful, makes it really tangible. So I completely agree that the why is extremely important and something that frankly can't be communicated too much.

That's a great question. There's two companies that immediately pop to mind. One is Pendo, which is a product experience platform focused on enterprise companies and B2B companies. So they help companies who have been around for a while, had products in market for a while, I don't want to name names, but like traditional B2B enterprise types, build better products by helping them understand their user behavior on the website and then helping them guide users through tutorials and polling and a lot of consumer-like experiences that we now expect in consumer products but for whatever reason haven't made their way over to enterprise products. And the founder there, Todd Olson, was previously a VP of product before becoming an entrepreneur himself, and he has been really effective at communicating the customer journey and the customer need to the organization so that every time that they launch a feature, there's a real understanding, not of case studies in the dry sense, but of customer stories that help bring to life the features and experiences that they're trying to build, connected with the end results. So they're able to say, you know, our customers, if they do X, Y, and Z, see an improvement like a 25-point improvement in NPS. That's really powerful. I mean, that NPS to the extent that you believe in it or not is debatable, but there's no doubt that if people are voluntarily saying yes, I'm more likely to recommend this product, that there have been product improvements. So he's particularly good at it. I also think Slack is another example of a company that effectively communicates internally the why, although it's one that frankly is more sales-driven in a lot of ways. So Slack started off as small teams of individuals sort of joining, getting other people that they worked with on board, and then over time organizations realized they had all these people on Slack and ended up doing larger deals. But the company has graduated to a place where really large Fortune 100 companies want to roll out Slack to thousands and thousands of employees all at once. And the stories around how people were band-aiding the product to be able to support thousands and thousands of people, when I think really Slack at its core in the early days was good for maybe a hundred people, brought to life the need to build out a real enterprise offering. And we don't pay as much attention often to enterprise products and services, but I think what's amazing about both Pendo and Slack and frankly Envision is that they are bringing delightful experiences to the enterprise. And Slack's way of doing that was really frankly being forced through some amount of embarrassment and friction with their customers who were trying to shoehorn their own needs into a product that wasn't ready for them.

Definitely. We're seeing the emergence of a chief design officer or a creative lead or someone around the executive table who represents the design organization's point of view. And I think that that's really powerful because that's not something that's been typical in quote-unquote tech companies in the past, and it's something I think is really important for building great products. So even just having a seat at the table, I think, is a huge step forward for the design community at large. So that's a trend that we're seeing and that we encourage. The second is frankly just the hiring of more designers, which sounds pretty tactical, but I do believe that there is a magical ratio of designers to product people to engineers. I'm not sort of religious about what that ratio is because I think it depends often on what the company stage the company is at and what the product is. I think it can usually look like one to eight to nine, something like that, in terms of engineering to design, but that's not always the case. But having an understanding that it can't just be, oh, we need to hire more engineers, we just need more engineers, we need more warm bodies that can code, but actually we need more builders. And the notion of builders being engineers, product people, and designers, and that frankly you can't over-hire on any one of those and under-hire on the rest and expect a really functional building machine, I think is an important realization within the companies that are growing very fast that I work with.

I typically see companies bring a design leader, and I mean by leader of the exact team level, a little bit later in the company development timeline than say a head of product or head of engineering. But I think that people increasingly recognize that it's not enough to have a product that's functional. That product experience really, really matters. And product experience isn't just, does it work and does it work as a user expects, but is it delightful? Consumer expectations of the products that they use, frankly both at work and home, have never been higher. And the iteration and development around new products, I think, is only pushing the bar for everybody, so that expectations continue to go up about those services that we use on a regular basis. And so I think that that's where this drive for more design leadership, a louder design voice, comes into play with the companies that we're seeing that are on a fast development cycle.

So the first quality that we uniformly look for in founders at Spark is a deep sense of ethics. We have to be able to trust that the individual is a good person with good intentions. And that seems really obvious, but at the end of the day, a lot of people build companies and not always for the right reasons. And so the first thing that we have to both see and feel, frankly, and it can be a little bit qualitative, is do we trust this person? The second piece, which is sort of more unique to my point of view but something that I look for, is a deep sense of personal awareness. And I say that because you have to be a little bit crazy, I think, to start a company, to found a company. You're kind of going against all odds. It shouldn't work. It's very hard. It's going to consume a large amount of your life. So I do think you have to be a little bit crazy. But I think that the very best entrepreneurs are both crazy and self-aware, in so much as that they know what they know, they know what they're good at, but they also know where they need to surround themselves with people who are better than them or who are more knowledgeable than them, people that they can learn from, and know when to seek help and expertise outside of the company. And I think that's really, really important. That kind of growth mindset is how people often refer to it, but I think that that's really important for long-term successful companies. We of course look for entrepreneurs who have a vision of the future that they absolutely believe must exist, that they have no qualms that this is the world that needs to be there and it's going to be this way come hell or high water, and that they were born to build it. That kind of tenacity, I think, is really required in building a company for the long term. We like founders who are very product-oriented. That's one of the unique things to Spark. We would say that the companies we invest in tend to have more product-focused CEOs or founders. We think that at the end of the day, the head of product at a company is the founder. And of course, we like there to be a big business as well. We want to see a business model in a large market, though understanding that can take a bit more time.

I have strong views. I believe that all pieces of the building process, and when I talk about building process and the building engine, I'm really talking about product, engineering, and design, that trio, that triumvirate. I really strongly believe that all three disciplines need to have a deep understanding of the other disciplines that they're working with, not just strong empathy but real practical understanding. The tip that I would give my PMs at Square, for example, was: you know, we had this weekly product review session, and the product lead and the design lead and the technical lead for every product would come in and update the executive team on their progress, and there would be discussion topics and so on and so forth. But I always said that we should be able to pull any one of you aside and that you would be fluent in the challenges and opportunities for each of the other functions, because you're spending so much time together, you're working on these problems very collaboratively, that you should basically speak the same language of the challenges that you're focusing on across those three different disciplines. So I think it's really important. I think the strongest designers that I've worked with not only have a deep sense of the business need, which is to say they don't design for design's sake, they design for purpose, they design with an end goal in mind, but also a deep understanding of the engineering requirements of the work that they're doing, which is to say that they've been curious enough and confident enough frankly in their own abilities to work really closely with engineering to understand what's possible and the timeline in which things are possible, versus designing in the abstract. I think that that's really, really important. And the same goes frankly for engineering. I mean, the strongest engineers that I've worked with had a real deep appreciation for the discipline of design and the needs of design, particularly at the beginning of a process.

I think thinking of, again not to harp on the Square experience, but I think really thinking about these functions as a triumvirate that's building the best product engine. And when I talk about product engine, it's really about how do we build a product that's wonderful, beautiful, proficient, but is efficient in the process, that we are not waiting on different functions, that people don't feel like they're being steamrolled, that we're utilizing our resources effectively. Like, how do we turn the product development process into an efficient engine? And I think that requires all three disciplines working really closely hand in hand. And I think when those three disciplines see it as a 'we're all in this together, we being this product group' versus 'we this discipline,' I think that's a really important change in how each of those individuals think about building that engine. So it's not designers versus engineers versus PMs, but it's these three functions working together on this product in the trenches together, building an engine across the three disciplines. That I think is a small but important change in how we even talk about development within an organization.

Yeah, the primary challenge is always around communication. I have a basic rule of thumb that every time you add 30 people to an organization, everything breaks in terms of your communication strategies. So first 30 people, everyone can basically yell across the room. You know each other's names. You know what everyone's working on. Next 30 people, you still know each other's names, you still know who to go to at any point in time when you want to ask a question or talk about something. But with every 30 people, though, you abstract away one more layer of communication just by the nature of getting larger. So the advice that I give to the companies that I work with is to instill processes around communication earlier than feels necessary. Make it so that it almost feels like it's too much process and too much structure for where the company is at, because if you're growing and doing well, it's going to be just the right amount of process and communication by the time you get any good at it. And then frankly, you're going to have to start all over and build new processes and communication channels. But I think that that's something that's really, really important. Humans don't like uncertainty. We behave really poorly in uncertain environments. It's human nature. It's not because we're bad people. It's just that we are actually mammals who enjoy repetitive, predictable interactions. But everything about a startup is uncertain. And so anytime you can minimize that uncertainty, that you can make something predictable, consistent, you have a metronome around how you build, how you communicate, how you operate, I think that's really, really valuable for a company, particularly a fast-growing company. And frankly, when people tell me, 'Oh, I don't want a lot of process, I don't want a lot of structure, this is a startup, that's why I'm not at Google,' frankly, a lack of structure and process is a process unto itself. It's just a broken one. So that's one of the things that I really work with closely on the companies where I've invested.

That's a great question. I read voraciously. I read both fiction and non-fiction. I consume content all day long. But the internet's a wide place, and it's helpful to traverse it with friends. So I'm a big believer in having email reading lists. I have three. One is with my colleagues at work, which largely, as you would expect, pertains to things in the technology industry, whether it's portfolio companies or not or other investors and so on. I have one with friends, it's just around interesting stories that are floating around the internet in the ether. And then I have one with my husband, which is very tailored to our personal interests in things like movies and wine. But I'm a big believer in having content streams that are curated by people that you're associated with, not necessarily people who have the exact same interest as you, but people that you're associated with in some way, because there's just so much content out there. At the same time, I read a lot of books, but as I mentioned, I read a lot of fiction and non-fiction. I like them equally. I read a fair amount of sci-fi, which is not unusual in Silicon Valley, but has an uncanny way of predicting some future products that I think we'll see in the world in 10 or 20 years. I do listen to a lot of podcasts. So basically, whenever I am not speaking to someone, I have my earpods in, which people make fun of me for. But I listen to a number of podcasts, but frankly, I try not to listen to technology podcasts. I really listen to podcasts that expand my aperture in other ways, whether it's around a lot of design, a lot of business ones, economic podcasts randomly. There's a whole number of true crime podcasts that I'm a fan of now. I'm just embarrassing myself. But I am constantly dipping into various forms of content. There's no single book or blog or podcast that I could point to, but I think at its essence, being curious means you're sort of all over the place in terms of the things that you look at and engage in. To some extent, it's knowing a little about a lot, which is one of the perks of my job.

The primary hack is actually based on the reciprocity that's required for these various content streams that I belong to with my colleagues, my friends, and then my husband. Which is to say that when I do read something, whether it's on the internet or a book or not, and I make a recommendation about it, I really try and synthesize about why I think it's worth someone else's time. And just doing that quick summary of takeaways or insights or just a rationale for engaging in it is a way for me to develop recall over the things that I thought were interesting, whether I knew it at the time from that book or blog or whatever the case may be. The other thing that I do is frankly I wake up very early. So I wake up around 4 in the morning and really use the time between 4 and 6 selfishly to do whatever it is I want, which ends up looking like trolling around the internet reading things. And I guard that time really fiercely, because I think it's hard for me in the midst of a day or even frankly at the end of a long day to be able to disassociate enough from the day-to-day requirements of my work and the things that I'm thinking about in the context of work to be able to engage on different subject matter. And so that's why usually during the day it's a lot of podcasting, which is a much more passive learning experience. But on the reading side, it's much more focused in the early morning.

No, they're not. But my husband sometimes wants to talk to me, and I have to remind him that that's my time.

Thank you so much, guys. I really enjoyed it.