 I'm Irene. And to get us started beyond the little introduction that you just heard, I think it would make sense to back up and hear from each of us how we arrived in our positions of designer and product manager. So Irene, why don't you go first and introduce yourself with a little bit of emphasis on how you ended up as a designer. Okay, so I studied electrical and computer engineering in school and then I went on to graduate school originally with the idea that I would become a computer engineer and get a PhD and design computer chips. And while I was there, I pivoted and moved into the field of human computer interaction. This was during a time before you could really study HCI. So the focus of study was on human factors and engineering psychology. So really it was like studying human perception and cognition to design experiences better for people. So like how do you design airplane cockpits so that people don't accidentally crash the plane? We were taking these methods and practices towards the design of software and that was the start of my career. I began my career at Netscape Communications as an interaction designer and then moved to Yahoo in 1998 and started Yahoo's Human Center Design Practice and ran that for eight years before I joined Google in 2006 and ran design for all of Google for about six or seven years. After Google, I went to Udacity for a couple of years. I joined when we were about 20 people and just had raised our series B and helped Udacity develop their product strategy and their business strategy, raise their series C before then I left and then I left to join Coastal Adventures as a design partner. So that's where I've been for the last four years or so working with our CEOs to help them be successful. So I think I have a similar story in that I didn't study product management in university because there was no discipline called product management, at least not for internet products when I went to school. So as an undergraduate, I studied computer science and then as a graduate student, I studied computer vision, sub branch of artificial intelligence which is really around machine perception. I got my masters and then dropped out of school to found a company and this was so important in my own development, being a company founder taught me a lot and part of it is as we heard this morning in the official slush launch, you have to do every job. So I was formerly the CTO, Chief Technology Officer of the company but when you're four people, everyone has to do everything and I think of these as really important years that informed a lot of the rest of my career and that journey for me from founding the company with three friends to exit was about eight years. So this was not a rocket ship, this was more of a slow burn but we eventually did take the company public and exit the company and then I got my first job as a product manager and it was relatively late in my career, looking back when I joined Yahoo in 2004, I was already 39 years old before I took a job in product management. So I went from being a CTO to a product manager and I did that for four years at Yahoo and then joined Google in 2008. So I've been at Google a little over 10 years and run some of our biggest consumer facing products including Gmail, Google Docs, Google Drive, Google News, Google Photos, as well as many others and I do that to this day. One thing that Irene and I both do sort of as a sideline is angel investing and so that's another way that we get to stay involved with the startup community and mentor. So I wanna ask you first about Google Photos. You were responsible for Google Photos and this is one of the most successful products in internet history. I mean it's fastest growing product I think from a user perspective, right? So tell the story of Google Photos, like how was it conceived? How did you guys create it? So I think responsible for is a good way to frame it. I was the executive under whom Google Photos was created and at the level of interaction that I have with a product as an executive, a lot of what I'm doing is curating the team that makes the product and I think that's a lot of the skill that a product manager needs is not only to have great product vision but also to install leadership along all dimensions of what it takes to build a product who can sort of carry that vision forward. For me, I almost think of this as the third act in terms of bringing AI to the photos problem. So the first act was my own startup which is dating back two decades ago. The second act was Flickr. So while I was at Yahoo, one of the companies we acquired was Flickr, the photo sharing site and all this time we were sort of waiting for computer vision to catch up with its promise and for many, many years, computer vision was very, very modest in terms of its incremental progress. Every year it would get like 2% better but around four or five years ago something amazing started happening and I think it was the consequence of a number of factors that converged. One is new techniques in artificial intelligence, deep learning, neural nets that started to be applied to the problem in new ways. The other was the amount of data that we had that was actually informing the problem was significantly and dramatically more than had ever been approached before. And so four or five years ago things that we thought we could never do like show me all the pictures with dogs in them or show me all the pictures with churches in them suddenly and magically started to work. And so we knew that we sort of had this amazing opportunity to take that technology and solve a problem with it. What we did need to do is ask what problem are we trying to solve? And with Google Photos we backed all the way up and thought for a moment about what could we really do for users? And this was at a time when suddenly people were taking more and more photos. I think the sensors on cameras just kept getting bigger and bigger. It became a differentiator. So if you had four megapixel next season it was six megapixel. So photos just getting bigger and bigger as well as people's ability to take photos. So you would sort of go on a vacation and you would come home and you have 2,000 photos. You almost need a second vacation to curate the photos from your first vacation. And the problem was of course nobody gets that second vacation. So photos tended to sort of sit on drives or sit on your phone and just sort of rot there. So these were the problems we were trying to solve and we were really inspired by the metaphor of Gmail. Like Gmail changed the way that you process email and I don't know if any of you are old enough to remember this but back in the days of Outlook you would tediously curate your email until at the end of the day you had a zero inbox. Everything was folded away and you could sort of close your laptop and go home. As more and more email started flowing in that became impossible. The premise of zero inbox just doesn't work. And what Gmail does is let you breathe again and sort of instead of manually curating all of my email you just sort of trust that we've got your back and that you'll use search and priority inbox and all the techniques that we provide to get through that email. If it's really important it will find you again. So we wanted to do the same thing with photos so that I could take photos and not feel I was building up a workflow that I had to address just by taking those photos that we would do magical things for you. Like find the best photos, help you find those photos when you need them, help share them with exactly the right people and that was the premise of the product. So I think it was an opportunity to take a new and differentiated technology and unmet need in the consumer space that sort of looked at all the trends about more photos, bigger photos, more content, more data and build a product that really landed and resonated with users. And so it was the sort of cherry on top, the third time's a charm for me as I sort of built a product to address that photo need but this time really got the product to scale. So it was a great experience. I've got a question for you, something I know you think about a lot in your work with COSLA. What are some dos and don'ts for people thinking about bringing a design practice into their startup mostly focused on startups because I know there's a lot of startups here. What are common mistakes and ways to sort of get around those mistakes? Yeah, one of the most under-invested activities that I see startups fail to engage in is user research. There are a lot of misconceptions about what user research is and what it can do for a company. Some common misconceptions are like we don't have enough time or energy or resources to go out and talk to users. Or this idea that talking to users is about asking people what they want and there's the whole Henry Ford adage, like if I've asked people what they wanted they would have said a faster horse. But actually user research is like rocket fuel that can get you to the right answer faster and it helps cultivate a deeper understanding for what people's needs and their pain points are. A lot of times what's obvious to the development and the design team is not necessarily obvious to users and I've literally watched people using products where they just would go through this lengthy process of building up to a point of buying a product and then actually not buying the product because the button that they were expecting to find was not in the right place and they would just lose trust in the site completely and abandon. So there are little things that the development team often takes for granted that you can uncover through user research. There's formative user research and then there's more summative user research. So formative user research is kind of like need finding, watching people in their home or their work environment or in the context of use. Summative user research might be like when you actually have a prototype or working product and you take that out and watch people use the product. So I would say do definitely do user research. You get the biggest bang for the buck. You get to the right answer faster. One of the pitfalls that I see, another pitfall that I see startups often make is that they dive into high-fidelity mockups too soon and I've worked with executives who kind of push their designers to generate high-fidelity mockups rather than working in paper and pen sketches or wireframes because they feel like they can't imagine what the experience will be unless it's in high-fidelity. But what happens is that when a mockup is in high-fidelity, it causes the team to focus on the wrong issues at the wrong time. So when there are larger, more strategic issues around like what's the point of view of this user experience? What should be the focus? In high-fidelity, people tend to focus on, well, I don't like the way that icon looks or things like that. So my best advice is to use the lowest level of fidelity to prototype your experiences to make the right level of decisions at the right time and then gradually work your way to higher and higher fidelity. The third common mistake that I often see startups make is that there's a failure to go back and iterate. So there's this idea like we build something, we launch it and then we move on to the next feature and then we launch that and the next feature and then we launch that. And there isn't like a discipline of going back and assessing did what we've launched work well or not well for people and how can we improve it and perfect that before we move on to the next feature? And of course there's always a fine balance because you don't wanna be polishing a diamond when there's a long list of features that also need to be developed but there needs to be sort of a commitment to going back and improving, especially in software where it seems like every launch is effectively a prototype. So I'd say do use your research prototype at the lowest fidelity you needed to make the right decisions at the right time and then also commit to going back and iterating. So I wanna ask you about product excellence because I've been working with a startup that is trying to turn the company culture, they've grabbed the marketplace, they're really successful, they've scaled but now they're finding that their product is sort of has so many, it's like death by 1,000 cuts. There are all these little details in the user experience that have fallen through the cracks or even just less than pixel perfect alignment issues and things like that. And so they're wondering how to kind of emulate a product excellence initiative in the way that Google did and I'm curious to hear you talk a little bit more about that. I think it's a great question and a hard one to answer in the abstract. To do anything like Google does is tough to be prescriptive about because Google circumstances are pretty unique in the industry. I will say that the first thing I like to do is demystify product excellence because I think a lot of product suckiness comes from people making compromises along the way and sort of putting things in a parking lot and saying we'll get to that later. And these compromises are death by 1,000 paper cuts and a lot of times the people in the organization, the engineers, product managers, designers that are building things are too aware of the constraints of their daily life like whether that's a technical limitation and organizational limitation, et cetera. There's all these reasons that we don't do the right things for users and they're good reasons sometimes meaning that they're real, they're not sort of fabricated but in the end they sort of create this product suckiness which is sort of accumulating over time. So I think the first thing you have to do is dispel the myth that it takes a turtle neck wearing product genius to sort of come in. A lot of this stuff is self-evident and with dialogues with users, talking to your customer support people, just opening your eyes and using the product yourself, you can uncover all of these compromises that you've made along the way. The question is when and how do you deal with those? And so there are different techniques for that. One of them is to have a fix-it sprint which is to really make it a company priority to address these things and celebrate that and sort of say we're gonna do a launch which isn't about new features or sort of V2.0 or V3.0, this is a fix or a launch which is specifically designed to eat through that backlog of compromises and bring the product quality up. And to do that you really need the support of leadership whether that's your CEO in a small company or your vice president in a bigger company because it feels like you're moving sideways but of course you're really vaulting the product forward but it's not the kind of things you put on bullets on outside of the box. You can't say now actually works or sucks less. These are things that are hard to market but really, really important to do and you need that sort of top-down support. What kind of advice would you give to companies that are more date-driven and what kind of role do product reviews and launch checklists and things like that come into play for that? Yeah, I think the other thing that you're partly referring to is process. A lot of being excellent in your product is about the process that you build in in terms of dog-fooding, QA, and making sure that you meet a minimum bar of acceptable progress. And there's obviously a trade-off between date and quality and that has to be managed to the constraints of your particular company. Companies may not have the luxury of 18 months of runway to get it exactly right. Part of my philosophy there is it's generally better to do fewer things well than have a bunch of half-baked features that you're sort of foisting on users. So if you do have to make trade-offs, which you will at a startup, I would say do fewer things well and get to the other things later and do those well too as opposed to putting fewer or more half-baked features to market, which is something you'll end up regretting. There's also this notion of having a high bar for excellence that you kind of set as an expectation for the whole team. I think one of the challenges that I see is that across a team, you can have a lot of different levels of what's acceptable. And so what might be acceptable to one person may not be acceptable to another person for launch. And so as an executive, whereas the product lead, you sort of have to calibrate everyone around is this launch worthy or not? Right. Yeah. I think that that tone is set from the top and you get what you incentivize. So when people do these fix-it sprints and things, it has to be celebrated within the company. It has to be rewarded. It has to be part of the company culture that you're going to celebrate fixing something as well as launching something. Because if the company just gets too launch-focused, it becomes a perverse incentive and you just get sort of feature creep and it's very hard to dig out of that kind of debt. So I completely agree that this has to be modeled and a lot of times it's about leadership getting up and talking about the progress you made that may never really be seen or appreciated outside of the small cohort of people that know that this was sort of a looming bug inside the system. I think a key to design success and product success is that there's like a standard of taste that everybody shares. And I think it raises an interesting question around whether taste can be taught. So like when Steve Jobs hired Frog Design, Design Agency to design their first computer, Frog sort of famously sent, started educating him around design. And when Larry became CEO prior to that, he spent a lot of time with Steve Jobs learning about design as well and developing a language for that. So it kind of supports this notion that you need somebody at the very top kind of calibrating that taste or delegating that to someone who is the arbiter of taste and whether something is good enough to launch. And one thing that I've seen that's interesting is how some companies have tried to cultivate a culture around design and taste by educating the entire company around this. So like one of the portfolio companies that I work with called Nutanix, the CEO, Dheeraj Pandey, decided a few years ago that design was really critical to the company's success. And so he started to pivot the company culture in that direction by engaging the entire company in a conversation around what constitutes good design or bad design and where in the Nutanix experience do people perceive that there's product excellence or where were they falling short? And all of that was with the intention of helping to build the muscles within the company to identify and critique their own work so that they could call each other out on it and then make improvements where necessary. So it's an interesting question, can taste be taught? And I think the answer is yes. It has to be supported from the very top and it requires a couple of things. One, it ultimately comes down to observation. One is observing your users and over time if you watch people enough times and over an arc of an extended period of time, you start to understand what works well for people and what doesn't. Where do they expect things to happen and where do you fall short of meeting their expectations? And then the second is really in observing yourself. So if you're the user of the product, so I think this comes into play a little bit more for consumer products, is to start to build the muscles within yourself to see where do I feel cognitive load or stress or unhappiness when I'm using a product and why and how could this experience be better? And so you can actually build those muscles within yourself to elevate your standard of taste and design. You know, we've only been in Finland 24 hours, but it's interesting thinking about the cultural value of design here. Like if you look at the airport, it's absolutely gorgeous, modern. You know, you could spend time in that airport. Even the plane we flew over or Finair was like one of the best designed planes I've ever been in and I'm just wondering what the effect of coming from that culture does to people in terms of their value of design and being surrounded by thoughtful design everywhere. It did occur to me that Fin's flying to JFK must think were absolute barbarians when they land in the chaos of that airport. But... No comment. Yeah. Another thing that I think we both deal with in design and product is around metrics and sort of using metrics. And you know, especially as related to things like growth as the previous speaker spoke about, it's an interesting relationship that I think a product manager has toward metrics. They are the lifeblood of running a product and I think that every product manager should be absolutely glued to the metrics of her or his product. But I also think they provide sort of constraints around local maxima, that there are things to be gleaned and learned, but they can only take you so far and that there are discontinuities and great leaps that require other methodologies beyond just sort of optimizing to drive metrics forward. Yeah. Well, famously, AB tested every aspect of the search interface because for one thing, it was easy to AB test that. It's just a single page interface. It's also a very fragile interface. Just slight changes at the pixel level to the search results UI can result in dramatic changes in user happiness. But all that AB testing really did result in a local maximum and to create material which is like Google's new look and feel, we had to bust out of that and that was a huge cultural shift for the whole company to get to that and that was inherently qualitative. There was nothing AB tested about that at all. Yeah. Well, there's a lot more we wanna cover and maybe we'll get a chance to do that in the Q&A after this session. I think we're in about 20 minutes headed over there. But in terms of the last few seconds we have, are there any sort of parting thoughts or advice you would wanna give startups as they're setting up a design culture or design practice? You know, I think it comes down to a really great partnership between product and design. Good design has to come from the very top. If the CEO doesn't really care about it, then it's not gonna happen because somebody has to give air cover to the team to create the time and the space for thoughtful design to take place, to give enough time for understanding people, their users, generating a lot of different ideas, prototyping them, evaluating them, going back and iterating. All of that takes time and commitment that really doesn't happen magically unless the CEO asks for it. In the same way that the CEO has to wear many hats and be well-versed in the technical possibilities and constraints or the market opportunity and the market dynamics, CEOs also need to understand product and design. And I think the most successful collaborations are ones where that definitely takes place. Yeah, I'll just add that I've heard people talk about product manager as CEO of the product. And I find that really off-putting. And the way I think about it is more in a musical setting like the product manager's job is to help make great music. And sometimes that means acting as a conductor. Sometimes it means jumping in and grabbing an instrument and playing along. Sometimes it means tuning the instruments for folks and being much more in dialogue with the other team members and much less prescriptive than I would imagine the model of product manager as CEO is. So that's sort of my parting words is to get people who are interested in that service mentality such that we collectively can make something great together. But we'll continue this conversation in the studio next door and thank you for your attention and time in listening to us. We'll see you there. Thank you.