This week on Product Love, we revisit my interview with Sam Boonin, the VP of Product Strategy at Zendesk. Sam is also an esteemed member of our debate club, where he’s weighed in about what the primary driver of a product roadmap should be and whether PMs need a technical background.
Spoiler alert: he does not believe that technical experience is required for product managers. To Sam, being technically fluent doesn’t necessarily translate to making the right decisions. Instead, he calls for customer empathy as the more desirable trait.
We also chatted about his experience in scaling product teams and the importance of implementing the founder’s vision. I am now happy to share a lightly-edited transcript of that conversation. Whether you prefer audio or love reading, I hope you enjoy it!
You can check out the original post here and stream the audio version here or subscribe on iTunes today.
Eric Boduch: Welcome, Sam! Glad to have you here on the Product Love podcast. Why don’t we start by giving us a little bit of your background?
Sam Boonin: Sure! Thanks for having me, Eric. My name is Sam Boonin. I’m currently the VP of Product Strategy at Zendesk, which is kind of a fancy term that I’ll get into. I’ve been at Zendesk for a little over 6 years, mostly in product management roles and some go-to-market as well. I’ve been in tech for probably over twenty years at this point. Don’t ask me how old I am. Combination of product, or product marketing roles over small or large companies, pretty much all around bringing new and innovative products to market.
Eric: Awesome. So why don’t we start by talking about scaling product management as the company grows from a small team to a public company? You have a lot of experience there.
Sam: Yeah, that’s certainly what I’ve been doing at Zendesk. I think I’ve seen that there’s a relative pattern. First of all, scaling product teams is super challenging and interesting. It’s hard to get right. But when you get it right, it’s pretty rewarding. You know, in the early days of product management, especially at startups, it’s kind of around understanding and executing around the founder’s vision.
What was the reason the company got started to begin with? Depending on your startup philosophy of choice, if it’s lean startup or whatever, it’s all about pivoting and adapting to those pivots. So changing business models, changing focus, and things along those lines.
If you’re lucky, it seems that the next thing that happens is to deal with the customer demands that you’ve innovated with, whether it’s feature requests, or even changes in your business, loss of customer inputs. Then if you’re really lucky, you have to deal with the crushing loads of the technical debt you got from pivoting and building a lot of MVPs, dealing with a lot of customer demands, and it’s finally in sort of like a fifth stage that you’re dealing with some level of steady state where you got a mature product function.
You’ve got mature products. You’re building some new things and you have a steady state of say, 60-70% of folks working on sustaining and building existing products. 20-30% is sort of building new stuff, and 10% are doing some whacky big bet kind of stuff. Again, going through those phases of scale in product management teams are super hard, because you typically went from a founder whose a product person to teams of 20 or 30, or even 50 at that point.
Eric: So let’s talk a bit more about one of the problems that you’ve mentioned, dealing with product or technical debt. Any thoughts there? Any advice?
Sam: Just to be aware of it. I’ve had a lot of debates about whether technical debt exists or not. I recommend not having that debate because it’s kind of a no-win argument on either side. I think what we try to do is be mindful of the decisions we make as much as we can, realizing that it’s sort of inevitable. Having a discipline of a product person not to build something or can you build it as one office or it’s a customer. We’ve had problems where, just as an example, we’ve had too many databases and too many technologies to count so it’s very tempting to apply the next technology to the next problem that you’re facing.
The discipline to see whether your existing infrastructure, existing product or existing stack can handle what you need to do that. It’s super hard to do that. I think we’ve had some successes. We’ve had a good set of APIs in our products at Zendesk. We have an app framework which allows you to extend the product, or some of our products, like using APIs and installing apps to extend functionality. It’s helped a little bit with sort of product debt, and feature bloat, but I don’t have a really good pithy way of describing how to prevent it. It’s just something I feel that you have to be super mindful of and understand that when you do it, you’re going to incur this debt.
Eric: So now, I have to ask since you mentioned having this argument. Does it exist or does it not?
Sam: I think it does. But I get frustrated typically, that product people who like to incur a lot of debt are the ones that argue that it doesn’t exist. It’s kind of like arguing about the national debt or the deficit on whether it’s important or not. People who are like, “We’re gonna go bankrupt as a company and China is gonna control the economy if we’re not careful with our national debt.” And then other people are like, “We could be highly leveraged as a company. It doesn’t really matter.” Having that debate is kind of an impossible thing to talk about.
Eric: So talk to me about moving from a founder’s vision. When you’re that first product team member that isn’t the founder – what’s that like?
Sam: Yeah, I didn’t have this at Zendesk. I came in when we were about 100 people and about three or four product managers. I’ve had it in the past. I think that’s the hardest job as a product manager to have, to be the first PM outside of the founder. And again, very specific to startups, and specific product-driven companies.
First of all, product people tend to think of themselves of being pretty smart and if not knowing all the answers, being able to get all the answers. It’s a little bit of the ego in being a product person but you really have to. It’s the reason why the company exists and to a certain extent, the main sort of stress of the company is to realize the founder’s vision and keep building it.
Typically, product founders aren’t disciplined product managers so they’re not going out and seeking out the right amount of customer insights. They’re not really balancing, “Oh that’s going to be too hard to build.” They’re visionaries, so checking your ego at the door and really being a servant almost to the founder is super important. It kind of goes against a lot of what product managers think of themselves as what they’re good at. I’ve done that a couple times myself, and it’s one of the hardest jobs I’ve had. You know it’s being sort of the first product person into a startup after the founders. Again, no easy recipe for doing it successfully.
I think it’s a really important thing for all product professionals to go through that because it’s another set of constraints that you have to operate within. There’s nothing more rewarding than when it does work. I’ve been involved with some that didn’t work, and ones that kind of work. But when you realize that founder’s vision and work well with the founder and sort of getting that energy that he or she has, you know from being that true entrepreneur, it’s incredibly rewarding.
Eric: So let’s talk a little bit about building those discipline teams. How do you teach product managers?
Sam: That’s a big question. Obviously, I’ve been lucky to be on some really good product management teams myself and how I learned was primarily… I took some product management classes, but I’ve mostly learned from the teams I’ve been on. Everybody will tell you that there’s really no formula on how to learn. You can get a CS degree, but you can’t really get a product management degree.
From my perspective, I think the two most important things, in terms of the two things I really want to teach any product manager. Number one is, without a doubt, the concept of customer empathy. It’s so important to really understand and put yourself in the shoes of the customer and the users of your product. Depending on your business, it can just be more than one user in B2B settings. The second thing is to really understand how to be collaborative with the rest of the team. People talk about the magic triangle of product manager, engineer, and designer, whatever the case may be or however the company sets up, but being able to really collaborate with the product and other members of the team. How do you actually teach them that? Modeling good behavior is probably one of the most important things. Once you get beyond two, three or four scrum teams, you have two or three or four of examples of product managers, and combinations of PMs and designers. They will kind of learn that. Again, the PM is the one that has to bring the customer empathy the most. Designers, obviously, do a lot of that with the huge advances we’ve seen in UX and product design and empathy on that side. I’m going to say “empathy” a lot in this podcast because I think it’s so important.
Eric: I would completely agree with you on the empathy side of things. I would say it’s one of the most essential, if not the most essential skill for product managers.
Sam: Yeah, definitely.
Eric: So now, you have a really strong background on the go-to-market side. How has that helped you?
Sam: Yeah, I’ve sort of bounced back and forth between product marketing and product management. Typical sort of background you’ll see. I’m not an engineer by trade. I was a liberal arts major in college and eventually got my MBA after kicking around for a little bit. Obviously, I’m biased because of my experience, but the go-to-market experience I’ve had feels more valuable than any technical skills I could bring to my job or my career. Unless you have a really technical product, or you’re a super specific company like Google, for example, that hires very technical product managers. I think go-to-market expertise is a lot more important than technical skills.
I’ve spent most of my career in B2B. In B2B, the go-to-market implications are so important in how you build products. At Zendesk, we started as a SaaS web model where we were driving hundreds, if not thousands of trials a week and people would swipe their credit cards and buy products without them interacting with a human. Our business is a little bit different now but just understanding the go-to-market implications of that and how you build products is so important compared to how do we turn a tweet into a support ticket, how do we wrap workflow around how a company can handle a particular support incident whatever the case may be. So I just feel that understanding on how the go-to-market of a company is impacted by every decision you make can be a little more important than like what’s technically feasible, like how to build something that’s going to be durable, and technically capable. Obviously, I’m biased because I’m a go-to-market person but I think it’s super important.
Eric: So let’s talk a little bit about engagement. How do you work to keep customers engaged? I imagine that’s extremely important, especially in the web try-buy model that you were just talking about.
Sam: Yeah, so it’s different for every company and again, I’ve certainly worked for companies, and worked on products that didn’t get a lot of usage and sort of had crickets of people trying or even having really heavy sales model where it’s a six months sales cycle before people actually even tried the product. At Zendesk, because we’ve had this web try-buy model, because we’ve put a lot of effort and energy, and we still do, into getting people to our website and into a trial. Engagement becomes really important. When I showed up at Zendesk, it was a little bit different. We had probably like a two-year list of features that we had to build, that we wanted to keep building out. We had a lot of vocal customers with lots of demands, with new features that they wanted, and with things they wanted to change in the product. We had active user groups that were sort of like, “Why don’t you build X? Why don’t you build Y?”
But the thing that we noticed that is really interesting was that number one, when we started to instrument our product, and instrument our trial; a lot of people were missing a lot of basic things. It came in a number of ways. Number one, we can see which customers implemented which features and used which features at what point in their life cycle. The second thing is, we started to hear something really funny in our user groups and our forums where people were actually asking us to build things that product already did, so there was a huge awareness gap between what our customers thought they wanted, and what the product actually did in a good way. We already built that.
So engagement number one, we sort of did the classic, “Here are the three or four features…” once the customers turn these features on, they tend to convert faster at a higher revenue point. But we also realize a huge thing we had to do is, educate customers on what their product is already capable of doing and also come up with ways they could solve these problems so engagement is hard.
Even though for us, this whole software as a service, free trial, give customers access to all your features is kind of an old hat to people who are product managers in a SaaS world. It’s still pretty new to most of the customers that are adopting it, so they’re not used to it. Especially when your product kind of goes from early adopter to the mainstream; they’re not used to feature discovery, clicking around, and figuring out how to do things. They need a lot more guidance. And again, engagement is the word that we use for that. I’ll go back to customer empathy. We have to realize that this isn’t a 26-year-old millennial SaaS user that has used 15 SaaS products in the last year. In our world, it could be a director of customer support at a middle America company that is switching over from something antiquated, or even a shared email, and she may need more guidance and direct engagement than you’re used to.
Eric: Absolutely. So let’s talk a little bit about scaling product teams. You know, Zendesk grew really fast. You hear a lot today about this triple-triple double-double, year over year, the growth rate for SaaS companies. Now scaling product teams, and fast-growing companies have to be a huge challenge. Do you have any advice for senior product leaders?
Sam: My biggest advice is to try to get lucky and get into one of those environments because it’s super fun to do that. We’ve had that similar growth that you’re talking about, the product team as I mentioned earlier, we went from four or five when I showed up, and now we’re about 50 or 60 in terms of the number of product managers or total people on the PM team.
Again, I think the first thing is to create a strong culture and to create a culture that’s durable beyond the founders of product teams. What does it mean to be a product manager? In our case, what does it mean to be a Zendesk product manager? There are certain things we do that are maybe unique or different than other product teams and you create that culture, and then you imprint it on the second and the third and the fourth product manager.
It’s really informal, and it’s kind of hard to describe but you see it in the practices, the way that we build our backlogs. It’s the way we do something called ticket duty, which is something every product manager has to do: a rotation where they sit on customer escalations, customer support escalations, and that means they have to get to know, not just their part of the product, but the whole product. The second thing we did, which was somewhat consciously, is that we built a balanced team. Your second and third hire always wind up being clones of your first hires; sort of a lot of studies about this.
What we did is that we made an effort to break out of that. We hired somebody from our support team, our customer support team. He spent his first year at Zendesk, where he spent all day in tier one support, dealing with all these issues. He had a list of 10 things he wanted to fix if he could ever do it. Again, the empathy that he brought from dealing with customer issues and dealing with the imperfect product we made was incredibly valuable. He didn’t have any PM skills, he learned it on the job.
I also hired a sales engineer, somebody who was involved in presales. That’s important because he understands how to implement our imperfect product, so how you get around feature limitations or other things in order to satisfy customer needs so building a balanced team was a super important thing for us. Things that got difficult for us was that Zendesk does things globally, so more than half of our product efforts are outside of the U.S., which is great for travel but it’s hard so setting up that second office and hiring the third office, where we had one product manager, for example, in Copenhagen. We had one product manager in Melbourne, one in Dublin. That was the hardest, making sure those people could learn and be a part of the greater product team even though they were somewhat isolated. Now it’s a little bit better because we have teams of people in all those locations but that’s also a really hard thing to do.
Eric: So you hinted at it a little bit. Global giants, and pulling people out of sport, but at Zendesk, you’ve supported a product that sold to global giants, but also as a self-service model. Now I’ve seen that kind of bifurcation destroy companies. How have you, and how has Zendesk not only managed it but really been able to excel?
Sam: Yeah, actually. That’s one of the main reasons why I wanted to come to Zendesk, to begin with. I was really interested in this bifurcation. It’s funny that you say bifurcation because I remember in 2012, or 2013, sort of putting bifurcation as a word into a slide in 256 point font and going around to talk to people about all the implications of bifurcation in our business. It’s really challenging to balance it, but it’s one of the main reasons why we’re successful as a company at Zendesk. I think where it can destroy companies is by not being mindful of the balance.
In our world, if you look at our support product, we’re a multiproduct company. We’ve got a chat product, talk product, a product called guide which is our customer self-service and knowledge-based product. But the core product remains support. If you look at that product, it’s still, to this day, when you buy the enterprise version of that product, which is used by companies that have thousands of support agents and very complicated processes. They’ve extended the product again, using our APIs and app framework and they’ve integrated into, not just standard, but custom third-party systems, etc. It’s the same product that a startup or a small company that wants two or three agents with really basic functionality uses. It’s the same code base, you implement it in the same way and I think that discipline is really important to maintain.
We think that we get huge advantages by having a bifurcated business model and web try-buy on the low end and sales-assisted customer success consultative on the high end. But by having a single code base, a single product and by forcing ourselves to always think about both our enterprise buyer and our S&B buyer. We think it makes us strong in the end. But as you said, it’s super hard to maintain that discipline and if you don’t do it right, you can really hurt the company.
I think one thing that we benefit from at Zendesk and one thing that I’ve seen over and over again in my career is that it’s so much easier to build upmarket than down market. It’s easier to add complexity and the configuration options, the security roles, permissions and things along those lines that upmarket customers want than it is to take a complex product and simplify it for a simple buyer. I talk to a lot of people who come to Zendesk a lot, and say, “Hey, how do you guys do your web-try thing?” Or I look at some of our main competitors that have been around awhile, and I see them constantly trying and failing to build a self-service product because it’s just so hard to move down.
Eric: Now, one thing that you mentioned in there was balancing feedback and what I imagine, requests from the self-service side and also from the enterprise giants. Do you have a particular process for doing that? I often see larger dollar customers getting the lion share of attention. How do you effectively balance that?
Sam: We’ve been through a lot of that at Zendesk. I think we’re in a pretty good place with it, although it’s a constant adjustment if you will. First of all, our own guide product is our customer portal self-service product has feature requests in them. In an effort to eat our own dog food, we have our own feature requests forums which customers can go and post their own requests then vote on them, and add comments on that. As you can imagine, we have a passionate and relatively large customer base. There are lots of interesting, funny comments: “Do you guys even read this?” “Why are you guys even doing this?” We’re getting a lot of ‘Voice of the Customer’ directly from the customer by posting on our feedback forums.
Second of all, we get tens of thousands of support requests or support tickets a month just using our own product because we have over a hundred thousand paying customers. Third, obviously, larger customers that are either sales-driven or owned by customer success teams, our product teams can interact and do roadmap presentations and have conversations. Then there are internal stakeholders that build this particular set of features so we can access this particular segment or go after this market opportunity. I think that this is more of an art than a science.
But each product team is balancing those different sets of feedback, and those have changed over time so our support product is pretty mature at this point. I wouldn’t call it feature-complete, but it certainly doesn’t lack features. We’re moving up-market so what we’re deciding to build there, is larger features that customers would want so we can grow the market opportunity.
We have a product called Connect, which is a set of proactive engagement tools where we’re really getting to market for the first time. We’re building out the basic feature set or something in each case. So each case of those, balancing out the different inputs we have from existing customers to new customers to internal stakeholders is really hard. I don’t know of a company that does that incredibly well, we just started using a product called product board, which is a start-up that helps you organize and structure customer inputs. It’s sort of a roadmapping tool and it’s pretty effective. We’re seeing that get adopted by a bunch of different teams, anything we can do to put a structure around that is really valuable because again, it’s one of the hardest things that product teams have to do; figure out how to deal with all the inputs that you’re getting to make really good roadmap decisions.
Eric: When we were talking earlier, you describe yourself as being the least technical guy on the product management team. Probably not true. But assuming it is, how does that or doesn’t that actually matter?
Sam: Well, I’ve done this a couple times. My boss, at my first review at Zendesk, said, “If you were a Native-American, your Native-American name would be Man Afraid of His Engineers.” I think to a certain extent, it is true that I am maybe not the most technical person. I use it really effectively to be self-effacing.
At Zendesk, and a lot of companies I work for, our customers are not technical. We certainly have developers that implement Zendesk or tool teams putting our mobile SDK to their native apps or something like that. For the most part, our customers support agents, team leads, and admins and Vice Presidents of Support and they’re not technical themselves.
If customer empathy is the most important value of a product manager, then I shouldn’t have to be technical. I shouldn’t have to understand the technical nuances of things. Obviously when we’re making the implementation decisions and as a product manager, you have to understand the job description framework that your company decides to build on is going to impact velocity a lot and hosting environments whether you’re public cloud hosted or building your own private environment. Those are really going to be important decisions. I think that you don’t need to be technical and for me, we have pretty technical product people, and we do have a pretty technical stack. I think, by saying, I’m the least product technical person around – it actually gives me a little bit of cred because what it allows me to tell people is that empathy is that important. You don’t have to be technically fluent to help make the right decisions is what I would say.
Eric: So are you truly afraid of the engineers?
Sam: I’m not. That was my Native-American name, but I am not afraid of the engineers. I do lose interest sometimes in the second hour of technical conversations.
Eric: So one final question: three words to describe yourself?
Sam: Everybody calls me snarky which I think is a compliment because I can be pretty funny, and biting at times. I think honest, or even brutally honest would be the second one. I think we are not as good as we think we are in a lot of cases, and we are not as bad as we think we are, and I tend to call that out. I think the third thing I would say is passionate, I just have a passion for the day-to-day work we’re doing and making sure we do it better. If I had to do that again, I might come up with a different list. We’ll stick with snarky, honest, and passionate.
Eric: I think it’s a good list. You know, brutally honest is actually one of our core values. Snarky is not, but brutally honest it is. I would say if I had to pick attributes for product leaders, passionate and empathetic would be two of the top three. So I think you encompass a lot of great things there. Well, thanks, Sam. This was great. Enjoyed the conversation. Look forward to chatting again in the future.
Sam: Great. Thanks, Eric. I appreciate it.
You might also like
