You graduated from like UC Berkeley, with a CS degree. Tell me a bit about yourself and how you got into computers.
Yeah, I grew up as one of those kids who did everything. School and getting good grades was kind of expected, Indian family and all that stuff. But my parents really fostered in us the importance of doing stuff outside of school. So a big part of my life was learning and performing classical Indian dance and classical Indian music and all sorts of artistic endeavors like that. When it was time for college, I landed at U.C. Berkeley, unsure of what exactly I wanted to study, but I knew it would be in the sciences. I wasn't yet sure if it would be physical sciences or life sciences. So I started off as a physics major. I found physics very interesting from the problem solving perspective, but so mind-blowing from all these other perspectives, like how systems intrinsically worked. I really enjoyed it, but then I had this critical moment where I was like, "Well what am I going to do with a physics degree?,” because I knew I didn’t want to stay in academia. I remember my adviser at the time saying, "Well, no one will think you're a dummy if you have a physics degree, so that will actually open a lot of doors." That conversation really sticks out in my mind, the succinct honesty of it. It was like, “Okay, that's reassuring, I'll figure it out.”
I know that like Peter Thiel is physics major too.
Sometimes if you're working on something like an algorithm or trying to design something and you look up like, "Whoa, nine hours passed!" And you can like feel your brain wrap around the problem. I love that feeling.
Yeah, absolutely. Some of my best techie friends don't have computer science degrees but have degrees in physics, philosophy, history, english. It's great how many people in this industry didn't study what you would think they would have or even have a university degree at all!
Anyways, my sister had graduated from Berkeley with a computer science degree and she was like, "Why don't you just take one computer science class?" I kind of resisted because she had done that and there's something about doing what your family tells you to do that is hard. (I'm not a rebel, but I am rebellious). Anyways, I ended up taking a programming class during a summer session, one of the intro computer science classes at Berkeley, and I loved it because it was nothing like what I was expecting. It was essentially just problem solving. I remember thinking the class was very fun and that it didn't feel like work. I would finish my homework assignment and be energized by the time I spent solving it, not drained by it. I found it really cool how sometimes you would be working on something like designing an algorithm and you would look up and realize, "Whoa, nine hours passed!" I like how in programming you can feel your brain physically wrap around the problem in order to solve it - I live for that feeling. So I ended up switching majors late in my career at Berkeley from Physics to Computer Science, it was the right decision for me. That switch meant it took me four and a half years to graduate, well worth the extra time in my opinion.
What year did graduate in?
I graduated in December of 2002. The bubble had just burst, so it was a weird time in tech. I graduated with a Computer Science degree from Berkeley which would normally open a lot of doors. However, at this special time, there were similarly-educated Computer Science Masters degrees and PhD's competing in this recently-burst bubble in Silicon Valley. So I'm applying for entry level programming jobs and competing with people who had much higher degrees than me and who were much more accomplished in terms of research projects and the like. So that was really tricky and scary. One of the most blessed moments of my life, sort of like kismet, was how I ended up getting my first job. It was with Macromedia, the company behind Flash and Dreamweaver and Director. Macromedia was hiring and I really hit it off with the hiring manager for a position they couldn't even tell me about because it was for a new product, very secretive. I didn't know much about Macromedia or Flash at the time, actually nothing at all. I kind of fell backwards into the opportunity but it ended up being this perfect moment and accepting that job put me on such a great path in my career. So I joined Macromedia right after college.
What were you doing there?
Ha, well, I joined as a QA Engineer, even though I had a Computer Science degree from UC Berkeley, because it was that competitive of a job scene. I joined the tiny team that was coming together to create a product called Flex. Have you ever heard of it?
How many people can work on a 1.0 of a product that literally challenged a lot of the tech industry?
Let me take you on a little historical journey if you don't mind. When I joined Macromedia, this was the pre-1.0 of a product called Flex, which was a framework to build rich internet applications. Basically, a simple, declarable framework that let you build client-heavy applications. At this time there was kind of a groundswell of people caring about design and building apps that didn't always have to hit the server. Instead developers were adopting patterns where you could store more data on the client and do quick client-side computations to create beautiful visualizations and layouts. Flex really capitalized on that. Flex is not a technology that's used a lot now, but Flash and Flex really seeded the ecosystem that went on to produce Silverlight, AJAX and influence the web technologies stack and lots of HTML5 application frameworks. The tooling for Flex also inspired innovations in the application tooling space, spurring Microsoft to create Blend and Expression and such. Flex's heyday has definitely passed but its relevance in the history of client-side technologies is significant. It's funny, I did some work with the W3C on web platform API's a good 8 years after my time on Flex and Flash and it was amazing how some of those APIs perfectly match the Flash APIs.
Anyways, I joined as a QA member on Flex. It was very early on, the vision for the 1.0 release was just coming together, and joining at that time was the best thing for me. How many people can work on a 1.0 of a product that literally challenged the entire application-development industry? It was an amazing experience, one that I am very grateful for. I worked with engineers who were double my age, had more experience then I even have now, 12 years into my career, and incredibly smart. These were the men and women who built Dreamweaver and Director and Flash, Macromedia's flagship products. It was just such a safe, fun, creative, and smart environment to start my career in. That team challenged me like nobody's business - to be a better engineer and leader. Flex was a public-facing API, that eventually went on to be open-source with version 3, and I learned so much about how to build a clear, intuitive framework with tooling behind it that developers could use in an easy and backwards-compatible way. It was one of the best crash courses in building usable software that can be used by both a hobbyist programmer and a hardcore engineer.
What were some of the product lessons that you learned then that you have taken with you throughout your career?
I started off in QA and very quickly moved on to become one of the lead Computer Scientists on the Flex team. I was an engineer on the Flex team for many years before I ever did any “product” work. In hindsight I realize I was making many product decisions, but not knowing that was what that was called. It was during this time that I learned a lot about what is really the responsibility of the engineer versus the product owner. That division of responsibility became really clear, especially when I went from being one of the lead engineers on Flex to being the Product Manager for Flex.
What is the difference in responsibility?
I think the product owner is really… “What are we building?,” “Why are we building it?,” and “What is success when you launch it?”
I think the product owner is really asking questions like… “What are we building?,” “Why are we building it?,” "What are it's goals and non-goals?" and “What is success when we launch it?” And the engineering team is partnering with the product owner to make sure that what is being built is built in a modular, secure, scalable fashion so it can evolve easily and grow to possibly satisfy use cases that you may not even be able to imagine yet. Like take Flex for example, it started off as a framework for building desktop applications. Then the mobile explosion happened and we started realizing that the same components and animations and layouts were applicable when building mobile applications and so we had to make big and small changes to grow Flex to support mobile application development. That was a super fun time to be the Flex product owner - man, I'm getting nostalgic thinking about it now.
Anyways, when I first became the product manager, I would sometimes get caught up in the implementation details because that was the area I was most comfortable in having just switched roles from being an engineer. Then I started learning, “Oh, I don't need to care about that. My incredibly smart engineering team is going to figure out how to build that and I should trust them to do so.” Instead, my product role was to be setting clear requirements, identifying use cases from the end-user's perspective, backing up those requirements and use-cases with data and competitive analysis and translating all of this in a clear and understandable fashion for the engineering team to build with as little friction as possible. This division of responsibility is a real partnership, and once that is understood, you're well on your way to making magic.
Do you think that you need a design or development background to be a successful Product Manager?
Great question. So I think you should be comfortable with development practices, design practices and data practices. It is imperative that you have a hunger to learn those disciplines, really learn them. Do you need a Computer Science degree to be a great product owner? Not at all. Do you need to hungrily consume new applications and services and be aware of emerging metaphors on web and mobile and all that kind of stuff? Absolutely. And there's really no excuse not to, at least in my opinion. There are so many easy ways to learn simple programming and design best practices, even if you didn't have the chance to study it in school. Online courses like Khan Academy, BitFountain or in-person classes at General Assembly are affordable ways to learn these skills in your spare time. When I look to hire a product manager onto my team, I want someone who's not afraid of technology and has strong opinions about it. That can be someone with a Computer Science degree or a design degree, or someone who just lives, eats, and breathes digital design and development. That hunger and strong point of view is really, really important to me. It's such a bummer when I interview prospective product managers and they are lackluster in opinions. I would much rather you have a strong opinion I disagree with then no opinion at all. For example, a product owner doesn't need to be able to necessarily talk to their engineering team about the specifics of the database schema or details about the messaging queue API, but they should know what it means to be able to store data, fetch it securely, and really know the data-model clearly. Otherwise, how are they supposed to be able to grow the vision of the product from what it is now to what it can be in the future?
Going back a little bit… you were working in Macromedia and then you moved to work at Adobe, what were you --
Yeah, Macromedia got acquired by Adobe.
You got acquired, right.
When I first got the job at Macromedia, I didn't think I would be at that job for as long as I was. I was at Macromedia and Adobe for 10 years, which is crazy in this world, but it's a testament to what a great place it was to work. I got to move around and do all sorts of different things and wear all sorts of different hats. Sorry, I didn't mean to cut you off, you had a question?
I was just wondering how that transition was for you and what you were working on at Adobe?
At that time the web platform stuff was really taking off and I wanted to work on whatever was next, and big, and exciting.
I think the transition to product management happened because, even as an engineer, I was always insisting on going along on customer visits so I could hear what our customers were saying. Flex was being used by large banks, digital agencies, Disney, Viacom, etc. It was so fun for me to sit in a room and hear exactly what the customers were saying about the product - what worked, what didn't work and what they wished they wanted. I sometimes would be the only engineer in the room and I could glean a lot of insights from these conversations. The original Flex product managers were really smart, savvy people and I liked that they recognized the importance of having engineers in the room. When wearing my engineering hat, I could hear what the customer was saying and take it back to the engineering team. That interest and ability was just a natural on-ramp for me to move into product. I mean, at that time, the term "Product Management" was kind of new and I didn't even know what I was doing was product management. But around the third release of Flex our then product manager moved onto something else and our GM tapped me and said, "You have the natural skills, you should do this role."
I was really scared. Like, really really scared, because I was very comfortable on the engineering team and had a ton of respect for our then product manager. To me he seemed to make a billion decisions a day and I wasn't sure if I was capable of that. Ha, now I understand that is the most important thing to being a product manager - making tons of quick decisions, often with little data, in order to keep the team moving forward. You have to believe in your ability to course-correct if you do make the wrong decision. Anyways, I'm glad my GM pushed me to become the new product manager for Flex because it was really a great synthesis of my skills and natural talents, and I respect that he saw that in me. He's still a fantastic mentor now, 10 plus years later. It’s funny, all us Flex people still feel like family – whether they worked on the product or are part of the broader community. Anyways, being a product owner is not just about being technical, but also owning the business side of things. This includes looking at the competitive landscape and asking questions like "What's the market?", "What's the real opportunity?", "What's the growth path?". Being the product owner for a bunch of developer-oriented products at Adobe was one of the most exciting times in my career, I loved it, like a pig in mud. I think back on those experiences with such pride.
And then...well, I think we all know what ended up happening, we started seeing a change in the technology landscape. The iPhone had come out and it was capturing peoples' hearts, minds, imaginations..and building out a broad developer landscape. And, it was not running Flash. So it was an interesting time at Adobe, having really frank conversations about what was important and trying to predict the future. Adobe was always a huge leader in the creative space with the Creative Suite, so I ended up helping Adobe change its focus a bit, from such developer-oriented "enterprise-y" technologies to improvements that helped designers and developers build more beautiful, expressive things regardless of the development technology. The enthusiasm in the web platform space really captivated me so I ended up moving into the web platform side of things and helping to establish Adobe as a leader there. I helped lead the efforts for Adobe to staff up a pretty significant engineering team that was contributing to WebKit. In that capacity I got involved with the W3C and learned so much about the standards space. I had no idea how that whole body worked and it was fascinating. Web standards affects every single thing that we build, whether it's for the web or for mobile. In a way the W3C was like the United Nations for web technologies. You have all these different players: Microsoft, Apple, Google, Mozilla, Adobe, all working together in this governing body, representing their proprietary interests but also the interests of the broader development community. Watching all of these different entities, big and small, come together to build a standard and consistent platform was a fascinating thing. And to have been brought into that world was truly amazing. I got to meet such smart people, people I studied in school, like Sir Tim Berners-Lee. That was a highlight - he asked to join me in line at a buffet and we had a fun conversation while loading our plates up with veggies! Anyways, I helped build up the web platform team and Adobe went on to submit proposals like CSS regions, and shaders and that was really cool.
Now, at that time, Adobe acquired this company, TypeKit, which is an awesome company that streams web fonts through a subscription. It's probably used by many of your readers. There was a Typekit party I got invited to and that's when I met one of the founders of TypeKit, Jeff Veen. Him and I really hit it off and I summed up some boldness and just asked him if I could work for him, because I knew I would learn from him so much about not just technology and design, but leadership. Secretively, I was hoping some of his entrepreneurial spirit would rub off on me too. Jeff is and will continue to be one of my biggest product mentors. He has such a creative eye and it doesn't stop there, he's a great designer and he's development savvy. So, yeah, I met Jeff and it was the first time I ever thought so intentionally, "I want to work for you because I know I will learn so much." He had this horse-whisperer mentality about him, where he would just look at something and be like, "So, why'd you place the button there? Why not here?" And it's like, "Whoa, I never thought of that - that placement or label or roll-over color now makes so much more sense!" My career is full of these kismet moments where I just happen to be in the right place at the right time and my professional career just blossoms. I digress....Jeff joined Adobe through the Typekit acquisition and was brought in to help lead product on Creative Cloud, which was—
What year was this?
This must have been the fall of 2011 into the beginning of 2012. Up until that point Adobe was selling Creative Suite, which was a packaged bundle of Photoshop, After Effects, Dreamweaver, etc - all the products that creative love. Then Adobe had a very keen and inspired moment of business clarity, they recognized the cloud was the future and that there was a huge opportunity in selling the Creative products as a subscription product. That was the genesis of Creative Cloud and Jeff was brought in to help figure all that out from a product perspective. So again I found myself working on a totally new 1.0 product that was challenging a very established company's business model. I mean, how could I say no to that?
What was the size of the team working on Creative Cloud?
For such a huge endeavor, it was actually a really small team at the beginning. I think the product team at that time was two or three people. When I joined, I reported to Jeff and worked closely with him. They went on to hire this amazing pair of designers, Emily Chang and Max Kiesler and we formed a close-knit team to work on new parts of the product offering.
The thing I loved about the Creative Cloud product team and Jeff in particular, was how he led with vision but also delegation. I realized early on that one of the most important thing was for him and I to always be on the same page. That way he knew to give me space to just “get it done” and I could represent his vision in meetings with other teams and design reviews. He gave me a lot of responsibility and ownership, which was an awesome privilege and a scary responsibility, and I loved it. So our little were just kind of tasked with figuring out what our new Download Center looked like or the Creative Cloud learning and training offering. Granted, a lot of people had very strong opinions, but with Jeff's vision coupled with clear ownership and communication, we were able to get a lot done quickly.
This was when I started being a lot more quantitative when making product decisions, though that grew by leaps and bounds when I joined charity: water. On the Creative Cloud team we were constantly being fed numbers like "What are the top apps people are downloading?", "When someone uses service X, what is the likelihood they will go on to try Service Y", etc. Using this data, my team and I were tasked with building part of the on-boarding experience, ensuring people could find the apps and services they wanted to but also be gently introduced to other apps and services that might interest them based on how they self-identified (like a photographer, videographer, graphic designer, etc). That was a really exciting project to work on. I learned so much about the business side of selling software, especially how to build and market a subscription business with recurring revenue. I mean, you look at Adobe's stock price now versus three years ago and you can tell Creative Cloud was an incredibly smart bet for them to have made.
How much freedom were you given as a team in Adobe? Were you given a timeframe and a budget for the products you were tasked with building?
Working together was the only way we were going to get this done.
We were definitely given directives like, "At our major user conference we want to be able to announce 'this'." So moving backwards from that, you would have to come up with a shipping schedule that could support the product vision along with buffer for risk, slippage and such. Creative Cloud was this umbrella of probably like ten to fifteen services, and twenty to twenty-five different applications, each with their own massive engineering teams. Working on that was a massive organizational undertaking along with a lot of dependencies. If one team slipped, that would introduce risk for the whole product offering. Learning how to predict and then mitigate that was a very valuable skill to learn, and a necessary skill I might add.
I learned how important it was to have "product emissaries" on all the different engineering and product teams. One of my old managers used to call this your "mental rolodex" and I made sure there were a few on each of the product teams I dealt with, like Photoshop and After Effects or Behance. Working together was the only way we were going to successfully ship good Creative Cloud flows. It was clear to ship a feature, like syncing a users' application settings and preferences to the Cloud, would require teamwork, clear communication, consistent vision and lots of documentation. Caring about detail and making sure that was expressed clearly to all the different teams, through wireframes or specs or other requirements documents, was really important.
How do you deal, either at Adobe or now at charity: water, with an engineer or a designer who is slipping on a deadline?
Ah, what a fun question. I think it's the products owner's responsibility to always be crystal clear about what the MVP is. This includes being clear about what is really important, what is not important and always, always, always, why. Explaining the rational is critical, this means when you’re not in the room, people who were listening to the rational can make decisions in-line with that even though you’re not there. I mean, there's always going to be scope creep that will jeopardize shipping the MVP. It's your job as the product manager to really closely work with the engineering team to unpack, "Why is this thing that we thought should be straightforward and take this amount of time to build actually taking this much more amount of time?"
I find that about 80% of the time it's because some assumption has been put in place that can either be removed or challenged. No matter how clearly you write your stories and you discuss things in stand-up, there may be places where someone is assuming something that if you challenge it, you can win more time back, or shave down something complex that lets that feature ship on time.
It's all about constant communication, and that's where leaning on my engineering skills has helped. You need to be super clear about what the MVP is and be diligent, like a linebacker, in not letting nice-to-haves come in and throw off your ship date. Now, you always need to be thinking about what can be layered on. Like, I can't tell my CEO, "Well, that's a great idea but, uh... NO, we can't build that." Instead, I have to be like, "That's a fantastic idea, but to do that means we have to ship this piece first. You're idea is a prime feature for inclusion in the 1.5 version because we'll have laid a foundation to build that in v1." It's understanding not just what are you trying to ship in the short-term, but also the evolution of the product portfolio in the long-term. I'm constantly asking myself, for every single thing we ship, "What does v2 look like... and v3... and v4?" and ensuring I’m including in version 1 what is needed to get to that version 4 vision eventually.
You moved to New York City recently in October 2013. You just started working at charity: water. How's that been different than Adobe?
I started peeking my head out and thinking, "Okay, how can I use all the skills and talents that were naturally developed in me at Adobe and go do something else with that?"
Whew... night and day! I was at Adobe, working on Creative Cloud and I was super proud of everything we were doing. But this was also a time where I kind of knew my time at Adobe was coming to an end. I was so happy there, I could've stayed and retired from Adobe and been incredibly happy. But I knew I'd always regret not trying my hand at some place different, something smaller and scrappier. Around that time I was also becoming increasingly interested in how people were using technology in all these cool ways to improve the world and solve major global problems.
I was reading books where innovative people were using Wi-Fi to bring micropayment processing into developing countries, or using mapping technologies to better understand a particular geography in order to change how farming was done so that locals could use less water and fewer pesticides. Just cool stuff, outside the realm of Silicon Valley, where it seemed like all my conversations were like, "This is the new cloud storage API" or, "This is the new social media plugin." I mean, that is all great stuff, but at that time in my career I was really interested in how people were using advancements in digital technology in ways I hadn't even considered.
So all of these thoughts were happening at the same time. I started peeking my head out of my Adobe world and thinking, "Okay, how can I use all the skills and talents that were naturally developed in me at Adobe and go do something bigger with that?" I started looking at other companies that felt like a tech company but were using technology in more interesting ways. I was very keen on working at a company that was smaller and where the work felt purposeful and meaningful.
This was where charity: water came to mind. I had known about charity: water through friends, but I never contemplated working there. I reached out to some friends and was put in touch with Scott Harrison, the founder and CEO of charity: water. Again, this was one of those 'kismet moments' that's like the theme of my career. At that time, Scott wanted to bring in more product muscle to shift how charity: water was operating. I mean, they had accomplished an incredible amount in the eight years since they had started. They'd built an amazing brand that really capitalized on storytelling to raise money for clean water and, without them even intentionally trying, had built an educational platform to learn about the water crisis in an intimate and compelling way.
Of course the reality was that the way things were being built at charity: water wasn't necessarily producing the most reusable products that could be sold by the growth team or could be amplified to bring in more users to the site. Scott recognized that to do that, he had to bring in product people who spent their days thinking about how to architect a strategy that supported that. So, it just worked out that as I'm thinking about leaving Adobe to do something completely different, lo and behold, I meet someone who's running something completely different but who needs the exact skills and talents that I have. It was a perfect meeting.
I started talking to a few confidantes about all of this and all of them, literally all of them, were like, "What!?! Leave Adobe for a non-profit charity? Not to mention they are in New York! Do you want to leave SF and move to New York?" And you know what? Every fiber of my being was yelling "Yes!" I was born and raised in the Bay Area, went to Berkeley, and lived in San Francisco. Going to live somewhere different sounded really exciting and invigorating. Additionally, that last year at Adobe I was coming to New York a lot, and I was really loving what I was seeing. I would go to a Meetup or meet some designer friends for dinner, and I'd think that what was happening in New York right now was maybe what the generation before me experienced in Silicon Valley.
What do you think are the differences now?
Oh my gosh, it's so amazing. The New York scene is very... "bespoke" is the word I like to use. The feeling I was getting in the Bay Area was so stale, at least for me. People were producing what I call "technology for technology's sake." What I was getting more of in New York was technology intersecting with all these different disciplines: fine art, social impact, cuisine, fashion, medicine. New York was feeling a lot more interdisciplinary, and thus a lot more "bespoke."
There were so many small companies, so purposeful and thoughtful with what they were building, and I found that incredibly enticing and inspiring. I think New York has some of the most creative founders, who think beyond a possible acquisition but really spend time honing in on what their company can do to change and better lives.
I was also really enraptured with New York as a city to live in. The diversity, the density, the arts scene - I found it quenching a thirst I didn't realized I had till I came here. I especially love the density. I think people packed in like we are, of all different backgrounds and lifestyles, creates an energy that just heightens what you do with each day. I miss the laidback nature of California, but this New York energy is what I need in my life right now.
Anyways, Adobe has this sabbatical program and charity: water offered me this product job. I got a little nervous about leaving San Francisco, leaving Adobe, leaving my family and friends so I came up with this clever idea which, thankfully, both Adobe and charity: water liked. The idea was to use my six-week sabbatical from Adobe to come to New York and advise charity: water on a particular project. That way I could determine whether New York was a place I could live in and charity: water was the place I wanted to work at next.
So I ended up doing that - I call it "prototyping my life". I spent those 6 weeks testing out this transition before making this huge life change, and it was a smart decision in hindsight. It made my move to New York and charity: water one full of confidence and excitement. So I spent the summer of 2013 out here and I fell in love with New York and really fell in love with charity: water. I mean, these are some of the smartest and most creative people you will ever meet, who are doing really compelling work. It's such an awesome mission: "How do we raise money to provide clean water to the 748 million people around the world who have to walk hours every day to get dirty water?" And who are the people who are doing that work? Women and children, so they can't be in school, they can't be tending to their gardens or starting their own business, instead they spend their days trekking to gather dirty water. And I respect that Scott and charity: water believe that no one in the world should drink water like that. I wanted to be a part of that mission.
So, as Director of Product, my teams and I help identify and improve the product roadmap to make our direct donation platform, our education platform and especially our crowdfunding platform be better, stronger and more scalable.
You have a much smaller team at charity: water than you did at Adobe. What are some of the challenges of having a small team?
So I grew so much coming to charity: water, mostly because I had to fall back and do a lot of the stuff that I could lean on other people at Adobe to do.
Well, there are challenges but there are also benefits. I have never been as creative in getting stuff done as I have been since I came to charity: water. I have never had such a hustle to figure creative ways to get something done quickly or cheaply. I mean the truth is that at Adobe I had access to teams of many people who I could ask anything to, like "Hey, what are the numbers for this" or "What is the data saying about this flow?" Here at charity: water we only recently hired our data analyst, I think perhaps just 6 months ago. Up till then, it was up to me to churn the database to look at the raw stats and figure out what the narrative was. I grew so much coming to charity: water, mostly because I had to fall back and do a lot of the stuff that I could lean on other people at Adobe to do and doing that work really built confidence in my own skills and instincts. Those early months at charity: water were challenging but also empowering - there was a lot of pleasure in going "back to the basics". Large teams were looking at me to very quickly, on the spot, determine the vision, back it up with data and help course-correct the approach day in and day out. Now one of the benefits of having a much smaller team is nearly everyone is co-located, and that togetherness allows products to be shipped better and faster. You know, I can roll my chair 15 feet and talk to our product designer about why he made these choices with the UI and right then and there we can pull up the data and be like, "Okay, we see that people are dropping off at this point. How can we fix that?" At Adobe we had a much larger team with a lot more bandwidth, but we were also very spread out around the globe. A big part of shipping product there was having regular calls with team members in India, Germany, Romania, China. I have taken countless calls outside of bars on Valencia late on a Thursday night. The intimacy of just being able to whiteboard together in a room at charity: water is really beneficial. I think that ultimately makes the product better, definitely for 1.0 products. This is probably why, in my opinion, some of the coolest, most interesting products happen via a small team that is embedded together. You get a lot more done and nothing is lost in translation.
With such a small team, how do you split your team between optimizing the current product offering or adding new features?
That's a big part of my job, owning and iterating on the product roadmap. charity: water has a wealth of products right now. Seeing how they perform and how we can improve them is really important, and not just for raising more revenue but for also drawing more people to the site to learn about the water crisis and the impact they can make towards solving it. We want to be innovating and producing new products that inspire and delight our supporters, that allow them to raise more money and do it quicker, better, and easier while also ensuring the existing products are as optimized as possible. So I spend a lot of my time grooming our product roadmap, really thinking about, "Okay, what are the products we have now, and what are the most critical improvements we need to make to them and when's the right time to layer those improvements on?" So sometimes what I end up doing is using a current product offering as a way to test out a whole new idea. I call it "determining heat" - if we can test out a new idea in an existing product, we can determine whether there will be a return on investment or not, and save ourselves from building something that may not produce the results we hoped it would. It's really important to me that we are nimble in that regard.
Now that type of thinking is not just about sitting in Pivotal and writing up a story. That is the type of thinking where I just have to turn my chair away and look out the window with this glazed-over look in my eyes, like "blue-sky" type of thinking. Asking questions like "Where are we now?" and "Where do we want to go?" That's why I work a lot with our executive team and our leadership team. Scott especially has a strong vision on how charity: water raises money, through inspiring individuals and letting them know that they can do something to solve the water crisis. We have 12-year-olds who are running lemonade stands and raising a few hundred dollars on charity: water through their campaigns. That's a great way for us to raise money and that's what we want to amplify. You know, I could sprinkle 100 donate buttons throughout our entire wesbite that is not in-line with our philosophy of inspiring and educating people to act. So the question always is, "How, through the values of charity: water, do we construct, deliver and evolve our products so that all of our supporters can have a larger impact?" That's the best part of my job.
Working here is also very collaborative. So many people here have smart opinions and clever ideas, so setting up an environment where we can brainstorm together, and synthesize those ideas is really important. Sometimes the best ideas come from someone on the programs team or the finance team as like a little seedling of an idea, and I can help build that into a more powerful idea. Those are the projects I really love.
What do you think makes a great product manager? What are the skillsets and what are the things that they should focus on?
I think to be a really strong product manager, you need strong opinions that are backed through gut instinct, but also exposure to what other technologies, and products, and industries are doing, and a hunger for consuming that kind of stuff.
Great question. This kind of goes back to something I said earlier. I think to be a really strong product manager, you need strong opinions that are backed through gut instinct, but also exposure to what other technologies and industries are doing. You must have a hunger for consuming that kind of varied knowledge. And above and beyond anything, you need a strong point of view while also the soft touch of constant collaboration. When I am hiring for my team, I ask questions that help me determine whether they have a strong point of view, whether they can share that point of view and back it up and also whether they can collaborate on that point of view to build it or modify it to make it even better.
I also look for the ability to look at something that's completely different and draw a parallel to what you're working on or trying to build. Product Management is a very interdisciplinary role - it synthesizes so many skills and you have to be constantly learning and absorbing from different domains. If you're a product manager at a company that's doing, let's say, a social network, sure, you should know all about the other social networks out there. But maybe also be looking at how people are communicating in other mediums and draw ideas from that.
You must be data-savvy. You've got to be looking at data, processing data and really comfortable drawing a story from that data. Your gut can only get you so far. Your returns rapidly diminish if you're not augmenting your decisions with quantitative results. That said, you should also be comfortable making a quick decision with, maybe, 40% of the information you'd like. Most of my day is making quick decisions and relying on my ability to know when that decision is wrong, we will realize that quickly and my team and I will course-correct. This means being open to saying things like, "Hey I actually made the wrong call here, because we're seeing a drop-off there. How can we pivot and fix that quickly?" The team is looking to you, the product owner, to make decisions quickly, and you don't have the luxury of all the necessary information to make all your decisions. That's just a fact of life. So based on what you have, what's the next step forward? You cannot be the blocker.
Are there any other questions about product that I should have asked?
Product is such an interesting term. When I came into charity: water they had never had a product manager before. I was working with folks and realizing they had no idea what product meant or what I was tasked to do. That was a really interesting position to be in, and I found that in educating the entire organization about product and how to "lead with data", I ended up becoming better for it. I felt more confident about the power of product and how, through trustworthy interactions with your creative, engineering and project management teams, you could really build powerful, inspiring software.
I spend a lot of time wondering what people think is the difference between "product design", "product development", or "product marketing". Sometimes I feel like people just slap a title on, because they're like, "You're just going to come in and figure out what we need to do." That really is what product is, and the second word just clarifies the part of the organization where you make that impact. Someone once told me how they ask for the title "Head of Product" and then when they're talking to creatives they introduce themselves as "Head of Product Design", when talking to the engineering side of the world they introduce themselves as "Head of Product Development" and when talking to the marketing or biz dev teams they are "Head of Product Marketing". I mean that's a luxury that not all organizations can support, but I understand the thinking behind it. What exactly is "Product" and it's many different flavors is a really interesting question that the tech field is still figuring out. It's such an interesting thing to ponder, like how there is this emerging discipline of "Product Analytics" and how that intersects with classic product management. Is there really a division, or are we all just doing the same thing with maybe a little bit more of a focus on one or two of the smaller disciplines that make up that job responsibility? I don't really know, but I'm having fun figuring it out.
Well, thanks very much.
Cool. Thank you.