This week on the Product Science Podcast, we’re joined by Michel Feaster, founder and CEO of the startup Usermind. She has 20 years of product management experience under her belt in software. She went from working at a gas station to working for a billion-dollar software company which was acquired by HP, where she played a role in the strategic decisions that led to the third largest acquisition of HP’s history at the time.
Questions We Explore in This Episode
- What is Michel’s unusual journey into tech? How did her path shape her career in product marketing and management? What were the key moments in her career that helped her understand things from the customer’s perspective? How did her customers guide her education and insights?
- What should you do when a customer asks for a feature? How can you understand the problem you’re really solving as a product manager? How can seeing the pattern behind problems lead to greater financial opportunities? What roadblocks can lead to significant growth in your career? How did Michel’s experience with Ben Horowitz change the way she thought about product?
- How do you identify when it’s time to increase the size of your team? How does the product team grow when a company gets bigger? How do you organize your product team so that they have enough autonomy to work with individual engineering departments? What does a team structure look like at a bigger company? How do your priorities shift as a leader?
- How does Michel categorize the main features in product development? How do you strategize your investments to balance your needs? How do you take product in a different direction when your decision isn’t validated for six months or longer? How do you get the most bang for your buck with your resources?
- How do you make sure that your work is as impactful as possible? How do you effectively communicate to achieve your goals? What evidence do Usermind and Michel look at to make decisions? What are the differences between a startup and a more established business in this process? How do we use evidence to direct the most valuable resources in the company to work that is the most important?
Quotes From the Episode
“Great product managers ask a customer why—what problem are you trying to solve?” – Michel Feaster
“A PM’s job is to get the single most company impact out of the resources that they have.” – Michel Feaster
“The good product people say what they’re doing, the great product people sell you on the What by giving you the Why around those decisions.” – Michel Feaster
“How do we use evidence to direct the most valuable resources in the company to work that is the most valuable it can possibly be?” – Michel Feaster
“A great product person will literally do things that an average product person can’t.” – Michel Feaster
- Follow Michel on Twitter – @michelfeaster
- The Product Science Podcast
- H2R Product Science
- Follow Holly on Twitter
Holly Hester-Reilly: Hi, and welcome to the Product Science Podcast, where we’re helping startup founders and products leaders build high-growth products, teams, and companies through real conversations with people who have tried it and aren’t afraid to share lessons learned from their failures along the way. I’m your host, Holly Hester-Reilly, founder and CEO of H2R Product Science. All right. Thank you so much, Michel, for joining me. For our listeners who may not have heard of you before, can you tell us a little bit about your background and what you do today?
Michel Feaster: Sure, sure so my name’s Michel Feaster, I’m the founder and CEO of an enterprise fast startup called Usermind. First time founder, first time CEO, been at this for five years, but I’ve pretty much spent about 20 years, most of my adult life, in enterprise software. Very short stint in pre-sales, and the majority of that time in product management and product marketing, so I am very much a product founder and super excited about being able to build products from scratch that delay customers.
Holly Hester-Reilly: Awesome. I think it’s really fun to talk to people who’ve actually been doing product and working in software for 20 years because a lot of our listeners and a lot of people in the industry are so much newer to it. Take us back a little bit. How did you first get involved in software, and what was it like back then?
Michel Feaster: Oh, yeah. I’m a college dropout. I was working at gas stations, if you can believe it. That’s a whole other story for another day. This is the boom. This is kind of ’98, when there weren’t enough tech people, and I just got super lucky. My partner was prospecting. She found a job offering on the web, called me up at work and said, “You have to apply for this.” It was a pre-sales role, but it was at a company called Compuware. Which if you’re familiar with those guys, they were a billion-dollar mainframe company, and they were trying to transition to client server. They had this really interesting program called the Professional Development Program. They would fly into Michigan for a whole summer or for three or four months, train you how to code, how to present, in SQL, and I remember learning C and kind of crazy. They release you into this indentured servitude where you have to stay for 18 months, at a reduced salary to pay them back for their investment. They were doing that to basically produce both consultants and pre-sales folks.
Michel Feaster: I was very blessed. I was given the opportunity to do both. I knew I really enjoyed kind of interacting with customers. I like different problems, so I felt like pre-sales would be a better fit for me. Went back to New England, and that’s when my whole tech career started. An unusual entry point. No degree, no computer science background, no reason I should have ended up in tech other than I got lucky in the right time at the right place. I tell people my life has had pivots, and that was for sure one of them. I’ve been in tech ever since. That was … gosh, that was my mid 20s.
Holly Hester-Reilly: I feel like there’s probably going to be more stories like that coming out these days because a lot of people are trying to switch over from different areas, and companies are having a hard time finding enough trained talent.
Michel Feaster: Totally. Then, it was interesting. I was in pre-sales there. When I joined Compuware, they were probably fifth in the market. I was given a product line that was in the testing space, and just got lucky. I started taking deals. They were fifth in the market, Compuware was, and I started taking deals from the number one player, which at the time was a company called Mercury Interactive. Maybe after six months I’d been in working for Compuware, my phone started ringing. Mercury sent headhunters after me, and at first, I didn’t return the phone calls, but as I got to the end of my tenure at Compuware, it was pretty clear to me that that wasn’t a good culture fit.
Michel Feaster: I don’t know how much, if you’ve ever even heard of them, but they were very suit and tie, very conservative, extremely hierarchical, and I’ve just never really done well in those environments. I think I do best where there’s low rules and high customer focus, and so, I picked up the phone one day, took the call from a recruiter, went and met the Mercury guys, and felt like I’d found my home. I actually left Compuware, and joined Mercury, and I stayed at Mercury for almost eight years, which is crazy.
Holly Hester-Reilly: Wow. Eight years is a long time in the software world.
Michel Feaster: Right?
Holly Hester-Reilly: Very much. I’m curious what made it feel like your home there. What was it like?
Michel Feaster: It’s funny. When I interviewed, I interviewed the reps, and I met the team. It was such a customer-focused culture. Number one, the products worked. That’s an amazing … For those people who have not been in tech very long, a lot of times, the hype is far ahead of what a software app can actually do. The magic that’s created when products really work and deliver reliably is pretty amazing. First thing, they were very well-known and loved by customers because the products worked, but the culture was really functional. It was a very, as the company grew, it maintained its focus outside the company, and I think that’s a hallmark of successful software organizations is this relentless focus on the customer and their success. I was really drawn to that.
Michel Feaster: I’ll never forget, I joined, the first day I was there, I walk in, and my computer’s on the desk, and my phone’s there, and everything I need to get productive, and I thought, “This is where I wanna be. I wanna be in a place surrounded by ultra-competent people, super focused on helping me be effective and helping customers be successful.” Right culture, right product, and then of course, eight years later … I probably wouldn’t have left. Obviously, we got acquired at the end by HP, so the company ceased to exist as I knew it, but it was an incredible place to be.
Holly Hester-Reilly: What are some of the things that they did to keep the focus on the customer? Especially, it sounds like, it was probably an eight years of change and growth. What did they do along the way to make sure people were still focused and aligned and making it happen for the end user?
Michel Feaster: It’s interesting. I have two lenses on that. One, obviously, in my time, I spent three or four years, half my time there, in pre-sales in the field. During the time I was there, many, many sales organizations go through this process of stratifying. When I started, basically, I covered a zip code, and any deals in that zip code was my rep-owned. By the end, I was running what we called strategic accounts, which were GE and Fidelity, the biggest accounts in the region. As we shifted to that more strategic account relationship, the role of a pre-sales person shifted quite dramatically. Instead of POCing a software product for a 70k deal, I was talking to Fidelity about their three year roadmap for quality. I got very involved with the product organization, and I think that was the first ways I think the sales organization felt very empowered to connect the customer in the product organization. Even in scale, we were, at that point, 500 or 1000 people.
Michel Feaster: My first interaction with this customer-centric culture was pulling people from corporate, engineers, and product people out to the customers to partner on this larger vision, actually one of which turned into MNA, so I was very vocally behind an acquisition of a company that Mercury did. We acquired a company called Kintana. I think there was just this really a strong megaphone between what the sellers were hearing from customers, and products, and engineering. Mercury really responded to that. Whether it was by adjusting a roadmap or buying companies. That was my first exposure to be customer-centric is to relentlessly just talk to your customers. Then, I ended up joining a product organization, and then, that was very interesting to me because that was the first time I saw, for example, how powerful the data from a call center could be.
Michel Feaster: My very first product gig, I took over a business. It was a product called LoadRunner. At the time, it was already the market leader, and it was 300 million in revenue. Very big business, relatively speaking. There was a ton of existing customers. For the first time, I actually learned how not just to talk to customers in the sales cycle, but I would meet with the call center team every couple months. I’d review all the tickets, and I was looking for patterns in the tickets. That was really fascinating as a way to start to understand where customers saw friction. Then, probably my favorite part was, when I was in product about six months, I started doing customer visits that were really pure products, where I’d go and interview people about their work structure, about their reporting structure, and their MBOs, and where their challenges were.
Michel Feaster: That’s probably what really, I think, if you did all three of those things, and you said, “Okay, great software company. It needs to listen to companies in the sales cycle. You need to listen to what customers are struggling with. Then, you just need to go out and interview and talk to them, a day in their life, because you’ll surface so many interesting opportunities for your product that you would never have heard, either just in context of selling, or solving a problem. I think it’s a pretty rare company I feel like that takes feedback from all those channels and uses them as an input to thinking about well what features should we build and why, and how do we think about our roadmap and the big problems we could sell for our customers. I often tell people I think that product role was like my college education. It’s a blessing. Product management is much harder when you don’t have customers. It’s much easier when you have a lot of customers I think.
Holly Hester-Reilly: That sounds fantastic. I always love the real visits to their offices, and getting to understand what their day to day experience is like. That is the best way to figure out what’s going to make a difference.
Michel Feaster: One, I mean, just funny for me, it was a huge Aha!, so this is dating myself. LoadRunner was a client server application, you would download it on your desktop. It was sold perpetually. This was before SaaS. Really before web-based applications become the norm. But I went and I went and I interviewed, I don’t know, 10 or 20 of our big customers. It was very interesting. What I heard was load testing was quite often a full-time job, meaning that person was a performance tester. But they might live in one business unit, but we do it load testing part-time for lots of different teams. We had this huge Aha! about the fact that while load testing is very strategic, it’s not a thing you do every day, you do it on a time-based … As you’re doing a roll out of a new version, you do a lot of load testing.
Michel Feaster: It became really clear that it was a right function for being in a center of excellence and operating as a shared service. A lot of what came out of those visits wasn’t really just features, it was we put our whole weight as a company behind testing centers of excellence and helping companies think differently about how do you create a shared service of some of these testing skill sets. Where performance testing is quite a deep skill set. But you don’t necessarily have to do it every day for every application. I think we turned a lot of what we learned in the thought leadership that we shared back for our customers. Also, we built a whole new version of LoadRunner that was web-based that was designed to work in a shared environment with a scheduler, and so forth.
Michel Feaster: But, man, it was so eye-opening that you can have a product as successful as something like LoadRunner where you have 70% market share and where you have thousands of happy customers, and yet, literally, if you just dig a little deeper, there’s just a massive opportunity to lead customers to the next level in terms of thought leadership, and organizational approach. It was, honestly, it was some of the best product work maybe not that I’ve ever done, but it was just an incredible opportunity to really learn what product is.
Holly Hester-Reilly: Did you have product mentors that you were working with at the time that you learned from?
Michel Feaster: Yeah. It’s interesting. The answer to that is yes and no. The very first thing I did was I asked the people who I respected in that organization what to read. They all said, “Read Crossing the Chasm, and read Influence.” I think I had great conceptual mentors, these incredible books and technology about how ideas cross the chasm, and how people buy. That was one really amazing gift. I’m really glad people took the time to give me a list of 10 or 12 of these iconic books to read. I went to a Pragmatic Marketing course, so I’m huge fan of Pragmatic. I think I didn’t really know what product management was. It’s kind of funny at the time, the output from a PM was an MRD. This was like when Waterfall was the approach, and the leases were a year. But so Pragmatic was fundamental to my thinking.
Michel Feaster: I didn’t know what my job was, so that was fundamental to like your job is to collect all this data and write a doc that can steer engineering all the way from market strategy all the way down to specific product Asks that can be turned into a PRD. I think Pragmatic gave me a super conceptual understanding. But I don’t know that I had … I had a great boss at the time. But to be honest, I was given almost complete freedom. It was pretty insane. I don’t really … There wasn’t a lot of me going to other product people and reviewing my work. It just was so clear when I did research the evidence around this shared service opportunity was so big. I don’t want to bore you with a lot of the other kind of insights. Maybe the other big one was we basically saw two personas in our performance testing business, these hardcore devs who were in a shared service model, and really technical.
Michel Feaster: Then, we had these other people who were business analysts who weren’t technical. We built personas, and we called it Build for [Christine 00:14:50], which was this non-technical woman that I met. I don’t know that I had particular mentors beyond the books and the basic training, but I feel like we had so many amazing customers that we could go and basically create a universe of ideas and really test our hypotheses against their feedback. The engineering team was amazing. They were just such great partners in that process. They were so excited to be talking about a multi-year change. But what a gift. Talk about an incredible opportunity as your first product role.
Holly Hester-Reilly: Absolutely. I think in many cases, the opportunity to start, and to learn the things, and to get the access to the customers can make a big difference. But then, I also think about how you said that you were able to dive a layer deeper and see this opportunity beneath what was already successful. I think that’s something that a lot of people that I talk to sometimes struggle with. They get caught on that surface level, and they’re making the tweaks that get them 5% here and 5% they’re not always looking for that deeper opportunity that will take them another step change.
Michel Feaster: It’s funny. When I interview for other people, one of the things I look for is how do they … When a customer comes to you and says, “I want this feature,” I think I wouldn’t have a bad or average product manager build the feature the customer asks for. But great PMs, really great product people, ask the customer why. What problem are you trying to solve? Take down the requirements. Take down the Ask, as they describe it. That’s fair. You’re taking their time. But my delay was always asking what problem are you trying to solve? Quite frequently, what I would find is a couple of things. One is the problem you’re trying to solve is a repeatable problem that many customers have. But the solution they’ve invented, so the feature they’re asking for is a solution that they’ve thought up in their mind as a problem. The risk of product management is you build a bunch of these one off features, but you never solved the real problem because you never understood it.
Michel Feaster: To me, when I would train young PMs, one of the secrets is teaching people that your job is to get to the underlying why of the what they’re bringing you. I’d say that we’re detectives, and we collect problems. Then, what we do is we look at how repeatable are those problems. If the problem is broadly repeatable, then, I would go to my engineering team and say, “Look, all these customers, as an example, someone might come to you and say, “Hey, I want this customer report.” Every customer wants 50 different customer reports. If you actually ask why they need them, it’s because they have a report to give their boss every month that ties their testing work back to their KPIs. Actually, that problem is quite common. Then, you could build not one customer report but some kind of a KPI center, where you can give a couple more features all added up together that solves all 50 problems for these 50 customers, as opposed to these 50 individual features.
Michel Feaster: To me, that’s a central skill of product management is not just collecting feature requests but digging one level deeper into the patterns of problems. Then, of course, the financial opportunity of solving those problems. Is there enough benefit that you can introduce a whole new product? Or have you found problems that are monetizable stand alone, and there’s a whole new product there. But I think it’s a central skill to being a great product person, and one that I don’t know we talk about a lot or people are taught.
Holly Hester-Reilly: I’ve actually found that the more people I talk to across different stages of company, and different levels of maturity, or experience in the tech industry, I keep finding, time and again, that people are still at that early stage of even understanding what product management is. Each of us is going through the experience and learning more and more and thinking, “Oh, everybody knows more now. Right?” But there’s so many new people every year, and lots of people are not so clear. One of the things that I’d love to hear more about is your past since then. You’ve had some incredible opportunities, and you made a great impact. Then, they got bought. Then what happens?
Michel Feaster: It’s interesting. I remember crying. I was on vacation on Lake Tahoe when I heard about the acquisition. I did actually cry. HP software, where all good software goes to die. But turned out to be one of the next great chapters of my life. After the acquisition closed, I was in Israel with my engineering [inaudible 00:19:35] actually working on some roadmap stuff. My boss called me up and said, “Hey, there’s this other business HP has, this data center automation business,” and this is dating myself again. This is when virtualization is the hottest technology in operations. It’s before dev ops becomes broadly a concept. Virtualization was introducing [inaudible 00:19:57] and complexity in Operations, and managing Operations, which was really fueling the rise of a whole new set of software market category around automating data center Operations. HP had done a couple of acquisitions of companies and was trying to play in that space and really had been woefully unsuccessful. I think they were maybe sixth in the market. My boss said, “Hey, kind of, you’re my glass breaker. Do you want to go see if you can figure this out?”
Michel Feaster: One it’s a real pain point. The field is kind of, the sales people are kind of screaming about it. But two, if you solve it, it’s a problem that has a lot of executive focus, so it’d probably be good for your career if you can make a positive impact. I remember, I said no initially, and then, I went to sleep. I said I’m just scared that I don’t know the space. Because my leg up in testing was having come from pre-sales. I knew the customers pretty intimately. I thought I want to go see if I can do product management in a company, in a role, where I did use the software, where I’m really just a pure product person. I took the gig.
Michel Feaster: Literally, I remember, two weeks in, I presented to the leaders at HP software and said, “You know? Number one, we’re fifth in the market. We’ve invested a ton of money, and guess what, the market is already consolidated. There’s three vendors.” This time, it was Opsware, Blade Logic, and IBM, all of whom have 80% market share. We’re not going to innovate … HP is not an innovation company. We’re not going to innovate our way to first in the market. The market has already chosen the top three vendors. If we think this market is strategic and we have to be in it, we should just go buy number one or number two.
Michel Feaster: If we don’t think it’s strategic, we should just shut the business down. Because we’re wasting money. We’re burning money, and we’re never going to actually move the needle to be where we want to be. That sparked a whole set of conversations that culminated in the acquisition of the software company called Opsware, which was for $1.6 billion, which is crazy to think about. That company was founded by a man who had become very famous. Marc Andreessen was already famous. He was the founder of Netscape, inventor of the browser, and Mosaic.
Michel Feaster: Of course, Ben Horowitz, who is now famous, he’s written the book Hard Thing about Hard Things, and they built a really famous BC firm. But literally, and that was my next big life change. We acquire Opsware, and Ben Horowitz becomes my boss. I think, generally speaking, in big companies I expected that they would rotate me off of this in special projects. For anyone who’s worked in a big company you know what special projects need. It’s like a holding place. I thought, “My work is done.” Right? I [inaudible 00:22:44] this whole company. They have a product team. They have an engineering team. Ben was taking over all the software. He’s going to have his people run his business. Of course, Ben, if you read his book, he writes about this management technique called Freaky Friday, where he rotates people. I met him, and he said, “I want you to run my business for me, working for me.” I took over the product function for the Opsware business, kind of crazy working for him. I led the integration. Where Jason Rosenthal was my partner, by the way. That completely changed my life.
Michel Feaster: Literally, not only was it an incredible experience to integrate two companies, where you touch everything, pricing, comp, licensing. I mean, I learned so much that has served me well in my later building companies from scratch kind of part of my career. But literally, Ben has become the great mentor of my life. I mean, I remember, I worked for him for six or nine months, and he was like, “Why are you in startups? Like, why, you’re a founder. What are you doing in big companies?” It both changed my life because it gave me this incredible opportunity to manage and scale. My direct team was like 60 product people, which was just … products on a scale function. He was the best boss and mentor of my life. I got this incredible one in a lifetime opportunity to both lead and acquisition and integrate these two companies. While it started off at Super Staff but joined HP, ultimately, the entire course of my life changed in that 18 month window.
Michel Feaster: As is public now, he obviously left and then founded Andreessen Horowitz. I remember calling him. It wasn’t public yet that he and Marc were founding Andreessen, which is now one of the top five Silicon Valley VC funds. I called him up and said, “Hey, man, look, I got to get out of here. I can’t, there’s no way I can stay at HP.” I ended up going to one of their first investments, which was a company called Apptio. I was employee 17. I was their head of product. That was my first chance to really go build a company from scratch. That turned out to be an incredible chapter in my life. Those guys have since gone public. Actually, a couple weeks ago, they just got picked up by private equity. But I mean, I was there from employee 17 to like 600. Talk about what an incredible … I always tell people that’s my … If Mercury was my college degree Apptio was my MBA.
Holly Hester-Reilly: That had to have been an incredible ride.
Michel Feaster: Yeah, crazy. By the way, that was the first time I managed a SaaS product. Up until then … Now, it seems obvious that all products were SaaS. But now, let’s see, I’m dating myself. Let’s see. This is 10 years ago. I think it was clear that all new companies were going to be SaaS, but they had up until then to get SaaS. That was a crazy experience. All the things we know now about SaaS that it’s obvious that you need to track usage data. Even all the tooling around AWS on how you build SaaS applications, that didn’t exist. Not only was it me learning how is product management different, one, when you have no customers, but I joined when they had 15 customers. Two, how is different in a world where you’re selling a subscription versus perpetual license, [inaudible 00:26:18] is an issue in a way it never was. Or was not so important. Then, obviously, how do you basically build the whole company, not just the product. That was an incredible life experience along every one of those dimensions, but yeah.
Holly Hester-Reilly: That one is really fascinating to me, and I’d like to hear a little bit more about some of the pieces. One of the ones that there’s so many things we could pick up on in there, but I think one of the things that I’m interested in is the building of the team that built the product. If you were person 17 and then you’re there through hundreds of people, what did building out that team look like, and how did you even identify when it was time to add people to it. Because a lot of people struggle with holding on for a long time when they’re in this growth environment.
Michel Feaster: Interesting. It’s interesting. I think product is, by definition, not a scale function. Which means that when revenue grows, engineering will become a giant team. Marketing will become a giant team. Sales will become a giant team. In relative terms, product will never be a big team. Even, you have to get to the scale of Amazon or Microsoft until you’re in the hundreds of product people. The law to be a product is you only hire 10Xers. Because the contribution of every single one of those people has to be so great. I think I was the only PM for the first probably 18 months. Actually, my first hires were on the product marketing side. I was more initially … I ran both product management and product marketing, which I recognize as a little unusual, but I think it’s incredibly powerful if you can do it well. Because in enterprise, particularly, the product is important, but how you sell is almost a product.
Michel Feaster: In enterprise companies, I think product marketing is almost as important a discipline. Actually, initially, my hires were on the product marketing side, and it was very much around sales enablement and refining what we call the plays, which is the solutions. What are we selling, to whom, in a repeatable fashion. I think only after, let’s say, two years in, we started to scale the product organization. I don’t even remember now, but when I left, it was probably still small. I don’t know. 12 people, or 10 people. In the Apptio, go-to market, we had different applications on the platform, so we kind of ended up with PMs who owned different applications and had span of control, or like the GM of benchmarking, or the GM of planning. One piece of it was you can only really hire … You need to hire great people. Because innovation has to happen at all levels.
Michel Feaster: Then, once you’ve hired a couple of great people, how do you organize them such that they have enough autonomy. Because you don’t want to have to triage across backlogs. There are some compromises I think in the product team you make or in the work structure is on the one hand limited by the talent pool. On the other hand, you have to align them to engineering organizations, so they’re maximally autonomous. Then, I think your role as a leader shifts from product work to what I call portfolio work, which is really ensuring that the team is aligned around the right overall priorities. I call it the resource pie. That the way that the overall engineering investment is being spent is aligned to the overall company priority. Because that’s the challenges. You want to give individual PMs autonomy such that they have a dedicated team of devs where they can drive that, and the team can work together and make impact.
Michel Feaster: But on the flip side, you need to retain control over the strategy and ensure that some of the resources are being spent to maximum impact in the company. That’s where I think the VP of products role shifts from product work to portfolio management, and prioritization. I don’t know if those words are clear or not clear, or if we should talk more about them. But that was a very interesting evolution over time.
Holly Hester-Reilly: I think some of our listeners will recognize those words, but maybe some of them will be more aspiring. Tell us a little more about maybe if you could give a story about portfolio management and how you might align the resources to fit with the strategy.
Michel Feaster: I would say a couple things. One, so portfolio management is about making sure that the sum of the features is very, a product in my mind. When I think about the portfolio, I had a couple of quadrants that I would articulate the strategy in the company to the company we’re on. One was there are features that are all about the market, innovation, competition, winning deals. These might be sales features. Or they might be like some technology is changing, so we need a gadget for social. But this is the innovation kind of bucket slash sales compete bucket. There’s the, “Hey, I need features.” What I call time to value features. Which is I need to deliver more work in our services organization faster, or for customers. It’s all about getting the customer to value as fast as possible for product.
Michel Feaster: Then, there is what I call Keep the Lights On features, which are features that are based on a bunch of paper cuts. It’s the customer calling in to support and being like, “Hey, this UI thing is not intuitive.” By the way, if you don’t invest in that over time, you get a lot of … That can lead to turn, and you get a lot of very unhappy customers. Then, there’s platform investment. This is investment that you just have to keep investing in the core platform on the SaaS application. Whether it’s for scale reasons. You need to invest and punch fast on performance issues, or it’s security. But there’s feature investments that are really about platform viability that may yield no obvious benefit to the customer or the sales organization that are critical.
Michel Feaster: I always would, in any given quarter or year, I would be looking at where does the preponderance of the investment need to be. Forgetting the features, at the strategy level, we need to win new deals and revenue. We need to deliver as fast as possible and lowest cost. We need to keep our existing customers happy, and the platform needs to work. That’s my four buckets. The four buckets are probably different for every company, but that was how I thought about Apptio’s business, specifically. I would look at it bubble up, the percentage of investments going to each of those things. When I would communicate to my boss, or the board, or my peers, we would be talking about that. Because they didn’t always understand the various features, but they do agree that paper cuts matter and if we don’t invest some amount, they don’t like it. Most sales organizations, even customers, really hate it when there’s big platform investments. But they have to be done, and if you don’t talk about them, you’ll end up with a lot of debt.
Michel Feaster: When I say portfolio management, and by the way, if you don’t innovate, the company could die. Or if you don’t deal with competitive features, there might be no business. There’s no fixed pie. The percentages that should go in any one area are very dependent on the state of the company. If your architecture is old, and it’s not … If your Twitter, with that Ruby architecture, at the point in time where they had to migrate off it, your resource pie might be 99% of people are on platforms because the company is dead if it doesn’t happen. If there’s a giant mega shift. Like your product that is built for the web, and mobile is coming along, maybe you need to like life or death for the company to build a whole new mobile app. There’s no fixed percentage, but it’s a way to help people in the leadership team, or the board, and yourself get out of the feature myopia and get into the what are the risks, what are the risks for the company, strategically where do we need to be investing.
Michel Feaster: Then, really, if we’re honest with ourself and we look at where our actual engineers right now are coding, is the actual work of the engineers aligned the strategy in our head. It eliminates this, a lot of friction, I think, organizationally. Because it helps to kind of create this language where people in the company can orient around the strategy and which investments we’re making and why. By the way, particularly, in product, I think we have … The onus is on the product organization to articulate the why. Because no one knows if we are right in product for 18 months, or 6 months. It takes us a while to [inaudible 00:34:56] features. It takes a while for customers to adopt them. By the way, people won’t know whether your innovation was right. Maybe for two years until that thing builds revenue.
Michel Feaster: Anyway, I used that within my team. I used it to move engineering resources around. I use it to communicate to the leadership, to the board. It’s really about … Portfolio management, to me, is ensuring that the maximum impact from the current resources you have is really, the work is aligned to the best strategy of the company currently. In my observation, a lot of companies fall down there. Like people really good at managing the JIRA backlog, but they’re not really good at managing the strategy.
Holly Hester-Reilly: One of the things I really love about the way you talk about it is how often you use the word invest. It’s something that especially when I talk to people who are earlier career, or maybe aspiring leaders who have only been in it for a few years, they don’t talk as much about how everything is an investment towards the strategy, or towards the growth, and I really like that perspective.
Michel Feaster: I think boil it all down, a PM’s job is to get the single most company impact out of the resources they have. That goes back to prioritization. Our job is to find problems or market opportunities to design solutions for those market opportunities, and then, by the way, ensure that the resources we have are going to get maximum bang for the buck. A lot of that is ruthless prioritization. When I hire PMs, those are the skills I’m looking for. Then, in leaders, I’m looking for that ability to manage the portfolio, to constantly ask are we really directing the resources at the most important problems that are going to have the biggest business impact.
Holly Hester-Reilly: What do you see as the role of communication, and how have the teams you’ve worked with communicated what they were doing and why they were doing it with people outside of the product team and inside their team, across their units?
Michel Feaster: It’s interesting. This is a hard one. I think communication is essential. I always say PM is a job of influence. You owe no resources directly, and yet, you’re accountable to make the company successful. Influence jobs are 100% about communication. I will say that while I consider myself a visionary, I don’t think I’ve always been the best at that part of the PM role, so it’s definitely been a thing I haven’t always done perfectly. But look, I think, number one, there’s input. Communication is taking input. I think it’s very important that all functions feel like they’re being heard. A product team has to have very good influence of how do you take feedback from customers, how do you take feedback from pre-sales, how do you take feedback from services, how do you take feedback from your own engineering organization about what they think is important.
Michel Feaster: I think whether or not we act on every single piece of feedback, it’s very important that every function feel like they have a communication channel into the PM organization. Exactly how you do it, it’s some mix of like a process. We have JIRA, and you can file a ticket. It’s some mix of a structure feedback session so that people can actually give you color around which things matter. I’m really big on ranking and voting exercises, so Usermind, for example, my pre-sales organization gives product feedback. We ask them to stack rank what they want and to present each the pre-sales guys can all submit tickets. But what we want at the end is the whole team speaking about a prioritized list, and here are their top 10 things and why. Because you need to make sure you’re working on the most impactful things that will help them.
Michel Feaster: I don’t think you can do that just with JIRA, so at least in my experience, you need some kind of a process that stores all the data. Then, you need a human process, a quarterly business review where each of these functions provide structured feedback for the product team. That’s kind of one important piece. The other important piece about communication is then explaining the trade-offs and explaining why we’re making the decisions that we’re making. That is some combination of the roadmap. The roadmap is the representation of all of the product team’s plan. But I think how you deliver that to each function is done differently. You probably do a product roadmap session in your kickoff or your quarterly business review for the sales organization, but to some extent, you’re constantly negotiating roadmap with engineering. I think you just need a similar structure and cadence. It’s not just the what. What I find is the why is really important. Everybody needs to know what we’re doing but why.
Michel Feaster: That’s why the resource pie, to me, is such an important tool for communicating out. Because nobody cares about the list of 17, or 50, or 100 little paper cuts we’re fixing, but I think everybody can get behind the fact that, “Hey, we need to put 15% of the pie on just making sure our customers stay happy.” And like do we really need to discuss every single one of those features? No, but just everybody should know that we are carving out a set of people who are going to go do that. I used both the roadmap and the resource pie to articulate the marriage of the what and why. Because what you’re really trying to create in your outward communication is trust. We’re listening. We understand the market. We obviously are making trade-offs. You can’t do everything. Here’s why we’re doing the set of things we’re doing. I think the good product people just say what they’re doing. The great product people sell you on the what by giving you the why around those decisions.
Holly Hester-Reilly: Absolutely. You hit a lot of high points on communication, the what, the why. I’m thinking about what other elements do our listeners want to hear about. I think one thing that would be interesting to hear your perspective on is how people in your organization, here, at Usermind, or at Apptio, how do they make decisions with evidence, and is there cohesive practices. Is it kind of each person is empowered to do it the way they like? What does that look like?
Michel Feaster: I would say, I think every decision needs to be evidence-based. I think what constitutes evidence is very phase-dependent in a startup. When you’re, let’s take the obvious one. Let’s say you’re a big startup, like Zen Desk, or your Google, where you have a lot of customers, and you have an existing product, and you have a lot of data, then, I think experimentation is one of your go-to skills in PM. You look at consumer product management, and a lot of decision-making is driven by experimentation. Because you have the volume of both people and the scale of the business to permit that.
Holly Hester-Reilly: [crosstalk 00:42:32] Can I just ask for a clarification there? In that context, when you say experimentation, are you primarily talking about AB or multi-variate tests that are pushed live, or what?
Michel Feaster: You look at Twitter. You look at Google. The way they make decisions is evidence-based by seeing what real users do and by ideating and prototyping a choice and getting real user data, and then, building it only if they think it works. But I think your style of evidence has to be very specific to what kind of company are you at and what stage are you at. [inaudible 00:43:09] opposite end of the spectrum, your Usermind, you’re Michel, you have yourself and one co-founder. You don’t even have a company. How do you make an evidence-based decision in that case what constitutes evidence? To me, let’s say you’re founding a company, and you have a product hypothesis, the first thing you should do is do a bunch of user images, and you should do structured questions. You ask everybody the same questions. You have something you’re going after, or a problem you’re digging into. You can make a very good product hypothesis and very evidence-based choices.
Michel Feaster: If I think about our first prototype that we designed, it came out of about 85 interviews that we did about a day in the life and what problem we wanted to solve. But that’s evidence that’s not, I mean, how heavyweight is that evidence. That’s just [inaudible 00:43:57]. I think that, and then, of course, if you get to the middle stage of being a company, where Usermind is now, we have people using the product who can give us feedback. We have user research we can do. We have tickets that people call in. The nature of the evidence you’re using, to me, is very specific to what kind of company am I, where am I in my stage, and how do I … Look. To me, the reason you want to make an evidence-based decision is that’s just [inaudible 00:44:32] notion.
Michel Feaster: The most valuable resources of any technology company are engineering resources. If we spend them coding things that are not valuable or that don’t move the needle for the company, it’s basically waste. How do we use evidence to help us direct the most valuable resources in the company to work that’s the most valuable it can possibly be. Now, on the flip side, I would also tell you that I’m not so hung up, I think there’s a very important bar for how much evidence do you need and how much goes too far. In my opinion, if you have a pattern, and the pattern, like in my 80 user interviews, if a pattern is consistent enough in 20 interviews, and my market research indicates I’m roughly right, I’m not going to go get another 40 people. There’s diminishing return to me. By the way, likewise, so when we design features here, we definitely get customer feedback, but we don’t overthink it. We need enough to know that it’s directionally correct. We also trust that we’ll get feedback to iterate on it.
Michel Feaster: There’s also this point, to me, of what’s just enough. How do I get just enough evidence to make the best decision I can make without taking too long or over-analyzing something. I think that’s a very important skill is just enough evidence to make an 80 or 90% right decision. In an startup, by the way, that’s the right methodology. That’s, by the way, maybe, the other thing about product management is your evidence to risk is what company are you working in, how much risk can you tolerate. If you’re deploying a feature that might impact the security of the platform, probably 80% risk is not good. You have to be 99%. There’s also this judgment call you’re making about how right am I and how much risk is there of me being wrong to decide how much evidence is enough evidence.
Holly Hester-Reilly: I think when do decisions need evidence and what kind of evidence do they need is a key theme that we like to explore.
Michel Feaster: I think decision is always the evidence. The only people who can barely get away with no evidence are founders. Even we have to show our board, and justify to investors what we’re doing.
Holly Hester-Reilly: Perhaps it’s the skeptic in me, but I would say I also … Sometimes, I see decisions being made with very little evidence inside the enterprise where they’re very cushioned. It’s going to be a long time before they see the impacts because their company is just already making a billion dollars.
Michel Feaster: My point of view is probably very biased by the fact that I’ve only been in tech companies and high-growth companies, and now startups for a very long period of time. Probably that risk reward decision is very different if you’re a giant enterprise where your decision doesn’t have any impact on the company. I’ve always done product management in companies where I could connect the dots between my decisions and the financial impact to the top line or the bottom line of the company.
Holly Hester-Reilly: Absolutely. I think that actually leads me to my next question, which is it sounds like you’ve had a lot of amazing experiences, and you’ve had a lot of opportunities to learn and try things with great user bases and work with great engineering teams. What are some of the things that you’ve learned along the way through, maybe learned the hard way. Something where you tried something. You felt really strongly about it, and then, later, you realized, “Okay, next time I’m going to tell people like not to do that.”
Michel Feaster: I mean, look, being a CEO and a first time founder, I feel like I’ve made every mistake in the book. I can give a couple of them. One, we started the company. Good practice. My co-founder and I built a little prototype, validated with some people, and to be honest, five years later, the product idea was basically right. We raised the money, and I’ll get to the mistake. We raised the money, and we started to hire engineers. We made two mistakes that were interrelated. One, all the early engineers, my co-founder was my technical founder that we hired, were really senior and really late in their career. We ended up with like six alpha personalities, all of whom felt they were really right, all of whom had built really big things before, and nobody who really wanted to listen to each other. To be honest, it probably took me 18 months to 2 years to clean up the architectural mess that was reflected in that lack of functioning in the early hires.
Michel Feaster: The second thing was I probably had the data at around three hires, but it wasn’t working very well. But I felt pressure. The idea was right. The market was right. We had the money. Why aren’t we producing enough code, and the answer was like, “Well, we need more engineers to produce more code.” What I now know is that’s not true. If I were to go back in time, the mistake I made first was I think you need some leaders and some followers. If you’re building your early team, you need to have role clarity. Like you need two leads, or three leads, whatever makes sense for your product, and you need followers, people who do what they say.
Michel Feaster: I don’t mean, that do what they say, people who know coding know that a lot of young engineers really want to work with these senior engineers to learn from them. You need to architect a team that functions and works, and our approach of having these, maybe there was an alternate team of really senior people that might have worked. But the most important thing in your first five engineering hires is team cohesion. Because architecture and productivity are directly an outcome of all those conversations. That was a gigantic mistake.
Michel Feaster: Then, the other thing is a gigantic mistake is scaling anything that’s not working too fast. Which is what I should have done when I saw that I had three or four engineers who weren’t producing enough code is say, “We’re not going to hire anymore people until this first batch works, until the process works, until we’re reliably delivering features.” Because scaling a broken thing only makes it worse. It’s so much harder to fix something at 20 people than at 3 people. Those are probably two huge mistakes that I made that were very preventable that if I were founding again I would take a radically different approach to my first six months. Because I think if you lay a good foundation, the alternate world where you hired six people, and they gel, and they’re kicking ass, man, the amount of velocity you can get then from scaling the team could be huge. That’s for sure one of them.
Michel Feaster: I think another huge mistake I made, which, it’s fine. It’s an example of a mistake that wouldn’t tell you. But when I founded Usermind, so we’re basically building what’s called a journey orchestration platform. If I was netting out what I heard, I heard from people, “Hey, look, customers are interacting more directly with companies.” Everyone’s head nods. The companies are adopting tons of new channels and therefore tons of new technology. There was this really interesting technology problem that you end up with 20 different systems communicating with the customer, none of which integrate together.
Michel Feaster: I’m like, “Wow. That seems like a pretty strategic problem.” And why don’t Marketo, and Salesforce, and ServiceNow, and Google Analytics, and HootSuite, why don’t they talk to each other? Because, man, you would sell more stuff and the customer would be happier if you could actually connect those systems together. I thought, “Wow, that’s a really strategic problem to solve.” I thought, “Who’s the buyer?” I thought, “Oh, well, who’s the buyer?” I thought, “Oh, well, marketing and sales really are the ones who care about the customer experience. That’s who I’m going to sell to.” I think problem statement, very validated by the market today, early segment, that was right.
Michel Feaster: Then I said, I’m going to go look at vendors who, one, in marketing and sales and see how they did it. The playbook seemed to be basically the SaaS and digital marketing leaders. Then, only then would the enterprise pay attention to the technology. Marketo, basically, won the valley, and then, big enterprise companies started to buy marketing [inaudible 00:53:00]. I thought, “That’s my playbook.” I thought, “My segment is this mid market segment.” I launched the company, and our pipeline went 100% … By the way, I built my product for that segment. I thought, “Oh, it’s all going to be self-serve.” Launched the company, and my pipeline went 100% enterprise. Turns out, hindsight is always 20 20, that if you’re a high growth startup, you can muscle your way through these customer problems by hiring more people. But if you’re giant enterprise actually can’t hire more people. And very small percentage increments of customer improvement have big revenue applications.
Michel Feaster: It turns out, although all of my suppositions sounded right and still sound right actually my system, Usermind is most valuable to the largest companies in the world. We had to build features we hadn’t thought about, and we had to, it’s a different sales motion. And you need [inaudible 00:54:03]. The implications of that wrong decision are very large. The good news is if you’re a startup, you’re designed to iterate through those. None of those were like killing the company. I would say that our issues on the engineering side had far more lasting impact than choosing the wrong segment. But those are two great examples of very, very big mistakes that I made along the way that you have to get back up and keep battling really.
Holly Hester-Reilly: You do. That’s how you get past it all. Right? Awesome. This has been really fun and interesting conversation. Do you have any final thoughts or things that you would want to share with aspiring product leaders or product-focused startup founders?
Michel Feaster: Oh, what do I want to share? Look, I think, one, I do think product is a 10X function. Meaning, I think product and engineering are, most functions are probably this way, but my point is a great product person will literally do things that an average product person can’t. I think if I was talking to startup founders, I would say, “If you’re a founder who didn’t come from products, you need to figure out how to recognize that 10Xer. Because it’s like adding another founder to the company. It will give you so much leverage for the company’s success. You want to go talk to other great product people, so you can figure out how to hire that 10Xer.
Michel Feaster: I think for young product people, I would give the same advice I got, which is if you really want to grow in your career and product, you should either do one of two things go work in a very high growth company where if you’re really good you’re going to be given bigger, and bigger, and bigger problems to solve. Or go work in a big company and jump on the broken business. Like my move in a data center automation. Those are moves that I think are very good career advice, especially for product people, because product jobs don’t just grow because the head count grow. You grow because the business shifts. I think be very intentional about your career.
Michel Feaster: The other thing I’d say is if you’re a young product person, go work in a company that does great product management. I would say Microsoft actually has very good product managers. They call them program managers. But in some really good basic DNA, I think Amazon is okay but not great. There are probably other brands in the valley where go learn from a great product person. It’s not like a business where there are these books, and you can just go read 50 books and you pop out … There’s not a discipline or a degree. Quite often, what you’re seeking out is great product minds to learn from. I think the more product folks … I mean, obviously, go read all the books, go to Pragmatic. But a lot of your career trajectory is going to be shaped by the first couple bosses, and first couple cultures you join because those are the skills you’re going to learn for the rest of your career. I think it matters more than in any other jobs or functions.
Holly Hester-Reilly: Absolutely. Awesome. Thank you so much. We’ll definitely share this and be excited to see more of where Usermind goes and what you’re up to, and it’s been great. Thank you.
Michel Feaster: Awesome. I’m happy to do it, Holly. Obviously, you can tell I’m passionate about products.
Holly Hester-Reilly: You are. Yeah. That’s awesome to hear. I hope you enjoyed that conversation with Michel Feaster as much as I did. If you’d like to follow her online, you can find her on Twitter at Michel Feaster, M-I-C-H-E-L, F-E-A-S-T-E-R, or visit her company’s website, usermind.com. Enjoying this episode? Don’t forget to subscribe, so you don’t miss next week’s episode. I also encourage you to visit us at productsciencepodcast.com to sign up for more information and resources for me and our guests. If you love the show, a rating or review would be greatly appreciated. Thank you.