A Tale of Two Product Managers

Suzanne: Let's start back at UC Santa Barbara which is where you two met. Do you get asked this story a lot? Tell us about how you met.

Mallory: Dave was studying computer engineering as a grad student and I was studying communications in undergrad at Santa Barbara, UC Santa Barbara, and I was pretty frustrated because I didn't really see my life going down the marketing path or the advertising path which most of the people in my program were going. I really wanted to do something music and tech related and I didn't really know how to get into the industry.

I would talk about this frustration a lot with Dave and he was in computer engineering and thought he was going to go into more of the hardware space or aerospace or something.

Dave: Yeah. I was actively looking for jobs in defense contract companies and ...

Suzanne: I don't want to age you all but I just want to try and get a sense of the cultural landscape at this time. Where are we in the pre-post Uber life ...?

Mallory: This is pre-Uber, pre-Venmo, pre-all of the things that would've made college way better.

Dave: Yeah.

Mallory: But this was 2006?

Dave: Yeah.

Mallory: Seven?

Suzanne: Because advertising was kind of the holy grail path to pursue, I think, for a really long time so the very fact that you were sensing, you had some spidey sense that something was wrong, you were like a true visionary.

Mallory: I guess. It wasn't interesting to me.

Suzanne: Okay.

Mallory: I wanted to do something. I wanted to start my own business. My parents had their own business and I knew I wanted to do something in music because that was what I was passionate about and so Dave, he told me, "there's all these engineers that don't understand how to do sales or how to do business things. They created this program called Technology Management Program within the engineering department and I think I'm going to sign up. Sounds like something that you might be interested in, too."

He ended up recruiting me into that program and I went in my first day as a sophomore probably and I was one of the only women, one of the only non-engineers in the program. I loved it because I was studying communication and wanted to do more of a business economics focus and I felt like if I had that understanding, I could help the engineers be more business and sales oriented and they could help me be more technical and engineering focused so maybe I could be a bridge between sales and engineering. That was something that was really exciting to me at the time.

Suzanne: Right. You were sort of intuitively feeling into the gaps that the product managers fill all the time. An engineer speaks a certain type of language and then your job is to try and get inside of that brain, decode it and then re-communicate it to somebody who doesn't speak that language.

Mallory: Exactly.

Suzanne: Right. She speaks your language.

Dave: Yeah. Yeah and I would also add that UCSB had a bunch of these Capstone programs that different departments would participate in and I think that this was sort of the natural evolution of taking all this great technical work that's happening and combining it with some practical business education and making it more of a streamline process, from kids who have these cool ideas with these things they're studying and connecting them with potential investors and putting business plans around these things and pitching them. Because that was already happening with Capstone project that I was participating in and engineering and other departments had their own versions of so it was kind of the same process. There was even a TMP like Capstone thing that you would participate in. It was a year long.

Mallory: And these Capstone projects actually became businesses so many of them are successful, functioning businesses that are in operation today and one of our best friends actually works at one up in Santa Barbara called Bio IQ, which came out of the TMP Program.

Suzanne: It's almost an incubator.

Mallory: Exactly.

Suzanne: Wow. Is the program still around?

Mallory: Mm-hmm (affirmative). Yeah, absolutely. It's really cool.

Dave: Yeah. It's been boosted up to ... I's like an official certificate you can get now and so when we took it, it was more of just like ... There was a certificate but I don't know how official it was.

Mallory: It wasn't like a minor.

Suzanne: It was the MVP of the program.

Mallory: Right, exactly.

Suzanne: Okay.

Mallory: Yeah.

Suzanne: Amazing. Amazing. You're from southern California, Mallory?

Mallory: Mm-hmm (affirmative).

Suzanne: Dave, you're not from southern California. We're not going to hold that against you.

Dave: Yeah.

Suzanne: I'm not even from southern California so ...

Dave: I got here as fast as I could.

Suzanne: Soon as winter came, I was out here. I bring it up because you've both been here a long time. So you're up in Santa Barbara, you're participating in this kind of cutting edge technology education program which, by the way, there's still very few programs. This is kind of one of the things that comes up a lot from my perspective teaching at General Assembly is there's not a lot of programs being offered at the college or university level that can teach these concepts in a new way. The schools are, I think, maybe having a difficult time mobilizing. I digress. You're in Santa Barbara, you've been here a long time so you've seen LA tech, you've seen Uber come into existence. You've seen Venmo, you've seen the rest. Tell us a little bit about your experience watching that, just being part of it.

Mallory: Yeah, I was just thinking about how our experience has changed since going to school in 2006 and then working in Santa Barbara in the beginning of the tech scene there and then moving down to LA where it was starting to catch its stride a little bit and how we saw that transition over time. I was thinking a lot about how, when we got back from traveling and we were living on a couch and you were working at Start Engine you how that ...

Dave: Yeah. My personal evolution as a technologist in LA was kind of ... I was participating in a lot of "hack-a-thons" when I got here, just trying to parachute into a group of people, often times an accelerator or incubators, and just hack out some work that they needed to be done and then just get out of there. I feel like that style of development and prototyping and product design is becoming more and more accepted as a process that should be employed when people are trying to discover a new feature or whether this feature could be viable but we don't want to dump tens of thousands of dollars into it.

When I first came to LA that was like you participate in a hack-a-thon. You might get together with some people and just hash out an idea but I find myself, as I mature as a consultant, pitching that same process to clients that are asking me tough questions about how they should develop their product and how they should design it and how they can verify that that hypothesis they made is accurate.

I think being able to build that into the consulting practice and into the product development process is really making things more efficient and people can accept that they're going to maybe just throw this prototype away. Then it opens a lot of doors for them to move faster and not put so many resources into this thing that's just going to fail.

Suzanne: Yeah. Certainly, it's an approach that I subscribe to and we embrace at The Development Factory how we kind of talk to clients about conceiving product, testing product, not falling in love with the solution. One of the things that I've heard talking to other people who work in kind of outside consultancies is that it's still difficult to get clients comfortable with the idea of "not perfect". I think it's difficult for even people working on product teams. It's difficult for developers not to be perfect in their own right. I think it's difficult for designers.

A lot of these ideas about, "Let's just quickly hack together something to prove a piece and, if it works, we'll go back and we'll do it right and we'll fix it and we'll make it scalable," is easy in concept and harder in practice. Has that been your experience or do you just have the most open-minded clients and I need to poach some of them from you?

Mallory: Show me where they are when you find them because that's not a thing. You said something about falling in love with the solution that it just really resonates with me because I feel like that's half the battle as a product manager is helping people realize that they are in love with the solution and not a problem and really unpacking what the problem is that they're trying to solve with that solution.

Something recently that came to mind was a client came to me when I was working at Philosophie and they had a research grant. They want to find a way to connect young African American men who are HIV positive with other men who are HIV positive because once you are diagnosed, it's a very scary thing and, often times, what will happen is it's a traumatic experience. They will lose their jobs, they'll get kicked out of their house, they will move cities to just try and find themselves and usually end up relying on drugs or alcohol or something like this and it's just kind of this downward spiral. A lot of that is because they don't know anyone else who is gay, let alone HIV positive - and they said, "We want to build a community for people who are newly diagnosed, particularly African American men who are eighteen to thirty two." They wanted to build Grindr. That's what they saw as a way to build community and connect people and I could not get it out of their heads that Grindr wasn't the solution.

Suzanne: Now, did they actually come more or less and say, "Basically Grindr but with our logo on it," or they were describing what you understood was a product that's already in market serving a very different need?

Mallory: Literally they said, "We want to build something like Grindr. Everyone that we've talked to says that their favorite app is Grindr and Facebook."

Suzanne: Right.

Mallory: Instead of just saying, "No, that's a ridiculous idea," I designed a solution that looked a lot like Grindr and I put that up to a solution that looked a lot more like Slack, where it was a community chat interface. Then I designed a solution that was a lot more like a Quora or a Stack Overflow where it's like ask questions, get answers from a community kind of thing. These were just paper prototypes so I tested all three of those prototypes with the client in the room with the demographic that we were targeting and we got immediate feedback on each of those solutions and some of the things that we got on the Grindr solution were, "Oh my god, this is like Grindr. Why would I want to talk about being positive on Grindr, you know? This isn't a safe place for me. I feel like I'm going to be judged," and that sort of thing.

It wasn't until that I was able to do a lightweight version of that solution in front of the client and test it with the demographic that they would be like, "Oh my god. We shouldn't build Grindr," you know? "This is not going to solve our problem." We ended up building a totally hybrid version of a community Slack feature with we call it a "coach", where they get paired up with someone who is like a mentor kind of figure where they can ask some of those more challenging questions. It wasn't until we were able to disprove that solution that they could see past it. Something that I think is pretty fun to get people away from being married to the solution.

Suzanne: Right. I'm glad you bring up paper prototypes as well because when we talk in my class, certainly, we explore customer development. Steve Blank’s kind of concept of customer development, and, inevitably, somebody gets out in front of the material enough to say, "But what if people don't know what they want?", which is, of course, Henry Ford says, "If I asked them, they would've said faster horses." Prototyping can be a great way to go from, "I've done some exploratory conversations, I've got some interview data, I've got an indication that there's a real problem here but I'm still not sure that I know what the solution looks like or needs to look like," as in the case in the example that you described.

How effective is paper prototyping because there is a kind of silliness to it, right? It makes me wonder how much people are really connecting with the concepts versus not connecting because one thing to be like, "Here's a URL with some clickable screens and it's vaporware but it looks and functions a lot like the software product would." It's another to sort of put a stack of cutouts in front of someone and say, "Press this button. Now this button." What is that? Can you talk about that experience a bit?

Mallory: Yeah, absolutely. In the design thinking process, it starts with a paper prototype, even a napkin sketch. It doesn't really matter what it is. I had some card stock that I was using that were in the shape of a phone. I did that as the first round of user testing and we did that in three days. They started the project on Monday and by Wednesday we had three paper prototypes and, by the end of the week, Friday, we had a clickable InVision prototype.

It's a way to get to the higher fidelity version but I used it as a way to steer the conversation away from being married to a solution and I think that's really what it's good for is test all of the ideas. There should be thousands of ideas of what we should build and why but how do you test them in the lightest weight version possible? Sometimes it's experiments, sometimes it's paper prototypes. It's whatever it really calls for. That was just the one I used in that example.

Suzanne: You mentioned Philosophie and, for the benefit of our listeners, let me do a proper introduction. First of all, both of you come from two of LA's premier product consultancies. Mallory, you were with Philosophie. Dave, you were over at Pivotal Labs. Both companies I admire tremendously and then you left. We're going to talk about why you left. Before we talk about why you left, tell us about the experience of working there. First of all, they're very different in scale. How many people at Pivotal?

Dave: A thousand maybe? Tons. The numbers are just constantly growing because we're developing a product called Cloud Foundry which is a huge enterprise scale cloud platform that you can use to have your developers ... It's basically like Heroku but open source so, as more and more enterprises join that federation, the numbers just keep growing. New cities ... another hundred engineers here and there.

Suzanne: Right. There's almost an irony to the construct of Pivotal which is that it's this sort of lean product consultancy that is an enterprise.

Dave: Yeah.

Suzanne: How do they manage that?

Dave: Yeah. Pivotal, it's broken down into a number of different organizations. Pivotal Labs is the consulting arm of it and it will always be the consulting arm of it in that the structure hasn't changed and won't change, which is usually engaging with startups and sometimes enterprises. It's moving more towards enterprises because there's a bit of more synergy with Cloud Foundry.

Suzanne: Well, and startups don't really have money for long. That's the other problem. I can say it because ...

Dave: Yeah. They've been well-funded startups. Always. Those teams are usually handful of pivots, maybe like three pairs of pivots on average and an engagement will be like, I don't know, nine months on average. That's pretty reasonable to expect.

Suzanne: Is that coming in the door with a concept and leaving with multiple iterations of a product or is it coming in the door with a product that's not working and leaving with a model that's got traction?

Dave: Yeah. It's kind of a mix of all these things and, over time, we've ... I keep saying "we" because I just left like a month ago and I very much feel like that's still a part of my family but we have spun out design practices from our core engineering practices based on the needs of those clients who come in the door. Sometimes they have an idea and funding and they don't really want to spend the time to build an engineering culture into this startup that was just conceived and their investors want them to hit the ground running, they want to hit the ground running and they want to start on the right foot. They want to have good process in place with a team that knows how to execute that process.

Those cases, they come in with an idea and they leave with production software probably within a few iterations, maybe even the first. The whole goal with Pivotal is top quality through test-driven development and pair programming and continuous delivery. Nearly every code push should result in a production deploy and so you should be able to get that like week one.

Suzanne: Would you say the primary problem that they're solving or seeking to solve is the work that goes into, essentially, insourcing your own digital department? Certainly I know that people think you can just put two developers in a room and call it a digital department and it's not that.

Dave: Yeah.

Suzanne: Is that kind of the primary value proposition? It's, "We can get you into market before you can find three developers to hire and train yourself?"

Dave: Yeah. I definitely, as an engineer there, I was focusing on getting the product out there and then educating the clients on how to run this process that we're employing. And also helping them hire a team and putting all of that together and then sort of phasing ourselves out. It's a funny way to operate your business because you're sort of relieving yourself of a job in a way. But we've found that mostly that equals success for our clients and they speak highly of us to other potential clients or they just come back for other engagements when they need to start a new product line or revisit some product that's gone of the rails a little bit or whatever it is. Yeah, I'd say primarily execution and then after that it's just tons just tons of enablement and education for whoever is working with us.

Suzanne: Mallory, Philosophie is a much smaller situation. Tell us about the construct over there and how your experiences are similar or different?

Mallory: Yeah, just in size alone, Philosophie's based out of LA headquartered. Also has a large presence in New York and is just starting up in office in San Francisco. They're probably about 40 to 50, I'd say, in total. Most of that being in LA where I think there's like 25 or 30. The real difference between Philosophie and Pivotal is exactly like Dave said, we're going to help you scale up a team. We're going to build a product for you over the course of nine months and we're going to implement these really strong practices that are going to help you in the long run. Philosophie's really focused on the beginning of any product so if it's an enterprise client that wants to build out a new product, we would be working with mostly innovation teams within a larger enterprise. The people that we really love to work with are the startups, but as you said it's very expensive to hire consultancy from the get-go. Philosophie's kind of altered their offering over the years and what they're doing a lot of now are these really, really lightweight four to six week MVP's. So you come to us with an idea and we'll help you build something, test it, and ship it within four to six weeks. That means you get a fully staffed team of two engineers, a designer, and a product strategist. They'll work with you to bring that idea to life.

Suzanne: Yeah, I've always been fascinated about that model because one of the things I think is interesting about Philosophie is they put the price right on the website.

Mallory: Mm-hmm (affirmative)

Suzanne: They're like, this many dollars for that thing.

Mallory: Right.

Suzanne: Without getting too much into their special recipe of how they do things, is the subtext of that it's rooted in a number of hours and our ability to control the scope or is it we know we can deliver something functional at this price point so you just have to trust us that if we can't it’s because we're collectively not being as lean as we can be in approaching the build. Because scope creep is real.

Mallory: Oh, totally, totally. I think that that's a constant balance and that's a lot on the product strategist and a tech lead. I feel like they work together to say this is realistic, this isn't realistic and managing those expectations together. So you get really good at scoping. I would say that it's a mix between setting expectations of hey, this is the problem that you want to solve that happens in sales upfront. These are the features that you think are going to solve that problem. We're going to work with you in the first week to test that feature set as quickly as possible in a design sprint approach. Then, we're going to spend the rest of those three weeks building out the features that we've validated. And setting you up for a process to track that over time.

Suzanne: Just to pit you two against each other in respective affinities for these companies, it raises the question at least for me of is there an inevitable point where scale hurts you? That even if ... like at Pivotal, deeply, deeply rooted into your philosophy are these sort of iterative, agile, lean thinking processes across everything, across strategy, across development, that inevitably once you have a company with four or five hundred people ... Google is the same, they're an innovative company but they're not small, versus an organization like Philosophie with 20, 30 people, they're scrappy and resourceful. Is it really hard to be lean when you're big?

Dave: Yeah, I think that I've seen a lot of enterprise struggling with product development. They have these huge products that are super successful and they're basically bankrolling all of their development, all of their hiring, all of their activities for years. All of a sudden ... and especially as time goes on that runway shortens more and more. They're not getting the same ... they're predicting that that runway's going to run out basically and they're like how do we use our own data, use our own teams to develop new products. But they're so cemented in this system that is just facilitating this sort of status quo product development that they've got going like bug fixes and minor feature updates.

There's a lot of enterprises that are reaching out to these consultancies and trying to do this startup culture ... build a startup culture from within the company which I think is really great because, that company is sort of a highly targeted VC firm in some ways where they have the opportunity to hear ideas and put money into small teams to innovate from within. At Pivotal, there's a huge offering for building a startup culture with an enterprise. They'll literally just ship over all the interested members of their company to start a labs for that enterprise where they would just be like in the Pivotal Lab's office doing everything the same as Pivotal process is employing. They're basically just pivots. I think it's interesting to see enterprises moving in that direction because I don't think they were doing that before but I feel like they're seeing that that is they way to stay relevant. There's a book, Running Lean, that talks a lot about this.

Suzanne: Scaling Lean is the counterpart to it. So you're talking about Ash Maurya's Running Lean.

Dave: Yeah.

Suzanne: I think this is exactly the point is, is scaling lean possible or is there a point ... Certainly I can understand this idea that legacy enterprise companies are looking for help from the startup community so to speak, but I'm even just talking about as a consultancy or an innovation team if you're too big can you be ...

Dave: I always see it as, as the team grows too big it is obvious that there's breakdown somewhere and then you break those teams apart and you separate those into their main concerns and then run those like a super lean startup group. If you can keep doing that it kind of builds a hierarchy into it but I think that's the only way because, I don't know if you've ever worked in a company where there's 10 people or 12 people or something and everyone is really intimate with each other. Everyone trusts each other to do their job and to help pull extra weight when they need to, or whatever it is. Then all of a sudden, there's some need to scale out and you're at 20 or 30 people and things are just ... they don't run the same. You have all these weird issues bubble up. There's communication issues, there's ... I think that's the scaling issue there. You look there and you say okay, well how can we break down this group into smaller teams that can actually run more efficiently in isolation and then have some kind of construct that can communicate across those teams.

Mallory: Yeah, I think scaling's hard at a consultancy or a product company. It's definitely its own beast. Many people say that the people who start a company are not the people that scale a company, right? They're two different types of people.

Suzanne: Right.

Mallory: But I completely agree. I think that what Philosophie and Pivotal do really well is they avoid that issue by just having really small project teams and treating those project teams independently. Like Dave said, as soon as the project ends then some people go join another project and then another project team forms and you're constantly working within your company culture and getting a feel for different contributors and their style.

Dave: Yeah, those teams have a lot of opportunity to do what they need to, self-direct their efforts.

Mallory: Exactly.

Suzanne: Let's talk about both of you in your respective rolls there had the responsibility of helping the client own the project at the end. I think this is another important part about outsourcing product design and product development is at some point the party's over, the last check has been written, and the client has a product that they've given birth to, and they have to now stand up a product management process. They have to be thinking like a product ... Do they succeed typically?

Mallory: It's always challenging, right? The best thing that we can do as people helping them on their project as consultants, is setting them up for success. So whether that is running hiring workshops and helping them find a technical co-founder or onboarding a new engineer or helping them find a UX designer. Maybe that's all that they need is that their ... they really need to dive deeper into the research because they have something that they built that works but they need to understand more about their users. It's like identifying whatever the project is, whatever the client's needs are, and helping them bring on the pieces that they can't already fill themselves. I would say that it's pretty rare that I leave a project and I didn't help them hire someone else. Because if you were just one founder and you're like okay, now you have a product, go do it. It's really hard to do things by yourself. Helping them create a structure and a team around their idea is the best thing that we can do as consultants.

Creating a product practice is the kind of the question that you asked? I feel like the way I would answer that is more with implementing lean thinking. You have this idea, should we go spend 30,000 dollars to build it or are there other lightweight things that you could do to test that idea? That's really what they should be able to walk away with at the end of the day is being like oh, what are my assumptions here? How could I test this in an easier way.

Suzanne: Right.

Mallory: That's when I know I've succeeded as a product manager.

Suzanne: I just came out of a product management bootcamp that I was teaching this weekend. Of course, everyone comes and expects that in four hours the they're going to learn everything about scrum, everything about product design, everything about everything. The thing that I spend the most amount of time on is validated learning. I would echo that sentiment, that it is the core product management methodology. Everything else can be learned, everything else can be augmented as you get other skills on your team but embracing that reducing waste idea. I struggle with this. Even internally where we're thinking about product ideas all the time. Even 100 PM started too big. Now I look back and I think no, I could have done this and I could have done this. It's just the more capable you are of conceiving and building solutions, the more dangerous you actually become to your own thinking because you tend to go ... Dave, you could just code it. So why don't I just quickly code it and yeah, you could quickly code it but that's not the same as actually deciding if it's something worth coding. Let's talk about why you left Philosophie and Pivotal. You have a new venture. You're romantic partners and now you're partners in business. Are you sure this is a good idea? Too soon to tell.

Dave: Yeah.

Mallory: I think that to your last point, you got to just throw a dart at the board and try, you know. And hope that it works.

Suzanne: We're going to do a where are they now episode of this a year from now and see what happens.

Mallory: Then iterate from there, right? That's where we're at right now is yeah, we started our own business and we did that because we've been consulting for three years at these different shops and before that we were both a part of small startup teams. We've seen it from both of those sides and now we want to take the reigns and have a little bit more control over the projects that we take, the timelines that we work on, and the problems that we solve. Dave is an amazing engineer and I love doing design and product so were like let's just do the damn thing.

Suzanne: It's called Creative Brains. Help us to understand hiring Creative Brains. If I'm sitting around and I'm thinking I need a great product consulting team. Why you?

Dave: I think for a lot of the same reasons that you might hire Pivotal and Philosophie. Except for it's going to be more of a close ... a more intimate experience. Obviously, we're going to be catering more to your needs as much as we can. That's what's one of the things that'll differentiate us. For clients who go to Pivotal and Philosophie they know exactly what their going to get out of Pivotal and Philosophie.

Maybe, there's other clients out there who are like well, we have this other organizational concern scaling our teams or maybe trying to create a sort of startup culture from within our big enterprise. We don't really know how that fits with Pivotal. We're not ready to kick off a bunch of projects. We're just looking to better understand our organism. For things like that, they could definitely come to us.

We've seen successful projects in huge scale teams and small scale teams varying maturities of the product. We'll be able to bring that experience to those clients. As well as, when the time is right do a more traditional product development engagement where we can execute as a balanced team. We represent the full stack of client facing concerns to engineering concerns with the two of us. I think the difference is mainly that more concierge experience for clients. It'll be a very pointed solution for what they need at the time.

Mallory: I'd also say that Dave and I don't really have an interest in growing this thing that big. It's very much just ... We love working on projects that change the world. We love working on projects together and for better or for worse live products. Eat, breathe, sleep these products.

Dave: Yeah. What we've found was we're ...

Suzanne: Looking around there's post-its and work flows everywhere. I can't tell if it's just for fun or these are actual ...

Dave: It's all kind of melted together. We're like are we doing a retrospective for our relationship right now? What exactly ...

Suzanne: I had a guest on the show, you joke, but talked about doing retrospectives. He said his wife would do a retrospective with him at the end of each week to let him know what he did well and what he could improve on so it's not that far fetched actually.

Dave: We're literally doing it. It's all kind of like melted together at this point which is cool. I think one of the obvious points for me to just say yes and try this out was that we would just talk about this stuff after work anyway. We'd both get home and we would say hey, I have this. This is what I'm working on this week. This is the challenge I'm working on. Can you help me think through it? We pretty much knew main challenges that we were facing at our respective office jobs that was ... why not have us just talking about the solution for this project we're working on together? Wouldn't that be great? We're going to talk about it anyway.

Mallory: Yeah, just giving each other a new lens to look at that problem through, you know? And always supporting each other in that. Creative Brains came out of those after hours conversations where we were already doing it. I think the other thing that really differentiates us is when you go to these consultancies, they charge this very expensive rate. You don't know if you're getting a senior person or a junior person.

Suzanne: Right.

Mallory: With us you're getting only senior people every time. You know what you're paying for.

Suzanne: Right. I'm glad that you brought up the point about we're not looking to grow. Because this is a thing I think about a lot. There's a tremendous amount of pressure on businesses to scale and certainly if you're looking for VC money, then they're looking for scalable huge disruption businesses. But it is perfectly admirable, whether it's a service business, whether it's a product business to say look, there's a niche. It's a small problem. I know that it's not going to cross the chasm into a majority solution and I'm perfectly happy with that because I want to work a very ... part of my goals are just work less, surf more or whatever the thing may be. That's inspirational to me. I wish I knew that or I thought that way eight and a half years ago. My path might've looked very differently but I can attest to that certainly going through year over year, growing, growing, growing without ever stopping to say are we happy? Do we want this? More employees, more responsibilities, and definitely at The Development Factory we've refactored a few times based on that understanding.

Mallory: Yeah, absolutely. I think that's just what we saw is we always have the most fun when we're working on a really small team with people that we really love and trust and admire. We think they're the smartest people. That's how we want to be selective in the clients that we take and the few coworkers that we decide to bring on.

Suzanne: When a client, whether it's an enterprise client or not an enterprise client. When a client thinks they need a product or want a product, right, what do you think is that ... Where does that insight strike and or who does it strike with? Is it always the CEO who has a great idea? Is it a single developer within an organization that's been running a macro for three years and thinks it could be something more? I'm speaking about your clients that come to you. What do you see as being their reason for wanting to build something?

Mallory: It really depends. Like Dave said, the people that we're talking to right now and the projects that we have coming up in the next six weeks are more process consulting. That's coming from c-level people who are like, I have no idea what my team is doing and I need to have better metrics around their effectiveness as engineers and our strides towards our goal. Being able to communicate up. That's one area that we're going to be focusing on and that came from c-level. I think when people come to us from ... we want to build a product. Where that idea came from? I would say it's mostly leaders at this point that are yeah, like CEO's and co-founders ...

Dave: Yeah, I would be surprised if there was a developer who like bubbled up some interesting idea and it got all the way to us. That would be very surprising.

Mallory: Yeah.

Suzanne: You're just out hunting c-level executives then when ... You're not doing this interview here with me ... Is that the ...

Dave: Some people that we're talking to ...

Suzanne: You have to do the pointy end of the business now. You have to do the selling and all of the other stuff.

Dave: If the business that we're talking to is of a certain scale, then there engineering department is buried between tons of layers of hierarchy. There's a really small chance that any engineer doing something is going to convince his boss's boss to reach out to a consulting shop and develop some product idea. I'm not going to say this doesn't happen but I haven't seen it and I wouldn't expect to see it. I would love to see it but I wouldn't expect to see it.

Mallory: I feel like other product managers at enterprise companies have access to these resources too. It's really about who has the money. Who makes the budget decision, right? Those are the people that we're talking to because obvious.

Dave: The flip side of the highly scaled organization that we'd be talking to is a small organization that we're talking to which is a startup which has like three people on it. Sure, the person we're talking to is a founder, CEO, or whatever but they're also the developer so it's like ...

Mallory: Yeah.

Suzanne: If you subscribe to the idea of sales as being about problem finding and the people who are most ready to ... This is true in product. Those early adopters are the people who have tried to envision a solution themselves. Maybe even put money toward it. I don't think there's any business on the planet that hasn't thought about how could we make more money? Whether it's a real problem or just sort of a desire versus being connected with your own organizational dysfunction. I think the reason that kind of internal tool idea doesn't come to the surface as much is because most of the time people are disconnected from how unhealthy their own businesses are running. They're not thinking about I need to solve this problem. They don't know it's a problem. Fine, we digress.

All right, we do a little segment here on the show called Get the Job, Learn the Job, Love the Job. It's really in service of our listeners who are out there wanting to get into the product management space. Maybe actively working in product management and just looking for encouraging words. I want to offer a little skew here because one thing I thought about, Mallory, as we were talking is product consultancies are like the new agency. As organizations are understanding more and more the importance of owning the data and really tracking it, outsourcing to an advertising agency, at least the scale of work that people use to outsource, is going away because I think they realize no, advertising is back to where it belongs which just sort of one node in the marketing constellation. Product consultancies are the new agencies, which means there may be a number of people out there listening going should I apply as a product manager at a product company, or should I go and work at Pivotal, or Philosophie, or The Development Factory, or Creative Brains. What advice would you offer somebody maybe staring down that fork in the road, specifically?

Mallory: If you haven't worked at a startup or in a bigger product company, I wouldn't recommend consulting. I think the best consultants have failed a couple times before they go and advise people on how to do the best job. That's from me personally. If I was a startup going to a consultancy, I wouldn't want a newbie out of college telling me what to do. That's just me.

Dave: I could argue it totally different.

Suzanne: Argue, let's just not make it so harmonious. People think you two just get along all the time.

Mallory: It's just perfect all the time.

Dave: I really like the structure that big consultancies impose on projects and I feel like with a really inexperienced product person or engineer, as long as they're with another mentor type that can make sure they're not doing any really bad things, they can ramp up really fast and get exposure to a lot of things very quickly. Not only for technology wise, but product wise and business vertical wise, business model wise. I think there's big opportunity. If you're fresh out of college and you can get a job at one of these companies, you can pretty much learn cutting edge process for any startup that you subsequently join. If it's the process and the technology that you're really interested in then I think that it's no question you should try and join a consulting firm that can handle more of the educational upbringing for you. If you have passion about whatever product that's going to trump whatever consulting gig you're going to get. Because that product you're going to be thinking about all the time and you're going to put in more hours. Just cultivate more passion.

Mallory: I will add on to my previous [inaudible 00:56:45] I think if you're an engineer or a designer and you go work for a consultancy, that's the freaking best. If you are a product manager going to work for a consultancy based on my experience working on these small teams, I didn't get a mentor a lot of the time so I was happy that I had my past startup experience to rely on to make decisions off of. Whereas I feel if I was flying blind it wouldn't be helpful for my team.

Dave: My perspective is definitely from an engineering perspective. I can see that. Often we don't have pair PM's.

Mallory: That doesn't happen.

Dave: At Pivotal, there's exclusively pair programming so you're never going to get an engineer just solo so there's more opportunity for that.

Suzanne: Right. Well, the trade off also that I'm hearing is you're going to get to touch a lot of different projects, right?

Dave: Mm-hmm (affirmative)

Suzanne: For better and for worse to your point, Mallory. But if you go and work inside of a consultancy, whether you're coming in as a designer, as an engineer, or even as a PM, you're going to touch a lot of products but the trade off is you're only going to touch them at a very specific point in the product like cycle. Even when you were describing earlier that Philosophie is a great fit if you're just looking to go into market. If you're just exploring problem-solution fit, product-market fit. One of the things that doesn't get a light shone on it as much is how do you steer a product that's in the maturity phase of the product life cycle, right? Because the strategy and the tactics to hold a market position that you've worked very hard to build up and not lose it to the next new disruptor startup is a very different type of mindset than just figuring out if you can create a great product, bring it into market, and capture a few clients.

Another one of the reasons this show exists is precisely because I'm aware, even as an instructor ... I've worked on 60 to 80 products a year for almost a decade. That's a lot of different experiences to draw upon, and yet I've never been a product manager at an enterprise level organization. We had guests on the show talk about doing road mapping, thinking about decisions five years out and I'm thinking I've never even made a personal decision thinking five years out, let alone a product. That's probably the other part is do you want to experience what it's like moving from growth to maturity or trying to rejuvenate a product perhaps that's in decline and being tasked with how can we give new life to this or break it apart and sell it or whatever. Just different concerns I suppose.

Mallory: Is your question around ...

Suzanne: I don't know that it was a question. It's really just more of a reflection of the benefits of going and working at a consultancy is touching a lot over a shorter period of time and the trade off is not getting enough opportunity to see ... Because you're starting to see now even here in LA companies go down that people never thought were going to go down, these startup darlings from a couple years ago. That's part of the piece, right? It's one thing to get some early traction. To get picked up in TechCrunch, to get a big life from some early PR, and some good VC funding. It's another thing to actually be an Airbnb or a MailChimp. These products that really came along… Basecamp that are still holding down space all of these years later. It's just a contemplation. You've just got me thinking is all.

Mallory: Yeah, awesome.

Suzanne: All right. Hardest thing about the space to learn, to discover about yourself, biggest failures, anything that reminds us that it sounds really cool but it isn't always easy?

Dave: You have to constantly be learning new things. For technologists, it's constantly changing so you basically have to like ... You can come in at any point and learn some new technology and be relevant and that's great. But if you're also not learning while you're in it you can become irrelevant really quickly and so you have to babysit your education.

Suzanne: Yeah. There's probably a certain amount of managing that that I think is important because no one is going to come along and say oh hey Dave, just be mindful because a lot of people are moving to Node.js and if that's not your background ... you have to be paying attention to where the market is going and not becoming irrelevant.

Dave: Yeah. If you get a project that lasts a year or more and it's on a technology that's already very mature you might not ever get to Node.js. You might not ever do mobile. It might be something you have to do in your spare time which is hard to find.

Suzanne: Right.

Mallory: Yeah. To piggyback off of that, the thing to watch out for is that the type of person that's going to do well in either of these roles is, and I mean like a tech lead or a product lead, is you have to have the insatiable attitude towards learning. Where you're just constantly trying to find new information. I don't just mean what's the new “lean startup?” what's the new hot trend or catchy phrase? I don't understand enough about engineering to help my team so I'm going to go learn to code or I'm going to go spend time with you and sit down with you and ask you questions while you're coding so that I can get a sense of how this repo is laid out. Then I'm going to go sit next with design and watch them and ask them questions and help them.

I think that cross-functional pairing is something that's really helped me get insight into how all the different departments work together and I'm just talking about engineering, design, and product because that's what I did at Philosophie. But if I were at a bigger company I would do the same with marketing and I would do the same with the analytics and data team and all of the different teams to see. Go on trips with the sales team and sit in those conversations. Those are so informative because I think as a product manager you're responsible for understanding every part of the business and doing whatever needs to get done to make it successful. I think for the PM role it's just constantly wanting to learn and understand new parts of the business.

Suzanne: I think it's absolutely right, although I did get this hilarious visual of designers and developers running when they would see you in the hall because they're like oh my god, Mallory wants to come and sit by my desk and watch me layout this webpage in Photoshop for the next eight hours. How can I shake her?

Mallory: I think that that is totally newer engineers. They get really afraid and intimidated because they feel like they have to like justify that they're doing something that's worth your time kind of thing. You should foster a culture of pairing where ... Imagine all the questions that an engineer or designer has throughout the day and if I was just sitting there we could tackle those things in half the amount of time together. I don't always have the time to sit there but I try to make myself available as much as possible so that we can have those pairing sessions and crank things out super fast.

Suzanne: To bring it back to the ad industry one last time, perhaps it's like the pairing of the art director and the copywriter. That was such a quintessential ... I understand that you bring a very specific vision and I bring a very specific vision and together through our different skill sets and then maybe just where they started to fall behind was not inviting the technologist into the conversation so to speak.

Mallory: But instead of just the PM, having the client sit there too. Taking it back to consulting, right? Having them play that role of ... and not being hovering micromanage-y but I'm working with you, we're doing this together. And how can you encourage the client that that's okay to do that?

Suzanne: I think you have to insist on it. For me now you talk about taking on the right kinds of projects or clients. I don't want to work with clients who just simply want to dump the work on my lap. Certainly not ones who also are asking me to do some free work in exchange for equity because I'm thinking if i'm doing ... You need to be connected with whether or not this thing is going to work. You need to be connected with this process. You cannot just rely on me to conduct the interviews and then come back and say yeah, it's good, let's proceed. I want you to be in it with me. But I think people want to do it, people want to create. It is a fun ... which leads me to the last thing, right? What's the ... why do you love this job so much? What's that thing for either of you, both of you?

Dave: Working with clients is always really exciting when you can have little breakthroughs and you see eye to eye and you share a vision and something just clicks. You kind of get these moments that are sprinkled around the engagement. That's always super cool and whenever you get to enable somebody to see a vision come to reality that's really inspiring.

Mallory: I think why I really love this job and so happy that Dave and I are doing our own thing now is we have a ton of interests in a ton of different industries. Dave's always been very passionate about biology. We are both very passionate about sustainability and right now gardening. We're also very interested in music and all these things and having our own consultancy allows us to go after those industries and work on projects that are focused on the thing that gets us most excited about that time in that industry that we really are excited to learn about. It really allows us the flexibility to go after them.

Suzanne: I'm glad to hear you bring up music. That it hasn't died over the years.

Mallory: No.

Suzanne: Any recommended resources that either of you want to throw onto our ever-growing resource list at 100 PM? Books, podcasts, articles, blogs, just anything ... It doesn't have to be product specific but just things that you think make you better thinkers, better doers? Or it could be science fiction?

Mallory: So many books. We read a lot.

Dave: Yeah.

Mallory: The one that we both just finished reading which I am obsessed with right now, it's called Radical Focus. It's about creating OKR's so I can send you that link. It's Christina Wodtke. That's a really, really helpful way of looking at the big vision and working backwards to create little milestones that get you to that vision. So objectives and key results, I really cannot say enough good things about them used by Google, Intel, all of the major players. The other one that I love is called The Mom Test and I think that anyone who's working on a product team, whether you're an engineer, a designer, or product manager should read this book and it's all about the art of asking good questions and unpacking questions, answers ... asking good questions so that you can get answers that you can unpack about whether something is validated or invalidated. So open ended questions, non-leading questions, all of that stuff. The reason it's called The Mom Test is because you can ask questions in a way about a business idea that even your mom can't lie to you about.

Suzanne: Right.

Mallory: It's one of my favorite ones.

Suzanne: Great recommends. Now I have something to do when I go home later

Mallory: Yeah. They're both really short books so you can finish them in a couple days.

Dave: I think I mentioned earlier Running Lean. That book really struck a cord with me when I read it. I was in an engagement that I kept finding the only way to effectively communicate with my client was through data and having the data speak for the concerns that I was bringing up and letting them come the conclusions that they would. That book, for some reason it was the timing and it really helped me see how I could think about presenting metrics and data for their product and their business in a way that it would help me convince them that they needed to do more user interviews. They needed to take a hard look at the data everyday to see if the health of their goal was being pursued properly. I really enjoyed that book and it's a super easy read.

Suzanne: Awesome. What about a personal mantra or quote that you love by? This is my quintessential your life on the side of a mug inspiring thousands of others when you've gone? It doesn't have to be your quote but just something that inspires you to do what you do or live the way that you live?

Mallory: For me, it's "don't cling to comfort and everything will be comfortable". I think that really speaks to the whole addiction to learning and trying out new industries and that sort of thing. It's something that Dave and I have always related on. Never getting too comfortable in any one city or any one industry.

Dave: Yeah. Mine is "fear is the mind killer". I just can't get that mantra out of my head because it seems to work in every situation.

Suzanne: What does it mean?

Dave: Yeah. What it means to me is basically, any apprehension or anxiety around a situation that I'm in is based on fear and that can be confronted and worked through as opposed to avoided and reinforced. It's a quote from Dune where the main character's ... He's got this spiritual teacher who's his mother and she gives him this long mantra to follow whenever he's confronted with fear in his own life. He speaks this mantra to himself and it basically is fear is the mind killer. The only way to overcome the fear is to let it pass through you and you'll see that the fear is gone and you remain. Anyway, when I read this it just never left me and I really love that quote.

Suzanne: That's awesome. Both of you have taken the ultimate leap of faith which was going out and starting your own business. I first wish you so much success and I think you're definitely living testament to your own mantras about not being afraid and going for it so that's awesome. Thank you so much for being on the show.

Dave: Thank you.

Mallory: Thank you.