“Innovate or die.” It’s one of many famous quotes attributed to management guru Peter Drucker. 3M, Apple, and many others serve as examples of innovation rescuing companies from the brink of extinction. But innovation shouldn’t just be a lifeline to a failing venture. It should be part of a company’s DNA that inspires and nurtures a culture and environment for creating products, processes, and business models that deliver new value.
Unfortunately, innovation too often gets swallowed by ongoing efforts to maintain existing product value. How do product leaders protect innovation, and why is innovation something that needs protecting? Who is responsible for innovation – if everyone is, no one is. These are some of the challenges we probe in our discussions with innovation leaders.
This week we sat down with Brian Lindauer, EVP Product and Engineering at Mavrck. Brian runs both engineering and product at Mavrck, which he says some find controversial but he finds interesting and important to satisfying his organizations “need for speed.” This cross-functionality on the product team allows them to move very fast and resolve conflicts efficiently. Brian started in engineering before becoming a product manager, which helps him understand where an engineer is coming from, where a product manager is coming from, or a designer’s coming from. In this interview, Brian also discusses:
- Balancing being Mavrck and MacGyver.
- Implementing lower case aGILE and how constantly iterating means more people get to be a participant in the process
- Finding the right people for his team and the Mavrck promoter score
Listen to the Show
Richard: But I would like you to start with a description of what your day is like. What does it mean to be VP of product? What does that look like to you?
Brian: Sure. Just a little background. I work for Mavrck. We are an A-round startup company, so have that picture in your head. It was 30 people in the company, and my team is 10 people. I could talk a little bit about that, I can also talk about working at PTC. I worked there for 15 years. Various product roles, and that was a stark contrast to where I am today from a, how big a company is, scale and so forth. So I got some perspectives on building products in a behemoth and building products in a startup. You can guide me however you’d like.
Richard: Why don’t we start from the startup. Tell us a little bit about your day-to-day right now.
Brian: A day here. Let’s see. I come in, warm the team up a little bit, a little banter, see where everyone’s at. I got two product managers working for me, and I also run the engineering team, which I like. I actually sought out an opportunity where I could lead the engineers and the product team at the same time. Which is a little controversial, depending on who you’re talking to, but I really appreciate it.
Richard: Tell us, why don’t we go deeper into that. Why is that interesting to you?
Brian: I think, in contrast to where I came from at PTC, it, in my mind, allows us to move very fast. At the end of the day, I can resolve conflicts that span across those two groups very quickly. And I realize that maybe I can do that, my background might enable that situation a good deal. I came from the engineering side and then became a product manager, so I have collected those skills over time, and, let’s say, deep empathy for all participants.
So I can always understand where an engineer is coming from, where a product manager is coming from, where a user experience person might be coming from, or a designer’s coming from and I think that really helps make every conversation we have as efficient as possible. Because at the end of the day, everyone’s not gonna agree, necessarily, on big things or small things, but I can at least make sure everyone’s point of view is heard and understood, and that we don’t linger too long. I’m not perfect at that, but I think in a company this small, and having that perspective, and also that control, I suppose, allows us to make things move forward relatively quickly. And that’s good.
Richard: There’s an advantage to having cross functionality on your team.
Brian: Yeah. I’m not sure you could pull it off in a large company, because the reporting lines in those scale situation would require a little more division between groups. But in a startup it works really well, and I think I was seeking that out when I came to Mavrck. Because we can move super fast, make quick decisions, and that’s what a day looks like here. We talk about lots of stuff. We do AGILE, but we always joke that it’s lower case AGILE. Little bit more by the seat of our pants. It’s definitely not SCRUM. We don’t commit to sprints. We’re very reactive day-to-day. We have a rough plan when we start our two weeks and then as the week goes on we’ll make ad-hoc decisions based on re-prioritizations day-to-day.
Richard: As you deal with the day-to-day prioritizations, how are you balancing that with the need to actually create something innovative? You’re a new startup breaking ground here. What’s the balance like?
Brian: I’d say it’s tricky. We’ve definitely spend time building the wrong things over the past couple years. You can’t feel bad about that. You can always look back and wish you hadn’t done it, but we know we’re gonna do that from time to time. We’re Mavrck, we’re “Top Gun” themed, so need for speed, velocity, is a big part of our ethos here. We have a quote on the wall from Mario Andretti, If everything seems under control you’re not going fast enough. I think that sums up our process fairly well here. What it’s allowed us to do is test stuff out, see if it works, make adjustments. That allows you to be innovative, because you can take risks. That may be a little bit more of a startup characteristic. I’m sure there’s ways to work that into a larger scale product development, but startups have that somewhat unique opportunity to do those things.
Richard: In terms of finding the right people to do that kind of work at the stage you’re at, you came in, it sounds like there was already a team in place. Is that true? Or did you build it?
Brian: The company had been founded by the year previously. They put out a MVP product already. It was somewhere between real product and prototype. More prototype than I was expecting when I came in, so it was a little bit of shock. Yeah there’s some engineers here. Our assumptions around what our product should be, and what our value props were, were established but not firm by any means. We’ve pivoted a couple times. I don’t think this is unique, but owning a lot of startups are trying to foster, or invent, or transform a market, and what we do here is influencer marketing. Which three years ago was very much a white space opportunity in marketing automation and today it’s becoming more of a known quantity. What was hypothesis three years ago, some of those hypotheses have been confirmed around what the value props are for our customers, what people want, what people don’t want. We’re getting a little bit more focused. We’re definitely still trying new things. We’re ahead of our customers in lots of ways in that we’re guessing what will be valuable a little bit more, because the customers don’t know what they want around influencer marketing, versus trying to solve a known problem.
So maybe every hypothesis that we consider around what would be a good solution or offering for this space is innovative in its own. And then we build it and we see if it works. It’s the balance of interviewing customers ahead of time, realizing that they don’t really know what they want yet, getting feedback as we start developing product to validate what we’re doing, and then ultimately seeing if it is in fact driving value when we roll it out there. We’ve been fortunate in having some good early adopters. Relatively large brands, sophisticated brands, try out our software to do influencer marketing, so we get relatively sophisticated feedback about what’s good, what’s bad, what we should change. It’s been good.
Richard: It’s been said that the best thing you get from your customers, when you go to them for information, is better understanding of what the problem is, but not a really good understanding of what the solution is. Do you agree with that?
Brian: I think that’s true, quite often. For sure. One of the great examples of that is always Excel. I have a personal vendetta against Excel. A lot of the products I’ve worked on in the past have been business automation type products where the old process was Excel based and now you’re trying to create a solution that fosters collaborative needs and scale and all these things. Time and time again the customer’s saying, Try and do X. Give me fee lookup. That’s the antithesis of all software I’ve ever built is fee lookup.
I don’t think they actually know what the product is they want. You just have to look and see what they’re attempting to do, then look at the ways they’re attempting to do it today, and imagine what the better solution would be. Sometimes it’s hard for them to even to validate that the solution is a good one until they’ve used it. I’ve also worked a lot on workflow related products. Time and time again, one thing I’ve learned is that if you’re implementing new software that’s gonna execute a workflow, don’t listen to the workflow that they’re asking for. The customer will tell you, I want this, I want this, I need this, and oh we need to go do that, and then when you give them that product with that workflow, it’s the absolute worst thing. And they don’t want it and they want something new. I’m sure there’s other product types that are like that, where what the customer’s imagining they want is far from the thing they actually want once you give them, one you transform the way they do something.
I used to work at Caterpillar. This wonderful woman there, she used to love the term don’t pave the cow paths.
Richard: Sorry, don’t pave the cow paths?
Brian: Yeah. Don’t pave the cow paths. If you go into a rural zone, sounds like you have an english accent, you probably-
Richard: I’m from South Africa, so I totally get that.
Brian: A lot of the roads in England, my wife is from Liverpool, are essentially paved cow paths. It’s what they used to run their farm animals through and they said, Well we might as well make that a road, but that doesn’t mean it’s the best road you can make.
Richard: That’s right. Downtown Boston looks like that a little bit, too.
Brian: Yeah, exactly. You go out to Michigan where I grew up and it’s a grid system, which is much more efficient, but it’s not as quaint. Anyway, a lot of customers, what they’re asking you to do is pave their cow paths and that’s not always the best thing to do. Might be the- Go ahead.
Richard: Is there any value in releasing a product that isn’t quite finished yet, or doesn’t quite have all the polish it needs, and let the customers fiddle with it or play with it, and give feedback over time, it makes them feel like they’re a part of that creation process? Or is that just disruptive?
Brian: I think it’s a great thing to do, in particular if you’re working in a new space. You can’t wait for feedback. I think that’s pretty established mentality. You gotta iterate. The products that give you the best chance to iterate are probably the ones that end up being the most successful. Let’s say you’re trying to put a product into a mission critical situation where you have no allowance for any kind of issue or incorrectness. Maybe it’s not the perfect value product when you ship it, but it has to be the perfect quality product when you ship it. Those are dangerous situations because you’re saying, I can’t put this out into my user’s hands until it’s perfect from a quality standpoint. It gives you very little opportunity to figure out if it’s the right value product.
I think we’ve been fortunate here, and maybe this is depending on what sort of company you are, startups can a little more allowance to put some product out, set expectations with a customer, work more closely with them because you’re only supporting a smaller set of customers. Communicate that, Hey, this thing’s coming out and there’s a few things that aren’t gonna work great, but that’s okay because we want your feedback and we’re gonna quickly make adjustments in the next month or so. That’s great. Any time you can do that you wanna do it. That has definitely been true for a lot of the products I’ve worked on over the past 15 years or so. They’re gonna end up being pretty good products at the end of the day as a result. Fail fast, the cliches around that, I think they’re true. They are true.
Richard: Although probably learn fast, that’s the goal, as opposed to just failing.
Brian: Fail to learn, right?
Richard: Yeah. Tell us a little bit about, and this might reflect a little bit on your larger company experience, but there is a definite situation where product leaders find themselves in, and that is you’re between the layers of the executives and the folks that you’re managing. And there’s different expectations sometimes about what needs to be done. Executives might have a goal in mind, a bigger strategy in mind, and your team is probably focused on things that are slightly more tactical. Tell us about managing up for your current and past situations.
Brian: At my last job, I came in through an acquisition. We were a small company, about 15 people, got bought, had some autonomy for a while, worked really well. That was perfect because we had small company feel and big company stability. Did that for a few years and then moved out of that product and got thrown on their biggest product. Moved around a little bit more and got promoted and ended up with a title of something like SVP of strategy within a business unit for a product line. It was really product strategy and not business strategy. At that point, anything that felt fast previously was gone. Speed was out the window, because now I was working on a portfolio of products all around a certain domain area, and that portfolio was one of like five portfolios in the company. Corporate level planning was pulling levers across, should we put more money into this portfolio or that portfolio or this portfolio, and we spent a lot of time lobbying for the portfolio you were working on like, “Hey look at how much of a business case around this”, and “Here’s our updated messaging”, and “We’ve got these customers on board to go build these new products, and we’re gonna take down this new business proposition.” We actually got a lot of excitement around what we were doing. For a while we’re the number one growth engine that the company was considering.
Spent a year pulling all that together and got ready to go build these big things and we’re all super excited, and then in that year, which is a long time, the company decided to pivot. An acquisition was made and another strategy was formed and that became the growth engine and suddenly I just wasted a year lobbying and creating a lot of vision and a lot of interesting ideas that never got realized into actual products. It’s easily the most frustrating thing I’ve ever done. I realized at that point in time that there’s definitely a job there for somebody to work through that and to do that kind of lobbying and build vision with the risks of never being able to build it. I decided that’s not what I want to do.
I came up with minimal criteria for what I wanted out of a product position. That was to create a useful product, useful or valuable are two words I go back and forth on a little bit. I think a product can be valuable and not useful. I want to build a useful product, and I want to work with a great team, and I want to engage that team, and then I want to have fun doing it. That became the minimal criteria for me when I started looking for another job and landed in a startup company. I get that every single day. Every single day I check those three boxes.
Richard: I was gonna say. In a startup situation you might have the reverse situation, where instead of planning, and visualizing, and organizing, lobbying for the long term, you could have a drive by situation where your CEO walks in and says, Hey, I’ve got an idea, or, I saw this yesterday, or, our competitors are doing this, this is the new priority. How do you deal with that?
Brian: That’s every day. To some extent, something like that happens. You get so sales focused in a startup, because every opportunity is so incredibly important, that you can say, Well hey, we just planned out the next six months, but we just got this customer on a call and they’re asking for X. Should we do it? And the dollar signs carry so much more weight in a small company than they do in a big company and it’s extremely tempting to say, If we do this then maybe we hit cash flow break-even, but what’s the effect on the two year plan? You always have to pause and have that conversation. I think it’s easy to not have that conversation and just do it, Mario Andretti style, but you gotta find the balance. You gotta have the conversation. You gotta whip together some sort of quick ROI analysis, just so everyone knows you paused and the pros and cons were considered. Eyes were open. Let’s check those boxes and if we all at least make the step together with our eyes open, at least then you don’t have to worry about alignment issues.
The worst would be if you were making quick decisions like that and you weren’t all on the same page. At that point you’re in deeper trouble when the choice wasn’t the right one. It’s definitely tricky. I think we’re always, in the product side of things, sometimes those decisions are gonna be made and maybe you don’t feel like it’s the right product strategy choice and at that point what you need to do is try to do your best to maximize the work that you do so that it can benefit the new opportunity and the opportunities that you know you’re still going after in the future. Can you craft a solution that solves the new problem, that’s adding value to the four other problems we’re trying to solve. That’s tricky. I think that’s a little bit of the art of being a product manager.
For me, being able to visualize, to view into the technical side of things as well, I think it’s an advantage to be able to say, We want to go and solve this other problem, but if you think about it we can do it in a way where there’s a lot of overlap with these other problems that we’re solving. For the end user and then also perhaps technically speaking. If we can craft this solution to take advantage of these three technology modules we already have or that we wanted to harden anyway, then we can get a better return on those across other problems that we’re trying to solve.
Richard: Sounds like you’re balancing being Mavrck and MacGyver
Brian: A little bit. In a startup you have some of that going on all the time. Problem solving. If you don’t like problem solving, you shouldn’t be in product.
Richard: That’s true.
Brian: It may be the most fundamental aspect of product. I think one of your questions in the survey was, How did you explain what you do to your parents? I’m fortunate enough my parents understand what software is. Let’s say they didn’t understand computers at all. I’d say something like, every day I go into work and I solve problems with a team, and those problems are usually trying to drive some value for one of our customers. I think a lot of jobs you can describe that way, but software product development, hard goods product development, any kind of product development project, including architecture. My wife’s a landscape architect. At that point you can say we’re doing the same thing. We’re solving problems every day and trying to drive value for our customers.
Richard: In our interviews we’ve noticed that a lot of the problems that you’re solving are not always technical? They’re mostly about people problems, if that’s a bit of a broader term, then it might be down to managing expectations, or at least aligning expectations. How do you do that?
Brian: That’s a good question. When I heard about this interview I thought if there’s one point I want to make, what would it be in an interview with a product development? I kept thinking about the team that we have here. It’s interesting, I’m the old guy in the office, most of my team are what you’d call millennials. I don’t know how I feel about that label, but one of the things I find about the team we have here, and I don’t know if it’s all millennials and I’m just generalizing, or if it’s just the people I have here because they’re unique, is they all want to create. If you’re an engineer, if you’re a product manager, I think ultimately you want to solve problems, you want to create, that’s why you’re there. To build something cool. Everyone has an opinion. I absolutely do not believe in drawing hard lines between the engineers and the product team about implementing a spec.
One of the best things I think about AGILE is that with AGILE you’re taking away the hard specification, or the upfront definition. An interesting upside of that, because you’re constantly iterating it means more people get to be a participant in the process. From a team standpoint, a lot of issues are around making sure everyone’s opinion is heard. Making sure everyone understands what the other person’s opinion is. Everyone has good feedback, and learning how to take that feedback, learning who should be consulted because they’re good at something, who to invite to what meetings. It’s funny, we have 10 people, if I’m gonna have a meeting about some module, who do I pull into it? I pull in five people, then five people might feel left out. There’s an art to that. Who should be invited, who could be invited. There’s a real interesting dynamic there. When do you poll the group versus when do you make a hard, firm decision. At the end it’s important to get as many people involved as possible.
I had a developer, I forget how we got onto this, but I do one-on-ones every week and I always start by asking them what their Mavrck promoter score is, which is like a net promoter score. You’re walking down the street and you saw your buddy, would you tell them to come work at Mavrck? I always start with that. The other question I always ask the engineers is, What do you think about your projects? How do you feel about them? I do that because I had this engineer that specifically asked me to ask her that question. She was like, I want you to ask me how I feel about these projects. She’s not asking, Is this project too hard, or boring. She wants to tell you about how she feels about what we’re building. I always try to draw that out of people. I’m like, “Hey Pat, what do you think about this project that we’re working on? Is it the right project? Is it going to drive value?” And the Pat is a ATI engineer. They always have interesting things to say. They always want to be heard even though they’re not the vocal person in the meeting. They always have opinions. So I think for them to be satisfied in their job, that’s a huge part of it. If everyone feels like they’re creating together, you’re gonna win. The team’s gonna be happy.
Richard: Right. We have a saying around here that consensus is not collaboration. It’s not the purpose of collaboration to get consensus. It’s not a democratic process. The idea around collaboration is to hear what people have to say, understand how they feel about things, and consider all those things, but it’s not about polling everybody around every single decision, because that can also be frustrating for them, because it doesn’t allow anybody with any experience or value around a particular domain to influence anything.
Brian: That’s true. Totally agree with that.
Richard: Brian, we’ve hit our 30 something minutes here. I want to say thank you. Thanks again for your time. Really appreciate it.
Brian: Any time. Glad to help. Let me know if there’s anything else I could do.
Richard: Cool. Thank you, Brian.
Brian: Take care. Good to meet you, Richard.