CP21: Scott Whitney from Actiance Talks about Product Management and Product Marketing
Welcome to the 21st episode of our podcast with Scott Whitney from Actiance!
You can download the podcast to your computer or listen to it here on the blog. Click here to subscribe in iTunes.
Martin: Hi folks, if you are running a business or you are thinking about starting one, you need to have a really cool product because in the end, this is what the customers are buying. Today we have an expert on the round with Scott from Actiance who will teach us about how to really build a rock solid product and manage the product team. Hi, Scott! Who are you and what do you do?
Scott: Hey, Martin. Scott Whitney here, I lead up the product team for Actiance. I have been in various product roles for close to 15 years. Originally started in management consulting for KPMG, so did a bunch of work there. I have an economics background, I focus on matrix and volumes.
Just by way of background, I started in product management in a company called Inktomi that was one of the early web search pioneers, then moved over to enterprise search, went into a company called Verity where I ran a product management team there and that was all about search, in particular enterprise search. From there I went and joined Symantec, which is a security company and we did a bunch of work there around what’s called email archiving.
And so, one of the fun things with enterprise search is that they made it difficult where you have got a search engine but you don’t necessarily own the content. One of the things I was looking for was – how do you build products that monetize enterprise content? Ultimately we ended up with email archiving because the email was the big gorilla in the room as far as content and the archive had all that content in place.
Then I have done several roles at Symantec and then ultimately went and joined a couple of startups, those startups get acquired, rolled into a large company; in one case here is Iron Mountain and then ultimately ended up at Actiance here where I am doing the same information governance, archiving types of workloads again in product management. I have been in product management, Martin, for close to 15 years now.
Martin: Scott, how do you get from Big4 into product management?
Scott: Yes, great question. So, as a low key consultant being shipped around the world globally, Martin, getting on an airplane, going to customers and helping them with their business problems, I took a seat back and I said: “Well look, how do I find a job where the customers come to me?” What I thought about here was, okay look, I live in San Francisco, there is a lot of interesting things going on in Silicon Valley here, which is really just half an hour down the road. I understand these companies are starting to get a lot of market attention, this is some 20 years ago now. And in the mid 90’s, I take a job there because primarily I wanted customers to come to me and I didn’t necessarily want to be on an airplane all the time. That was really the genesis for me, was really trying to spend more time here with my family and finding a job where I had an opportunity to do that.
Then particularly sort of switching out of Big4 consulting, at the end of the day it’s about interfacing with your customers and understanding what they want and what they need, understanding what their challenges are and what their business problems are, turning that into a set of requirements and actually implementing that as a product. And so there is a lot of parallelism between management consulting and product management.
BUSINESS IDEA OF ACTIANCE
Martin: Could you please elaborate on what Actiance actually does?
Scott: Yeah, so Actiance as a company name, stands for active compliance. And what we do, Martin, is, we provide governance tools for regulated industry firms. Think big banks, think big insurance carriers, think health care companies, energy transmission or energy companies whether they are doing exploration or whether they are doing transmission. What we provide, Martin, is a place to store all the communication events that happen within the company, so whether it’s a cross email, maybe it’s on Skype that we are using right now, maybe it’s on a share point blog, maybe it’s on Salesforce chatter, all those events are viewed as business records. And with many of these regulated companies, they need to be able to store those records, they need to be able to find them when they need to and be able to give them to other folks whether they are counter parties, whether they are a regulator, maybe they are opposing council. They need to give that data out to prove a point, whether it’s a legal matter, a regulatory, investigation. Having all that data in one place makes it a lot easier to get that work done.
Martin: Scott, do you know what, this is the perfect, let’s say link to your tasks back then at the Big4, because basically it’s the same stuff, recording transactions and making them available.
Scott: Right. And we effectively are what’s called the corporate memory.
So my background was search and indexing and so I had a particular expertise in that area. Also, coming out of a Big4 firm where they train you on understanding customer requirements, listening well to your customer, listening also to not just your customer but listening to market signals such as a regulator and understanding what those challenges are and what that does as a product manager, it helps you identify and quantify a market opportunity. Because at the end of the day, the product management function is about making trade offs and prioritizing all the different tasks that come into your desk.
Martin: Yes. What is your role at Actiance? What are your objectives? How did you structure your team accordingly?
Scott: Great. My title is Product Leader, and so I have got several disciplines underneath my oversight here.
So the first one is the traditional discipline of product management where there is an understanding of what the customers are asking for, quantifying and qualifying the market opportunity, being able to turn in those requests into a set of user stories. And the user stories are what’s communicated to engineering and what we tend to get back is what’s called a level of effort. And based on those 2 dimensions, what the user story is, what the level of effort is, and ultimately what’s the business value of the problem you are trying to solve, the product management team will tend to organize a set of priorities for a given release, and we happen to release every 4-6 weeks. And so every 4-6 weeks, we are releasing a new set of content into the product stream, and we have various internal discussions about what is of relative importance of one feature versus the other; that’s product management.
I also have responsibility for product marketing. Product marketing is the discipline where all external aspects, the view of the product into the market place where that function is managed. So, everything from “Hey, what is our key messages? How is my product different from any alternatives that would be in the market place?” Yes sure, there are competitors but an alternative could be do nothing or continue to do it manually, we offer a degree of automation. So what is that savings, or what are those benefits and how are those benefits realized by the customer and qualifying that and quantifying that, that’s product marketing.
Also from enablement perspective, like going to market, how do I best equip my sellers, my distribution partners on how to just talk about our products and what the value proposition is with the products. What is the packaging of our products? So as we all know, customers buy solutions, they want answers to problems, they don’t tend to buy products, they buy solutions. And so a solution can be in a package of a couple of products, a couple of features maybe some services, and then by the way, maybe there is a partner or two that helped them realize that value. The product marketing manager will set up the product packaging and solution packaging accordingly.
And then also finally the product marketing manager will also drive pricing. So, how should we think about pricing? How does it compare to the value that the customer will receive for the product?
And then the last bit if I can, Martin, product marketing, also does enablement into the field whether it is an analyst relations from a public relations, or press covered perspective, a product marketing team will also represent that message into those venues as well. If I can just a couple more points…
Scott: I got technical communications. What is that? That is basically anything that is written down from a technical user guide perspective in the online help, my team is responsible for that.
And then finally last but not least, the most exciting part is the user experience. I have got a set of user interface designers here, you can imagine today, all the different forms of communication that are being used by enterprise employees today in global firms, whether you are healthcare firm, a pharmaceutical firm, a global banking institution, how many different channels they use. Imagine the analytics and the views of that data if you are trying to run an inquiry, investigate a matter, all the different visualizations of the communication patterns. So we focus a lot on what’s that experience look like, how do people zoom into the data, per custodian or per channel. I am also responsible to encapsulate that user experience and communicate those requirements for engineering as well.
Martin: Okay cool. I mean this is totally, I would say typical structure besides this technical documentation thing from the product point of view.
Scott: Just quickly on that point, what we tried to do is anything that the customer touches, feels or hears about our product, from a UI, from documentation, from product literature, from our website, our branding, rolls through the folks on my team.
Martin: You’re right, I mean this comes I guess from the philosophy of having a service design that we are delivering to the customers.
Scott: Yes, absolutely.
BEST PRACTICES FOR STRUCTURING & LEADING A PRODUCT TEAM
Martin: Based on your experiences, what are the best and worst practices in structuring or leading the product team?
Scott: I think just from a structure perspective, it’s a philosophy. I think there needs to be a focus on the customer, and a focus on the problem that the customer is trying to solve. I think one of the, sort of the learnings that I’ve had is that sometimes we get too narrow focused on the feature and maybe one customer is driving us down this feature and that may be very important for that one particular customer.
The product management team with input from not only the field organization but product marketing, industry analyst plus our own primary research that we might be running, helps product marketing create a more holistic view of their product and value of their product and what are the competitive alternatives to your product that might be emerging around the corner.
There needs to be a balance and I would say the best practice needs to be that maybe 50% of your time is focused on the next series of releases coming up. But what I have learnt is that 50% of your time needs to be looking around the corner. You tend to get focused on what’s right in front of our nose, and not really what’s around the corner. And that leads to a little short sightedness where we tend to focus on the trees versus the forest. If there is a best practice there, one best practice that I have identified here is to make sure you have got ample time looking around the horizon.
Martin: Okay, good. When you look at your teams operations, what metrics do you look at to measure team and product performance? Especially for example, if the business value is very hard to estimate, and why are you looking at those metrics?
Scott: Yes, so there is a couple of things that I tend to look at.
First off is what I like to call request for enhancement. So we design a product, we release that product and what happens a lot of times is, there are obviously short cuts made. Time is not infinite, resources are not infinite, and we have got a series of gates within the budget of the program. And so obviously there is prioritizations and short cuts taken. And so what I want to make sure of is that my team is looking at what’s called the request for enhancements. So these could be enhancements that are coming from the sales team, could be enhancements coming from the customer via technical support or could be coming in from any number of people that are interacting with our product. How many of these are we receiving per week, per month, how many of these are you looking at, what is your volume to address those RFE’s. So the RFE’s in understanding the request for enhancements is also important.
Number of bugs is another thing I track on a weekly basis. So how are we tracking on our product quality? And so, is the product management team, how many of them are they looking at? I am not saying that the product manager has to go confirm that it is a bug, but they need to look and understanding and create some field on what is the quality and where are people getting stuck in the product? That’s point number 2.
And then finally point number 3 for me is the number of customer meetings that my team is having. And so what I want to make sure of is that there is one foot in the product team here internally, but to make sure, we always have a perspective for the market and the customer within that market that they are taking direct customer meetings, and how many customer meetings they are having.
So that’s on the product management side, so just to review number of RFE’s, number of customer meetings, number of bugs actually handled and touched by the product management team.
On the product marketing side, we tend to look at 2 very important statistics; one is sales qualified leads. If you think about product marketing, right, they are generating content that take customers on a journey to learn about the problems that they have in the market place, but also, what potential solutions are out there to this, of which Actiance might be one of them.
As we think about omnichannel, people coming to learn about Actiance, whether it may be from a session that we are having right now or maybe they might be hitting our website, they might be hitting some syndicated content, all of these coming from product marketing. We tend to look at very closely sales qualified leads that are coming in on the week, what content is producing that generated those sales qualified leads. We also look at what’s called marketing qualified leads, and those are raw touches to our content, and so MQL’s and SQL’s are what I evaluate on a weekly basis with the product marketing manager.
Martin: Understood. Cool, Scott! If I am looking at this matrix regarding the product management that you named, they seem to be only quantitative, but I don’t see a qualitative aspect in it, meaning that it translates to business value. For example, it’s very easy for me to have 100 or 200 meetings with customers without learning anything, or improving anything on the product.
Scott: Yes , so absolutely. These are matrix that we look at on a weekly basis. So I would say this is value in doing what’s called the benefits realization exercise with the customer, comes in the form of case studies, in a way, how many case studies do I have? So we clearly have a goal to produce case studies and success stories where we actually qualify and quantify the business value of the solution. We tend and want to produce at least one of those externally with the customer that’s available with the customer. We have a goal of one of those a quarter that we produce every quarter, and that’s a combination of product management and product marketing, working with the customer to get an agreement to talk about their success in the market. So that’s one goal that I didn’t mention that I certainly in there.
The other one is basically our billing goals and our revenue goals for the firm on a quarterly and annual basis. Clearly, if we are not delivering value for the customers… We are a subscription company, so that means, every year we are going back in and confirming with that customer that they saw value in our solutions and they are willing to sign up again. And so, I understand what you are saying about qualified measure of value, but ultimately the measure of value is am I able to secure a renewal in 12 months.
Martin: Yes, you are looking at the churn rates. Okay, cool.
Scott: Absolutely, 100%.
Martin: Okay cool, Scott.
Scott: And those term rates, just so you know, we observe our churn rates very carefully at the company level. And so the product managers are looking at that as well. And so those are things that are top of mind. But specific to the PM on a weekly basis, what I am looking for are these sort of very focused sort of quantitative data to make sure that they are being engaged.
PRODUCT DEVELOPMENT PROCESS AT ACTIANCE
Martin: Scott, you talked about the structure of your product team, now I would like to learn a little bit about the typical product development process in depth. How you are redoing it? So that our readers can understand the day to day in product management operations.
Scott: Yes, so on a day to day on the product management side, so we follow an agile methodology. We have got a SCRUM leader role in engineering, we have got a product leader, that is the product manager that is involved in daily meetings. So we have daily stand ups where we are going, and these are meetings that, these meetings will last anywhere between 30 minutes to an hour every day on that particular aspect of the product. There is a constant review of where we are stacked in the prioritization of the job jar. We also have that meeting to understand challenges that might be happening in the particular monthly release that’s going on. So that happens every day.
Once a week we have what we like to call an elaboration session. So whether it happens to be elaborating on this month’s release or the next month’s release, we’ll tend to focus on areas of upcoming features that are intended to be delivered. And that session is an opportunity for the product manager to walk through the user story. We’ll typically have a wire frame that goes along with that, and those elaboration sessions happen on a weekly basis.
Second to that is we tend to have a user experience design SCRUM on a weekly basis, where now we are taking the same user story and we are walking both the product manager through with the user experience designer and the UI implementer on what the user flow needs to be and what data needs to be on a report, what’s the orientation of the graph, or what color pallet are we going to use? Are we going to change the color pallet? And those meetings happen every week as well.
Martin: Okay, interesting.
Scott: And then obviously you guys, you know not to get in the full death cycle here, but just to throw it out, there is a plan of record. Obviously the plan of record changes based on challenges, change in priorities. There is an early bill, product management gets a what we would like to call a PM preview, we get those pretty much on the third week of the 5 week sprint for example, we get to see the software, we get to interact with the software and have an opportunity to make changes, we are getting kind of late in the cycle, and the quality and performance will take over from there. And then it gets handed over to our network operations team, and the network operation team, they get another round of quality, and now I am in like the fifth week of the release and then it ultimately gets moved into production.
Martin: Scott, are you using a centralized or a decentralized roadmap planning process? What I mean by that is are all the tickets or what you said request for, what was it? Opportunity or so, are these sent to a central point where then it’s prioritized and then distributed again to product managers and then developers? Or is it that you are giving some kind of topics where the team is managing their roadmap totally and independent of you for example?
Scott: Right, we use a centralized approach, so we have a product, we use the Atlassian product set, internally here. So Atlassian has a ticketing mechanism, there is also a collaboration system. So the ticketing mechanism is JIRA and that’s what also used by our customer support team. So as things come in, those need to be ticketed, they are ticketed in Salesforce first but if they need to be escalated into engineering, that’s when they use the JIRA system. My team gets access to the tickets, they see what’s going on and they see what’s being handed over in the engineering, and our sustaining engineering team will look at those and work on those. Parallel to that is the Confluence aspect of the Atlassian set. Are you familiar with Atlassian?
Martin: Yes, I know JIRA and I know Confluence.
Scott: And in that case on the Confluence side, is that’s where we tend to post our user stories, our product management artefacts, that’s the venue by which we drive these weekly elaboration sessions, and all of that is centralized.
Martin: Okay, understood. I was asking because since some companies are also starting to decentralize that because of pushing down ownership down to the team.
Scott: Well, so what we did talk through really is that Actiance has essentially 3 products, and they all have different aspects, not to get too deep here instead of the Actiance use cases. ut we have one Bproduct that does the blocking data loss prevention, is it appropriate for you and I to have a Skype session today, yes or no. Maybe you are a financial analyst and I am a broker and I am not allowed to talk to you. That’s one product or a set of products over there. What I tend to do is I have PM’s that are organized at the product level and I also have product managers that look across (again, that forest through the trees thing) a more foundational data structure level and working with our technology office to drive standards across the products.
ADVICE FROM SCOTT WHITNEY TO PEOPLE INTERESTED IN PRODUCT MANAGEMENT
Martin: Imagine, you are young again Scott and interested in building digital products, customers really love. What would you like to share with people interested in the product management career?
Scott: I think one of the things that I have learnt being in the industry plus 20 years now, it’s the certain notion of keeping it simple. One of the things that, as we all look at sort of modern consumer products, and some of the user interfaces and the capabilities, they focus on the 5 things that really matter for the end user. And if I think I go back to some of the early days and enterprise software, we tended to throw everything in on the very first release, and expose everything on the user interface because we were so proud if its capabilities and wanted to show case it. And I was worried about this particular competitor coming in with all that. But ultimately I think it’s far harder to design simple, elegant, just the right feature for the customer to get their job done and expose those first 5 features, than it is to just throw everything in.
And so it’s that sort of twist in that pivot that, as we are designing, and I think a lot of your designers right now are sort of picking that up now – just because I can do 100 things doesn’t mean I have to have 100 things on the UI. There is different places for that functionality.
And I think less is more.
Martin: Totally agree. So thank you very much for your time Scott, and for sharing your knowledge on the product management.
Scott: Thank you, Martin. I appreciate the opportunity.
THANKS FOR LISTENING!
Thanks so much for joining our 21st podcast episode!
Have some feedback you’d like to share? Leave a note in the comment section below! If you enjoyed this episode, please share it using the social media buttons you see at the bottom of the post.
Also, please leave an honest review for The Cleverism Podcast on iTunes or on SoundCloud. Ratings and reviews are extremely helpful and greatly appreciated! They do matter in the rankings of the show, and we read each and every one of them.
Special thanks to Scott for joining me this week. Until next time!
The concept of business process reengineering (BPR) is to rethink and break down existing business …