Product Hero: Stephanie Tanner, Principal Product Manager at CA Technologies

 

Product Hero is our bi-weekly series that highlights 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 Stephanie Tanner, Principal Product Manager at CA Technologies.
In this episode, Stephanie discusses:
Making a major culture shift from a delivery (output) focus to an outcome focus for customers and users.
How the ways in which we talk about and measure success in product management have changed.
The importance of context and communication for product managers. Can you communicate the context and “the why” behind the work that you are doing clearly enough so that your teams can make the micro-decisions to ensure that the best solution possible is delivered to the customer?
Listen to the Show: http://traffic.libsyn.com/thedirt/Stephanie_Tanner_FINAL.mp3 Download the MP3
Subscribe through RSS
Subscribe on iTunes
Subscribe on SoundCloud
Subscribe by E-mail
Show notes: Connect with Stephanie on LinkedIn.
Follow Stephanie on Twitter.
Follow CA Technologies on Twitter
Learn more about CA Technologies
Do you know a Product Hero that we should meet? Are YOU a Product Hero? Drop us a note or hit us up on Twitter.
Podcast Transcript: Heath: You’ve been in product it looks like …
Stephanie: About five years now.
Heath: About five years, okay, so tell me about your start. How did you get started in product?
Stephanie: Yeah, so I started in college. I did a CS Degree. I was always interested in the user and focusing on how they interacted with products and computers, and so I got very interested in human computer interaction and almost went to grad school for that, but when I came to Rally Software I saw that there was a role, User Experience Designer. We had a Director of User Experience at the company.
About six months into my engineering role I worked with my manager and the Director of UX to start a mentorship for UX for myself so I could learn a little bit about how they do it in corporations, in product companies. I was able to take a highly requested feature and talk to users, talk to a couple stakeholders across the company and design a better experience for this highly requested feature that already existed in the products but there were things that we could easily make it to be better.
At that point I was able to use my hackathon time to develop that and demo it at the hackathon demo and eventually a team took that into productions. That was my first foray into product management, even though I was kind of doing the UX side of things for a while, and then I started doing UX and development … was 40% time on my development team as a Uxer and 60% as the software engineer. Our product owner left the company and recommended that I take over in the interim, and at that point I realized that you didn’t need all that many years of experience to be a product manager. All it took was passion and understanding of the user, and I applied for the job and became product owner at that point.
Heath: Yeah, it’s interesting. You hit on the lack of a requirement or need of years of hardcore product management. I mean there are some people that would say they even seek out people who don’t have too much experience in product management for a host of reasons; number one, they like people who are learners and they feel like if they’ve been in product too long they’ll reach a point to where they feel like they have all the answers and they’ll stop asking the questions why or asking the good questions.
Secondly, just there is no official and certainly no curriculum for product managers, right? We all sort of got there through a different path. A lot of them like yourself took an engineering or a code or developer path, and others like me for example took more of a software implementation and training background, and at the end of the day we all ended up in the same place because we were the ones that kept nudging and asking, Well why do we do it that way, and who cares if we do it that way? Do our users care if we do it that way? What is it that they want us to do? It certainly in keeping with what we’re finding in our interviews.
Stephanie: How interesting yeah, and I would say that is something to really pay attention to I think, when you start feeling like you know all the answers. That’s a scary place to be because then you stop being as curious as you need to be to be in this role.
Heath: It’s actually being comfortable with and relishing not having the answers and the ambiguity that really makes for a stronger product leader.
Stephanie: Yeah, and I’ll add that I think I went through what I call my quarter-life crisis, and at that moment … before my crisis I believed I knew everything and after my crisis I suddenly realized that I knew very little. It was a dramatic change in my perspective, and I feel like I became a better product leader because of that experience.
Heath: What are your biggest challenges in your role and what keeps you up at night?
Stephanie: Yeah, I think you know I mentioned a little bit about self reflection and self awareness. I think that’s one of the biggest challenges that I have around not … I wasn’t very good at self reflection for a long time, and then I had a moment where I had to really understand, How were people perceiving me? How could I become a better product leader? and so I constantly look at my ability to get feedback from other people and to listen to that feedback in order to take those inputs and become better for it.
The other thing, the biggest challenge that I would say that we as an organization are facing right now, we’re working on making a shift from I would say delivery-focused to outcome-focused. As an agile organization we’ve been very focused on execution and ensuring that our engineering teams have the features and are able to deliver those on a regular cadence to customers.
However, I think that we’re starting to realize that we really need to become more focused on the outcomes of our customers and for our users so that our features that we launch are that much better and our product becomes better for that. I would say that is a major culture shift that we’re going through right now and it takes a little bit of time.
Heath: It’s not about getting x number of releases out. It’s not even necessarily about getting these five features in the next release.  It’s, What’s the outcome of all of that? Are we meeting our user’s needs? Are we meeting our numbers? Are customers falling in love with our product?
Stephanie: Yeah, I call it, outcome driven product development, and I think it’s something that’s not just for the product manager to do. It’s the whole team. The whole team needs to understand the outcomes that we’re driving towards, and they need to be as accountable as a product manager for achieving those outcomes.
Heath: What does CA Technologies do?
Stephanie: Yeah, so CA Technologies is a huge company. I think there’s over 11,000 people, so it offers a wide portfolio of products to help companies build better software faster, and that’s ranging from portfolio manager offerings to security automation as well as mainframe.
The product that I specifically work at is CA Agile Central which was formally Rally Software, and that’s a project management software for agile teams and organizations.
Heath: Can you describe your product team’s relationship with the users? How do you do user testing and solicit feedback from users? What kind of user research do you do?
Stephanie: Our teams are very focused on our users I would say every step of the process, so we’ll start with, when we realize that we want to start on a new initiative we’ll have a discovery process that we go through where the product manager, me and several other team members will work with customers to understand, What is the problem that they’re facing? What should the scope of this overall initiative be? So we partner with our customers at that stage.
Then we’ll also have an idea management system where customers can go at any point in the process and input ideas and we can have conversations ad hoc around those ideas or around a specific area that we’re looking to improve. Then as we go into feature development we’ll do data processes where we’ll have a group of customers that are looking at some of our early mock ups and giving us feedback, and then as we get working software out there they’re the first to actually try the software.
We use feature toggles to keep that functionality away from the rest of our customers in our user base, and then we’ll also have feedback after we release the software data and we’ll talk with our users around what do they like about the feature, what would they like to see improved so that we can continue to improve those features after they release.
You know we have a big sales team that has huge relationships with our customers and our users as well, so we have I’d say a good bench of users to talk with, but I think some of the hardest opportunities that we have is how can we get access to those users that don’t talk to our sales teams that are some of the users that probably don’t like using our product the most. We want some of that feedback of how can we make their lives better. It’s actually quite a challenge to get at those people because they’re even less likely to want to get on the phone.
Heath: Yeah, and those are the ones that are probably most at risk. It’s the silent un-happies that you have to really, really be disciplined to seek out their input. What is the relationship between product design, marketing design, engineering in your company? How does the information flow between you? How are you structured to handle that feedback and get that into your products and out to users?
Stephanie: Yeah, with our sales teams we have a monthly meeting. We call it a meet with products where we invite them to a session. That’s really for, it’s two-fold. The first half of the meeting we talk a little bit about our strategy, the initiatives that we’re really focused on and to seek feedback from some of the things that we know that we’re getting ready to develop and launch.
The second part of that is problem pitch time where we give our pre-sales organization the opportunity to speak up in front of all of their colleagues as well as the product team to communicate what they’re hearing from their customers and from the field, and to gain some understanding if that’s a shared problem or if that’s something that’s just unique to their own customers.
What we do from there is we give them an opportunity to vote at the end of the quarter on the top things, the top ideas that their customers have so that we can create our top ten customer voice needs from our sales teams and marketing teams. On the flip side of that we also do that with our external customer-facing idea management systems that we have their list as well and to help us determine how we’re going to use our customer voice spend throughout the quarters, but the other thing that we do in order to ensure that we are collaborating across engineering, marketing and design is for every initiative that we work on, we create an initiative team that is led by a product manager.
We’ll have the development team leads on the team as well, as well as an architect and a UX designer and possibly someone from marketing as well to represent that side of things so that as a team we can define what’s the work that we need to do to achieve our outcomes for this initiative? How can we scope it? What decisions do we need to make in order to ensure that we’re delivering value to our customers?
It’s a small team so that we can make quick decisions, so probably around five to seven people in this core team. Then as we start development and execution we’ll broaden that team to the full development teams that are working on it in order to ensure that their input is heard and that they understand the context of where we’re going and why.
Heath: You guys make use of probably roadmaps that are more now, next and future or later, or how do you break things up on the roadmap?
Stephanie: Our roadmaps, we generally the first quarter we’re focusing on, Here are the features that we’re delivering this next quarter. We’ll have an idea about the following quarter what some of the features are as well as maybe an initiative that we’re starting, so we’ll become a little bit more vague when we talk about that second quarter, and then the third quarter is really just, Here are the initiatives that we believe that we will be starting at this point in time. We can give you a little bit of information about this, but we try to, it’s pretty vague around what that looks like because we know that our direction may change a bit, so that kind of seeds our conversation with our sales teams as well as our customers when we talk about our roadmap so that we really focus on the here and now, but give them insight into where we’re headed into the future so they have an opportunity to respond to that.
Heath: Back when I was doing park management, the roadmap looked more like what we’d call today a release plan, and it had hardcore dates and even releases assigned to them. We had conditioned not only the sales organization but lots of times customers to expect feature x, y, z and V7.2.0 instead of looking at things as, Look, this is what we’re delivering now. This is what block of functionality is next and then this is the stuff that’s later. We’re really not sure when and it might change. It might stay in later. It might fall out based on what the market tells us, based on what sales tells us, based on what our users are telling us.
Stephanie: I would say that we start every roadmap presentation as well with a statement that’s saying we’re an agile company and we have a steering meeting every single week where we talk about what’s on track and what’s not on track. There are times we have to make decisions and pull features out because we know we want to swarm on a feature that’s really important for our users … Or we might do so well that we bring stuff in. We try to set the expectation with our customers that this is a living breathing roadmap. It’s not something that’s never going to change.
Heath: What’s one of the biggest product measurement mistakes you have made or you maybe have seen either at CA or in a past life?
Stephanie: Yeah, I want to talk a little bit about a feature that I created that I managed called Milestones. Basically it’s a name-to-date within a product and my biggest mistake with this one is I didn’t focus on a single use case for the feature. I focused on, What are all the ways that a user could use a name date? Well, you could use it as a developer as a deferred appointment object or you could use it as a release train engineer or program manager for a planning cadence, or you might even be able to use it as a conference you know, an important date within your company. CA World is coming up in November. We might have a milestone for CA World, and finally it might be launching version 3.0 and you could use this object for that.
There’s a lot of use cases that I was trying to design for and I ended up delivering functionality that was kind of battered across all of those use cases and didn’t really get at the single use case and the single persona really well. This caused us to build a feature that very few people could really truly adopt and the architecture was then extremely difficult to change. I would say if I was able to go back I would really focus on that single-use case and that single persona, and ensure that for those customers that we were supporting something that was really perfect for them, what they were asking for. Then we could focus on expanding functionality after that initial release.
Heath: Products that you admire, what are one or more or some that you either use or you’d use if you had a need for them but you really think they’re kinda cool.
Stephanie: Yeah, I actually wanted to start with a product that’s not in software. I want to say that Southwest Airlines is a product that I extremely admire. I will fly them no matter what if I can if they’re going on a route that I’m going to, a city that I am going to I will fly Southwest. I think that’s because they’re an extremely transparent company about who they are and what experience they offer.
Everyone who works at Southwest always has a smile on their face and a lot of their flight attendants often times make jokes to make things a little bit less stressful on the airplane, and I think it’s an extremely delightful experience.
The other product that I’d like to talk through is GitHub. I think that GitHub is amazing at what it does. I don’t really use GitHub myself but I know people that love it. It creates openness and again, transparency within the development world, and developers absolutely love the product. I admire any product that absolutely understands who their customer is and serves them to its fullest extent.
Heath: I don’t know why. I want to have that seat. It’s never in first class and I’m always in coach, so it’s not like I’m missing first class, that’s for sure, but I don’t know what it is. It’s just like being lined up in a cattle stall of folks not really knowing am I going to get that seat that bugs me, but I’m fortunately not, well fortunately for me not a heavy traveler, but I totally get that people can be fiercely loyal to their airline, typically if their airline is … even in cases where the airline … it’s not as if the airline is succeeded and never been late. It’s that they’ve always done right by their customers, so even when there’s a screw up right, as long as they recognize and to your point, they’re transparent, they acknowledge it and make it right one way or another.
Stephanie: Yeah.
Heath: … so interesting.
Stephanie: For me with the airline I always wanted to be in the front and for a long time with all the other airlines, until you use them for long enough you always get in the back or it feels like you always get in the back, so I felt with Southwest I could choose to be in a middle seat but still get to the front if I wanted to.
Heath: How would you think product management has changed since you got started for better or worse?
Stephanie: Yeah, so I’ve been in the same company pretty much my entire product management career and we’ve been very focused on agile. I talked a little bit about this when I was talking outcomes versus outputs, but I really believe that five years ago we were very focused on delivering on a predictable cadence and ensuring that we could communicate to our users that this feature was getting out by x date.
Now that we’re starting to discuss and talk through what it looks like to measure success, and not only measure success but before you launch but continuing to measure success and continuing to iterate until you actually achieve that success. I think there’s still a ways to go in the industry for how we measure success and how we talk about success, but it’s something that’s all of a sudden a part of the conversation and I keep hearing it from product managers all around. I need to be able to measure this quickly and I want to be better and I want to achieve my outcomes. I think we’re going to see a lot more of that in five to 10 years as well, more organizations talking about this, more product managers talking through this as well.
Heath: How do you guys measure success, product success or success of the product team?
Stephanie: Yeah, as a SAS company we have usage metrics on every page and feature within our product, so depending on what feature or initiative that we’re working through we can create goals around selves of what do we think the usage should be for this new feature or this new page, and we can look at those adoption rates as we go, which is great. I think that’s a huge value within SAS companies.
We also have usability metrics for each of our initiatives. For instance, I was working on an initiative around our new team board, and our metrics around that new team board experience was teams can get started with the new board immediately with no questions asked. They can just get started, but they could also customize that process under two minutes and that teams can get one-click access to metrics.
We focused on these metrics because it was these getting started experience that we were really trying to get better and we really focused on that piece to it. I think when we look at product managers and how we look at success for product managers, it’s really around can you communicate the context and the why behind the work that you’re doing clearly enough so that if your teams are working they can make the right micro decisions right when they’re in the code to ensure that the best solution is delivered to the customer as possible. I think that dot focus on context and communicating the why is extremely important for product managers.
Heath: That’s awesome. I haven’t heard one like that before, both the use metrics but sort of more importantly I guess you call it the inward focus on team feedback. Do they understand the why enough to be able to make some decisions on their own or do you always have to come back to the drawing board and say, Okay, we can’t do it this way. What do you want to do now, product manager?
Stephanie: I definitely believe that as a product manager, my decisions and my beliefs around where we should head with the product are not necessarily the best ones. I think that engineering and developers have amazing ideas for what can be done, and if you just harness some of that thought you can build something that’s even better, and so that’s something I really focus on and I try to bring the entire product development team into that decision-making process in order to make better products.
Heath: What’s missing from the conversation in product management now would you say?
Stephanie: I think that what’s missing from the conversation with product management is really around that entire development team. I think we’ve gotten into a situation where a lot of the times the product manager feels like it’s their job to know all the decisions and to make those decisions and be there for the development team. I think that if you can get the entire product development team to focus on operating more like a start-up and maybe the developers are running interviews or talking to customers. Maybe you are validating problems as a team. Then you can have conversations about, Based on this problem we’re seeing, what’s the best way to solve that?
I also would love to see more I guess a concept I call feature slack. Slack is something that we talk a lot about when we talk about development teams not working more than 80% utilization rates within the agile world. I think that if you had slack around features, it could really solve a lot of problems around measuring success.
For instance I’m delivering a feature. I get it delivered. As a team, we don’t start on the next feature right away. We actually take a moment to breathe, to collect some metrics. Maybe the team can work on working down that technical debt while we’re waiting for those metrics to come so that we’re not trying to find spaces here or there in order to improve that feature now that it’s released, that we can really focus on making it the best feature that we can.
One of my favorite things to do when I was a developer was let’s say on a Friday if I finished my story, instead of starting another user story, looking through some of the defects that existed to find something that I could accomplish in that half day to bring some value to our customers to solve some glaring problem and just move on and be ready for Monday when it came.
Heath: What advice would you offer someone who might be looking to become or considering becoming a department manager?
Stephanie: One piece of advice I would give is you don’t need a lot of experience. Really it’s just around understanding who your user is, so get as close to the user as you can. If you already work for a company that builds a software product, get on the phone with the users or maybe shadow another product manager on a call to understand and listen to what they’re saying, and find out why they love your product and what they’d like to see improved.
If you want to you can go ahead and try designing the change and testing the change, pitching it to someone and continuing to go, so I guess it would be to just start doing the job as product manager even if it’s during some sort of hackathon break or permission from a manager to see if it’s something that you want to continue trying.
Heath: Awesome.