Product Hero is our bi-weekly series to highlight outstanding members of the product management community. These industry leaders share tips on processes, team building, how to be a better product manager, and who they are outside of their careers. This week our product hero is Bryan Dunn, Senior Director of Product Management at Localytics.
C. Todd: Hi Bryan, thanks for joining me today. Can you start by telling us about your background and how you got into product?
Bryan: I started my career as a software engineer. I actually have a bachelor’s and master’s in computer science. I started my career at a huge company, Raytheon. Then I got the itch to be closer to the business decisions, and the bottom line – I ended up going in the complete opposite direction and being employee number 40 at a startup. I started as a software engineer, I moved to software engineering management fairly soon after I got there. We didn’t have a product team, so people managing the individual engineering groups were the de facto product managers. I initially was doing product management just as a way to keep my team efficient, but I loved how much impact you can have on the company by making really good decisions, understanding users’ needs deeply, and crafting solutions that really hit the mark.
C. Todd: That’s really interesting. There was no product team. Were the product duties assigned to the engineering managers, or was it you as an engineering manager who saw a gap in decisions and tasks that needed to be done and decided to take them on yourself?
Bryan: It was totally just a gap. The company was still small enough at that point where our CEO and COO were making a lot of the product decisions. We were also getting big enough where it wasn’t scaling very well. As the company grew, they would make some of those decisions, but they couldn’t get down into the details enough to understand all the nuance and tradeoffs of those decisions. They might’ve seen the potential value, but in terms of feasibility, and usability, those were 2 things that they didn’t have enough depth on, or the time to work through with customers in order to really give the engineering team good guidance about exactly what the market needed.
C. Todd: In terms of in the triumvirate of viability, feasibility and usability, they took care of the viability aspect but they were lacking in the feasibility and usability area?
Bryan: Yes. They ended up setting the general direction for the product but also had to worry about going to get another round of financing or 100 other things that come with those titles. Meanwhile, I was spending so much time with customers doing that detail-oriented work that a product manager does, that I started to have my own opinions about what we should be building. It’s often the case that the people closest to the customer are the ones that are best-suited to be making those decisions.
It started out as a way to fill a gap, but over time, it ended up that as I talked to more customers, as I worked through more issues with customers, I started keeping KPIs about how the products were performing. I was the one best-suited to shape the direction of the product.
C. Todd: That’s great. How did you become Senior Director of Product at Localytics?
Bryan: At my previous company, I went from being an individual contributor as software engineer to being Chief Product and Technology Officer when I left there a year ago. When I came to Localytics and had the opportunity to take some VP-level positions, but ended up deciding to take a downgrade to senior director because everybody I interviewed with were ‘A’ players. I didn’t want to take a step back, but when I got here and I started to talk to everybody, I think it was the right move. It’s very rare that you go through a couple of days of interviews, and everybody that you talk with really impresses you. I felt like I just couldn’t pass up the opportunity to directly work with some of the talent here.
I started off running the product management team. I’ve since taken on user experience and data science. I’m running the day-to-day on those 3 fronts.
C. Todd: I’m going to come back to the intersection of user experience and data science in a little bit. Just give us the quick, 30-second pitch on what Localytics does.
Bryan: We help our customers engage their users. Initially, we helped customers engage users through mobile analytics. Drop our SDK (software development toolkit) in your app, and we’ll track all your events, run the analysis, and show you how users were engaging with your apps. Our founders have always insisted we make any insights we actionable and Localytics saw an opportunity to tie great data and engagement together through messaging capabilities like push and in-app notifications. As we moved into the marketing space, we found our rich history in analytics allowed us not only to offer the marketing tools to send notifications, but also to measure all of the downstream effects of those in great detail, to really help customers engage their users in a way that no other product can.
For instance, we know there’s a lot of marketing products out there that can send notifications and tell you how many conversions you’ve got on a particular campaign. We can tell you not only what those conversion numbers were, but also performance of a campaign versus a control group. So while you might have seen a big jump in subscriptions purchased when you sent out a particular push notification campaign, it might have also caused a drop in long term retention or opt-outs of push notifications or uninstalls for some subset of your audience. Having all this data behind our engagement platform puts us in a unique position to help customers drive engagement in ways no other company can.
C. Todd: That’s great. Tell me about what you are focusing on right now? What’s your biggest pain point? What are the things that you’re trying to really work on right now at Localytics?
Bryan: We’ve been around for close to 8 years now. We have a lot of product. When you’re an early-stage startup, you need to just keep shipping product in order to hook a big customer so you can continue to pay everybody’s paycheck and you’re not running out of runway. We’re at the point now where we have great product market fit and need to be way more thoughtful about what we ship, and more importantly what we don’t ship. Everything you ship requires a certain amount of maintenance which causes you to get slower over time. How do we continue to have high-quality service and continue to push the roadmap forward quickly? I would say that is the biggest challenge.
C. Todd: On that topic of roadmap, let’s dig into that a little bit. Tell me about how the roadmap plays in your team’s process? You mentioned how it’s not only important, like what features you do ship, but what features and things you don’t ship. How does a roadmap help you with that?
Bryan: One important thing is product strategy, which is our layer above the roadmap. Over the last year we’ve defined clear boundaries that we want to play in. In the past, we might’ve been distracted by some opportunities that aren’t necessarily good for us. We have always been a very good mobile marketing product, but started to look at features that were slightly outside the bounds of mobile. We realized those things have a really high opportunity cost. As we started to consider adding more channels for marketing, we realized, “You know what? These things that are outside mobile carry way too large an opportunity cost and will just be a distraction.”
We’ve set a 1, 2 and 3-year vision about where we want to be, and we use that as the lens where we look through every opportunity to decide, “Is this something that we should be pursuing or not?”
C. Todd: That’s really cool because that helps you decide not only what to do, but what not to do, which I think is really important when you have a limited amount of resources. You mentioned roadmap criteria, with product strategy being one criteria that you recently added to it. What are the other criteria that you typically put into a roadmap?
Bryan: We try to suss out what value customers will get out of it, what our ROI will be, what else building this thing unlocks down the road, the maintenance burden, etc. How many customers do we see using this? What value are they going to get out of it? How is that moving their capabilities forward? Is it going to help them achieve their goals? Is it going to only help for a certain subset of customers that need this to achieve their goals?
There’s also the amount of work that’s going to go into it. Having all this data is our gift and our curse. We have a heavy tech stack, so it’s not as easy for us to push new features forward as it is for a company that isn’t storing terabytes of data every single day. There’s always that, the feasibility of it. What are the raw costs? What are the costs of developing this feature? How do we validate that as much as possible and get as close to what we think the real ROI is going to be for a particular effort before we start to develop?
We tend to do things like a lot of betas. We work with launch partners a lot to really understand the they are getting out of it, and where the rough edges are, before we release a feature for general consumption.
C. Todd: How do you manage trade-offs? Because you have the artifact of a product roadmap, that gave you some guidance, there was an ability to say, “Hey, wait a minute. There’s a trade-off here on cost. If we want to go this route, that’s fine, but here’s how much it’s going to cost, and can we do that?” It sounds like this prevented you from designing and deploying this incredibly expensive option, which may not have been very feasible or reliable?
Bryan: Yes. I think in terms of trade-offs, I think it was Eisenhower who said, “Plans are useless, but planning is indispensable.” I totally buy that. Roadmaps change constantly. I think I told Bruce when he was interviewing me for your book, the shortest amount of time I’ve had a quarterly roadmap blow up in was 9 hours. I think it was at 10 AM, before the kickoff of a quarter at my last company, and we had the roadmap laid out. We were all really confident in what we were pushing forward, the executive team in that meeting signed off on it. It was the most smooth, non-contentious roadmap planning meeting we’d ever had. We walked out of that room feeling great, and 2 hours later we found out that out of the blue, this large prospect was very interested and needed a feature that we weren’t planning to ship for another 2 quarters.
At 6 PM that night, we had all agreed to punt on the roadmap that we had and pull this effort in in order to make this deal happen in the next quarter. That meant shifting many of the efforts to things that we were planning to ship out. That was totally the right decision. It allowed us to hire new people to expedite the rest of the roadmap that we pushed out. Nobody was upset that we moved the plan out, but without that plan, without the context around the value that each one of those things was going to deliver, and the value of this new deal that had landed in our laps, we would’ve had nothing to compare it to.
Taken out of context, every opportunity seems like a good one but you end up being very short-sighted if you don’t look at an opportunity within the context of the rest of the roadmap.
C. Todd: How do product, design, and marketing work together at Localytics?
Bryan: Organizationally, the product org includes product management, user experience, data science, and product strategy and product marketing. Then we have a marketing department that’s separate that handles the standard marketing. The way that we operate is we use Spotify’s crew model. We have 5 crews that are all mostly full stack. When I say full stack, they have not only the engineering competency across each stack, but they have a product manager, they have a crew lead (which is the technical lead), engineers, and some of the crews have a user experience designer if they’re developing on the front end.
Then we have our data science team. They operate a lot like the user experience team where they’re a service that spreads across the crews, so there might be opportunities for a particular crew to work on some machine learning algorithms to improve part of the product. The data science team will work with them through creating those algorithms, and then move on to a different crew. They float based on need across the crew.
C. Todd: What’s missing from the conversation in product management today?
Bryan: I read a lot on Medium, Twitter, a lot of different places about the job of product management. I think the thing that always bothers me is it’s almost always B2C. A lot of people talking about B2C, and not necessarily B2B product management. I think that in B2B product management there’s really interesting problems to solve that are…I don’t want to say harder, or easier, but much different than your B2C products that focus on growth. When you have to worry about people actually buying your product, the conversations are much different. That’s one thing that tends to be missing.
The other thing is I hear a lot of product managers ignoring feasibility. When you’re talking to them about what you’re going through, they offer suggestions about why don’t you just do this, why don’t you just do that? There’s always about 1,000 factors that go into any product decision that are very difficult to see unless you are the product manager on that effort because you’re not weighing all those things against each other. Managing stakeholders and understanding the factors and all of the nuance is something that is very hard to discuss deeply in a group because it is really nuanced.
C. Todd: I’m curious, why is feasibility sometimes missing from the conversation? Is it that PMs just aren’t technical enough or they don’t come from the technical background?
Bryan: I think the best PMs are problem-solvers. When you start to have those discussions, you can tell a good PM when they start to ask more questions instead of throwing out potential solutions to a problem. At the end of the day we probably all understand that in order to give somebody else advice, you need to get into their world. That takes time and effort. You really need to understand the world of the people that you’re crafting a product for, inside and out, and the effort to do that is tremendous.
I think maybe it’s just an investment, a recognition that the investment there is not something you’re going to solve at a dinner party.
C. Todd: As technology’s changing and the way we develop products is changing, where do you see product management going in 5 years?
Bryan: A lot of people believe it’ll become a bit more nuanced, maybe separated. You have a product owner and a product manager working in tandem. I am always a fan of the PM understanding the feasibility aspects of anything. Balancing. Almost invariably the PMs at a company are put in a position to defend against why somebody shouldn’t do something. The answer to somebody who’s not a PM is always like, “Yes! Let’s build that thing. I think we can make some money there.” The long term cost and implications are something that’s very difficult to deal with.
I like having the PM and product owner role as the same person because they need to understand the feasibility and they can defend more easily against building products that might take you off the beaten path and make you a little less agile, and prohibit the ability to answer the call for change when it comes.
C. Todd: What are some of the things you like to do when you’re not at work and not thinking about product?
Bryan: Good question. I definitely like to hang out with the family. I have 3 kids so I don’t get much me-time anymore, which is sort of fun. I was a golfer in a past life. I like to read a lot. Anything where I’m not thinking about how to juggle 100 balls. Anything that’s focused and can get my mind off of the plate-spinning thing that is daily life as a product manager.
C.Todd: Well thanks so much for joining us today Bryan. Your insights are valuable and we appreciate you taking the time. Thanks for being a product hero.
- On product roadmapping: Product strategy is layered above the roadmap. Bryan and his team are able to make decisions using Localytics 1, 2, and 3-year vision as a guide to determine which features to build and not to build.
- On what’s missing from the product management conversation: all people talk about is B2C. B2B product management needs to be covered more. There’s a lot of interested problems to solve here that are much different from B2C.
- How Localytics organizes their product group: product management, user experience, data science, and product strategy and product marketing all work closely together.
- Connect with Bryan on LinkedIn and follow him on Twitter.