This week, we revisit a conversation with Kirsten Butzow, an industry leader in product management and marketing. Back when we spoke, Kirsten was an instructor and keynote speaker with Pragmatic Marketing and has since moved on to a new role as director of brand and marketing strategy at Salt River Project. Kirsten’s resume is a thing to behold: she’s held high-level product management positions at Blackboard, Pearson, and Fujitsu, not to mention she’s an esteemed member of the ProductCraft debate club.
Thanks to her experience, Kirsten has seen the role of the product manager evolve throughout the years. When Agile was initially adopted, product manager was clumped together with product owner. However, people began to realize that the responsibilities of a product manager differed greatly from that of product owner.
As a result, more and more companies are giving product a seat at the table. We see roles such as chief product officer or VP of product emerge each day, but it’s been a long time coming. Senior-level product people used to report to marketing or engineering before they could carve out their own place amongst the ranks.
Another thing Kirsten and I discussed was the lack of diversity in product management. We’ve touched this topic before, but it’s worth mentioning over and over until we fix it. Women represent a disproportionate amount of users in the most commonly used applications, so shouldn’t these companies reflect that level of diversity they see in their userbase?
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: Hello and welcome to another episode of Product Love. Today I am here with Kirsten Butzow, Pragmatic Marketing coach and consultant and reformed VP of product management. Kirsten, give them your background. I thought a great topic to talk about today might be high-performance product organizations. But, before we start, why do you give us a quick little overview of your background and your experience.
Kirsten Butzow: Great. Well, first of all, I just want to say thank you very much for having me today. I’m super excited to be here. As you indicated, before becoming a product coach and instructor with Pragmatic Marketing, I was a vice president of product management. Lot of experience and education technology in that role with companies like Blackboard and Pearson before joining Pragmatic and going out and trying to institutionalize best practice, product management and marketing methodology to the masses. That’s just a little bit about me.
E: Talking about high-performance product organizations, let’s start by talking about staffing, in particular, staffing at different levels of growth from start-up to growth to really scaling the company. Can you talk to us a little bit about what the size of a team would look like, what the makeup might look like, the responsibilities and goals?
K: Absolutely. I think the first thing that you want to think about when building a high-performing team is regardless of the stage of the organization and regardless of the size of the team, I always want to think about the work that needs to be done first. Then I’m going to think about creating an organizational structure that best supports the work that needs to be done. I find very often when we set out to build a high-performing product team, we think about building a hierarchal org chart, define structure first.
I think that’s actually the backwards way to do it. I think the better thing to do is think about where are we as an organization? What stage are we in? Where are we heading? What’s the most important work that we need to get done today in our life cycles and organization and then let’s staff that accordingly. Obviously, the byproduct of that is you’re going to have different size teams, you’re going to have different functions that those teams are performing as your company grows and develops.
A start-up, for example, might have one person. I think that we’ve got to think about all the activities that need to be completed and then we have to be realistic about what one person can accomplish. So in a start-up, I’m probably going to be looking for a product leader who has a lot of different background, a lot of different experience. Maybe somebody who’s got some technical expertise, maybe somebody who’s done a little bit of product management, done a little bit of marketing.
I’m going to be looking for somebody who’s a little bit more of a jack-of-all-trades because I’m going to have to ask that individual to do a lot of work across a lot of different areas. So I’ve got to find somebody who’s really ready, willing and able to plug-in in lots of different ways. The goals with a start-up are about getting that minimum viable product done, getting something out the door and starting to get traction in the marketplace.
Once we start getting that traction in the marketplace and we start to climb up that bell curve, that life cycle curve, and we start to go into growth as an organization, obviously the size of the team is going to start to expand. Now I’m going to be in a position where I can start thinking about specializing. I might have a product manager, I might have a product marketing manager, I might have a technical product manager.
The reason that I’m thinking about adjusting my skill set to a wider group of individuals that are specializing, is because the work has increased. I can no longer have one person, that jack-of-all-trades covering it all off. Now I’m going to go out and I’m going to find specialists who can really delve deeply into each one of those areas of expertise because that’s where we’re going to start to get scale as an organization.
Now let’s take that one step further. I’ve got scale. When I’ve got scale, what I’ve got to start thinking about doing is replicating that model that I had at growth across multiple teams. This is where a concept with something like agile is going to be really important and come into play because if you think about it, what I need now are individual, fully-integrated, cross-functional teams that have representation for all that key work that needs to be done.
I’ve got to have somebody who can do product management, somebody who can do design, somebody who can do the building, somebody who can do the testing and somebody who can do the validation all embedded in one team and I’m going to have multiple versions of those teams as I start to scale my product. It’s a natural progression from a start-up to a growth model to a scale model and it’s just a matter of how we start to expand or add those roles and going from one individual to a couple of individuals to fully-integrated teams.
E: Now, let’s talk a little bit about types of roles there. One of the discussions I was having recently is where user experience, UX, should sit in an organization. Should that be part of the product team? Should they be in that group?
K: Well, that’s a great question and it’s also a loaded question. I think the answer to that question is, truly, I don’t really care where the design folks fit if we have a healthy respect for the role of design. The way that I think about articulating how that role should really be clarified is somebody has to be responsible for gathering the market data, the what and the who. What is the problem we’re trying to solve? Who has the problem that we’re trying to solve?
Then, we’ve got to take that what and who and I would advocate that that’s the product team. That’s the product leader. That’s the product manager. Somebody has to now be responsible for converting that what and who into the how. I think how the team is going to include the designer, the engineers, the testers, customer validation. Whether or not design fits in with the engineering team or whether or not design fits in with the product management team is really inconsequential to the work that needs to be done.
As long as we have a really good idea and clarity of the difference between the what and the who and the how. I will also say we have to be careful that wherever we decide to put design, they will have a tendency to get pulled into that organization. If we put design into the engineering organization, they’re probably going to get a little bit tighter to the engineers. If we put them in with the product organization, they’re probably going to be a little bit tighter to the product team.
I’ve started to see a trend where we’ve actually pulled the design out and created a department of design that is by itself. Apple is famous for the fact that their design team all reported directly to Steve Jobs. It’s one of the reasons he advocated that they are able to design elegant products in a way other people can’t because they actually give it a seat at the big table. I think it’s just important to understand the role of design and I think it’s important to make sure that regardless of where they sit organizationally, they’re fully integrated into the team.
E: Let’s talk about how this looks at organizations that are traditionally not thought of as software companies, but for whom some software’s table stakes and in general software might play an increasingly important role in creating really a unique value proposition for their customers. Say like the banking industry, for instance.
K: You’re talking about a company that has software that helps in the fulfillment or the delivery of their core business. Yeah, I don’t think it really looks that different. I think it’s just a matter of how that work is perceived because for me, the work and the behaviors that we need to engage to build great products is true regardless of whether or not those products serve internal customers or whether those products serve external customers. At the end of the day, we’re going to consume resources as an organization. We’re going to apply time, we’re going to apply budget, we’re going to apply money to the things that need to be done and I better have a great reason for doing it and a great way to justify that.
Whether my product helps facilitate the delivery of something or whether they of themselves are the delivery of the thing, I have to think about how I’m delighting the people who have the problems that I’m solving. When I think about things like product management and design and build and test, I don’t really want to think about it that demonstrably different when I’m doing something in the fulfillment of something versus having it be the means to the end. If that makes sense.
E: Yeah, I think that makes a lot of sense. Do you think organizations like this are doing a good job of building up product teams and product organizations?
K: Well, I’m going to say I think we have room to improve. I’ve been at this for a very long time, Eric and I’ll be honest with you, I kind of wish as an industry we’re a little bit further along than we are. But I’m also going to cut us a little bit of slack because if you think about it, technology product management really is not that old. It’s still kind of in its’ infancy as a discipline. We have been evolving. We’ve been evolving pretty quickly.
When we introduce methodologies like Agile and UX, UI became really prevalent around 2007. We’re constantly having to figure out a way to play catch up in the way that we assign roles, the way we assign responsibilities, the way we integrate our teams to get that work product done. So, we as an industry are having to move pretty quickly and we’re having iterate pretty quickly as technology changes. I think of cloud-based computing and what that’s done to drive the rate at which we have to perform our work in technology related roles that we didn’t have to perform it at this rate five, 10 years ago because we couldn’t deploy technology at the rate that we can today. We really had to adjust over time. I think the really important thing to keep in mind is there’s some distinct roles that have to be done. Somebody has to write the requirements, the user story. Somebody has to design the product.
Somebody has to build the product. Somebody has to test the product. Where we run into trouble is if we don’t understand the importance of each and every one of those roles and we don’t staff them accordingly. We’ve got to get that clarity down and I think that we have room to grow. I think we have room to make improvements still as an industry.
E: Yeah. To that end, you see a lot of these traditionally non-software companies, but have a huge software component now. Do you see them having a VP of Product or a chief product officer? Or do you see that role being fulfilled by a CIO who traditionally had a very different mindset than some of the things we might be talking about?
K: I think I’m seeing a real shift there. I think even as recently as three years ago, maybe, yeah definitely five years ago, we asked the CIO to do it. Then we started realizing that IT is not the same thing as software development. We started to realize that we need to think about that role more strategically. It wasn’t until pretty recently that you started seeing even the role of a chief product officer start to pop up and that chief product officer having a seat at the table reporting to the CEO of the business.
Five years ago, we might have a VP of Product Management, but they usually reported into maybe marketing, sometimes sales, sometimes engineering, but we finally have stood up as an industry and said, “Wait a second. The products are our ‘make or break’. If we’re going to think about it, we really need to think about it by staffing it accordingly and giving it a seat at the big kid’s table.”
E: I 100% agree. We recently did a study along with Product Collective and found that 9% had CPOs. Then while that number seems to be growing and growing quickly, it’s still a small percentage. Let’s talk a little bit about Agile. You mentioned that a little bit earlier. For Agile organizations out there, how does the fact that they’re Agile affect staffing? How do we divide up the role of product manager and product owner? That always seems to be a challenge for software companies in particular and I’d imagine it’s even worse at a traditional organization that has a significant software component.
K: Well, these are two great questions. I’m going to take them in two separate ways. First, when I think about Agile and I think about staffing, there’s just a couple of things we have to keep in mind if we’re truly going to achieve the promise of Agile. In other words, we’re going to gain the level of velocity in our organizations that we hope to gain by institutionalizing Agile and that’s this: There are distinct roles. Somebody has to own the what and the who, that’s the product manager.
Somebody has to do design. Somebody has to build the product and somebody has to test the product. We have to staff for each and every one of those roles. That’s the first thing with Agile. The second thing with Agile is those roles have to be occupied by people who sit on an integrated team because the only way we really get velocity from Agile is if a team that stays together gets to learn together.
If we bungee people in and out of Agile teams every sprint … We have a designer, it’s very common, for example, to ask a designer to cover five Agile teams and three different products. It’s almost impossible for that person to be part of the velocity that we want to achieve by Agile because they can’t be embedded in a team and learn with the team. If we’re going to really be Agile, we have to start being super honest with ourselves.
We have to be honest with ourselves that we staff each of those roles accordingly and we allow those teams to be fully-integrated so they can actually learn together and get better and better together because that’s the only way we’re actually going to get the true level of velocity we hope to achieve with Agile. That leads us into the second part of this question, that product manager versus product owner.
Unfortunately, as we started to adopt Agile as an industry 17, 18 years ago, Agile demanded that we have this role product owner. Well, product owner’s supposed to be a subject matter expert that’s embedded with the engineering team so that they can answer those subject matter expertise questions on a daily basis, freeing the product manager up to be out in the market gathering market data. Well, organizations went and adopted Agile and they saw that term ‘product owner’ and they didn’t want to add headcount and they saw the term ‘product manager’. They thought, “Well, that seems close enough, we’ll just make the product manager also be the product owner.” What we’ve just done there is we haven’t staffed it accordingly. Now we’re asking somebody to be in the market gathering that research for the next functionality we should have or the next version of our product, but then we’re also expecting them to be available on a daily basis as a subject matter expertise. It’s a virtual impossibility for somebody to cover both of those roles effectively. I am seeing a huge trend. I work with hundreds of clients a year and I’m going to say in the last eighteen months, one of the most exciting things I’m seeing in the industry is, for the first time since Agile came on board, I feel like we’re really recognizing the importance of sourcing those roles and making them two distinct things: Product manager and product owner. I feel like 2018 is our year to make that happen, Eric.
E: It sounds like as good of a year as any to make it happen. The next step beyond that is extending Agile beyond the development organization, right? You’re Agile marketing, Agile product management. Talk about that a little bit. Should we be doing this?
K: Yeah, okay. Now, you’re going to get me really excited because I believe Agile is way more than a development methodology. I believe it’s a lifestyle. I really think if we can adjust our whole mindset to say, “Hey, every single thing that’s going to show to the market, whether it’s our market messaging, whether it’s our sales tools, whether it’s our sales enablement strategies, whether it’s our support programs, every single thing, every single thing that’s going to be our fulfillment of our brand promise in the marketplace, should be tested early and often before we put it into the marketplace.”
There is no reason why we can’t ask every functional part of the organization to iterate a long organization so when we put something into the marketplace, it’s not just a product that’s been validated and we have a really good idea that it’s going to be successful, but it’s going to be a product that has all of the supporting components of it so we’re actually delivering in a comprehensive solution to the marketplace.
E: Let’s change the subject a little bit to something that might be a little more … I don’t know if controversial is the right word, but it’s definitely top of mind for a lot of people today and that’s diversity. A subject that is very important, but can often be a little bit hard to talk about. I read Pragmatic recently did a survey and they found that 66% of product leaders were male and they’re in their late 30s, I think. Right? That’s not good, right?
K: Well, I don’t know if it’s good or bad, it just is what it is. I think what’s also interesting about that statistic, Eric, is Pragmatic Marketing’s actually been doing it’s annual survey for 17 years. That statistic has remained virtually unchanged during that entire time period. The composition of men versus women in technology-related roles has hovered right around that 61/39, 60/40 split. For 17 years it’s never really changed.
I think that that’s curious. I think … I’m going to say maybe it’s a thought-provoking topic, it’s certainly one that I think can everybody, myself included, a little bit uncomfortable. What I find is interesting is in the last year, obviously because of just events going on in the world, I am constantly being asked, “What’s it like to be a woman in tech?” Or “What can I do to be successful as a woman in tech?”
I don’t necessarily think that being a woman in tech makes me a subject matter expert, but I did start doing a little bit of looking a little bit of digging. I’m going to agree with you that I think it’s probably not a great mix. I think that the reason that it’s not a great mix is because if you dig a little bit deeper and you look a little bit further, it turns out, I was pretty surprised to find out that over half of the internet users and 55% of Facebook and Twitter users are female.
I got to thinking about it and I thought, “Wow. If women represent a disproportionate amount of users in the most commonly used applications and are online, can we really build beautiful, elegant, great products, remarkable products if we don’t have a diverse perspective within our organization? In other words, if our products are serving a constituency that’s 60% female and yet we only have 35% women in our business, are we really doing ourselves as big of a favor as we could get a broad perspective or that diverse perspective on the products that we’re building?
I definitely have this tendency to think, “Gosh, I think we could do better, but not maybe from the pure altruistic component of it. Of everybody ‘we should hire equally for diversity throughout our organization.’ But if we’re really going to build products that people love, we should probably have a diverse perspective of the people who are building them that’s at least somewhat representative of our user community.”
E: You mentioned the trend and the fact that the stats seem similar for quite a few years, has what’s happened recently, has that made things get better? Do you think things are going to get better? Are they getting better? Then I guess the second question to that, the second part of that, is how do we fix it?
K: I don’t know if they’re getting better because time’s going to tell. I think I’ve been at this for 25 years. I can tell you in my entire career, this is a topic that’s never been on the table the way that it’s on the table right now at this moment. There’s just been a series of events that have transpired that have catapulted the subject to the forefront in a way that it simply hasn’t ever existed in my 25-year career or experience.
Time will tell as to whether or not it quote unquote “gets better” or it changes or those numbers start to swing to be a little more even. I think that the fact that we’re engaging in a dialogue is exceedingly helpful as an industry because I think eventually we’ll see that that pendulum’s going to swing. I think there are some basic things we could do. I think we could look at ourselves, inside our organization and we could say, “Look, do we have a diverse workforce? Are we representing the people who use our products to some degree inside our building?
That’s probably a good place to start. I’m not saying that we should run out and have half of our workforce, for example, be women if it doesn’t make sense. I’m not saying that that’s the right thing to do necessarily, but what I am saying is we could make a conscious effort to ensure that we start to hire diversity into our workforce. I think one of the number one ways we could do that is we could look beyond the usual suspect places of where we go to hire people.
There are specialty groups by ethnicity, by gender in our community. There are groups for ethnic groups who code and women who code and I think we could make a proactive choice to dig into those organizations or reach into those organizations when we start to hire for roles versus just always going to the usual suspect places that is probably going to continue to give up the same demographic makeup of a candidate that we’ve historically always had.
E: Yeah and I would add to that too. I think one of the things we can do a better job of in product teams is hiring product managers that might not have a technical degree or might not even have a business degree. I was talking with Duncan from MemberClicks. He has a Liberal Arts degree. He was teaching English before he got into the space. Mike, from WorkWave, Ph.D. in Evolutionary Biology. Diverse backgrounds that have risen to the top of their profession. There’s no reason we can’t bring different perspectives, I think, to the product team. Do you agree with that?
K: I totally agree with that. I actually was recently on a panel discussion at Pendomonium and a similar question came up and if I can be redundant, I’m going to give a similar answer that I gave when I was on that panel and that’s what the number one attribute that I want my product leaders to have when they walk in the door every day is belief. I want them to believe in our vision. I want them to believe in our mission.
I want them to be passionate about the people who have the problems that we’re solving with our products. That means that we might get people from lots of different walks of life that can come into our organization and bring that belief and bring that passion with them. I think it’s a great point that you’re making. We can just maybe look beyond the usual suspect places when we think about our hiring practices so we can get a broad perspective within our workforce so we could build better products for the people that we’re serving.
E: Yeah, so belief, empathy, passion, right? Very important attributes for a product manager, which leads us into soft skills. Product teams need soft skills in some part of the organization to succeed. What particular soft skills do you think are most important in product teams or for product teams?
K: I think product leaders have to be hyper-communicators. I think these are individuals that have the ability to over-communicate and aren’t afraid to over-communicate. I also think that they have to have great organizational skills because they’ve got to work with a lot of moving parts. I think they have to have empathy. I think they have to be able to appreciate and empathize across the organization the frustrations, the stress that different functional groups are having so that they can bring those team members together to work effectively together. They can’t be afraid to take a leadership position and make a decision and then move on. I want them to be great communicators. I want them to have organizational skills. I want them to have an uncanny ability to hear and empathize with people and make sure that people feel like they’re heard, but then somebody has to make a decision and move on and they have to be comfortable in that leadership role as well.
E: Let’s talk about you personally. What’s your favorite software product and why is it your favorite? What’s your favorite technology maybe?
K: My favorite software product is TripIt. I travel for work. I’m on the road all the time. Our entire office administration and travel is handled through TripIt. Everything I need to know is in TripIt and I couldn’t live without it. It is probably the one app that I absolutely, positively could not live without.
E: Awesome.
K: I’m not getting paid by TripIt to say that.
E: But go to www.tripit.com. I’m assuming that’s the website. No idea.
K: I don’t know either, it’s on my phone.
E: I always ask people I’m interviewing this question. Three words to describe yourself.
K: I would say history buff, dog lover and wanderlust.
E: Great. Well, thank you Kirsten for being here today. I greatly enjoyed this conversation and I look forward to chatting with you again in the future.
K: Thanks again for having me.
You might also like
