Series: What does Product Management Mean?

Digital Strategies:Tell us about your background and how you came to work as a PM.
Seemant Kulleen: I fell into being a PM, it sort of happened by accident. I had been managing customer support and engineering teams before that.
My first PM job was at an enterprise software company where I was hired to help turn around customer support. There had been a lot of recent customer attrition for the company, and partly this was because they hadn't really wrapped their heads around how to do support. It took about four months for the team to really turn the corner.
“The biggest role for a PM is to maintain openness and to really understand people's inputs.”
I moved on to being a PM because a big stimulation for me when I work somewhere is that I want to change things, and not work in maintenance mode. It turned out that much of what I was doing, when in my customer support role, was what a PM should do, so that's what I moved on to, though I hadn't done it before. Another driving factor was that now that we had the customer support team working more smoothly, the main reason for customer attrition had shifted to product experience.
DS: How did you move to doing data viz work?
SK: I had run engineering teams before. I had also done some D3 development and then that led to where I am now. I do data viz primarily for nonprofits. It's the idealist in me - I got sick of doing marketing dashboards. I definitely had not realized how very energy intensive the whole process would be, and I really needed to take a break.
DS: What was your previous experience with working with product managers? How did it inform the way you worked as PM yourself?
SK: I had worked with a PM team prior to being a PM myself. To be honest, these experiences in the past had left me with a very cynical view of PMship. I found that the PMs didn't leave their desk; as a member of the customer support team, I found that I was was virtually doing the real work of a PM because I had to relay customer support feedback to the engingeering team.
I also had very PM-like experiences when I managed developer relations for the 250-strong Gentoo Linux developer base; this was a very interesting and challenging experience because there was no face-to-face contact, as all the developers were spread across the world.
DS: In our own experiences as PMs, we found that many people would ask if we thought they should get an MBA. We don’t have one, so that was usually our answer. What do you think?
SK: I don't think that you can get an MBA which is trying specifically to turn you into a product manager - the closest to a certificate is a PMP certificate, which is of course for project, not product management, and that’s a very different set of skills and responsibilities. I think the the idea with an MBA is that the PM to CEO is a jump that's easy to make if you have the degree. It is largely motivated by that.
DS: Without formal PM experience, without having recourse to any literature or training, how did you know what the right goals to set were, for yourself and your teams?
SK: When I started working as a PM, I basically took stock of the situation - there was a team that had been in place, but they had just left the company. We had about 60 engineers, globally placed. In addition to taking over an orphaned PM team, I took over the QA and Documentation teams simultaneously. Fortunately, all three responsibilities nicely dovetailed with each other.
“To figure out my PM strategy, I followed a structure called Observe, Orient, And Act (the OODA loop)”
To figure out my PM strategy, I followed a structure I had learned about called "Observe, Orient, And Act" (ed: This is a strategic model popularized by USAF Col. John Boyd, and is also known as a the "OODA loop," used in combat operations planning.) I found that the typical interface for our engineers was our "ticketing system" - so I started with looking at the system, what was closed, ignored, handled etc. I was dealing with what had been designated as a "roadmap queue" with 800 tickets. So my primary goal was to cut that down to 25. This kept me working late hours for a while, but it really helped me go deep, when I read every one of the 800 tickets - that was the best way to learn what the technology was about.
The second thing I did was to get direct customer input; a lot of SaaS customers had free trials so I reached out to abandoning and non-continuing customers, to fill the negative space. I started having weekly parties at the company HQ. We brought whisky and beer to the table and just let the developers (that is, our customers) talk. The biggest role for a PM is to maintain openness and to really understand people’s inputs.
DS: What change did you see in the company, as a result of these actions?
SK: It made justifying features a lot easier - our customers and issues became "self-reporting." We had a team of customer support engineers who knew a lot about the technology, because they had spent so much time duct-taping the product. I got them to pair on building features to spread the technology experience across the teams. Incorporating their narratives into the mix resulted in a growing closeness between the engineering and the support teams.
DS: The previous PMs must have had their own processes. What did you keep or drop?
SK: Some of the powerful stuff was how they had arranged time schedules and delivery schedules. They had also done a lot of good work in creating the large ticket queue, even though it was unwieldy. There's this idea out there in the PM world called "ticket bankruptcy" - the idea that all tickets have to be thrown away, but it's a scourge because it becomes an easy win. But the mess encapsulates a lot of pain which we don’t want to repeat. Ticket bankruptcy needs to be illegal! Where they faced challenges was in creating a cadence in releases. Customers like to have a heartbeat, no matter what it is - regularity is key.
“The idea of "ticket bankruptcy" is a scourge in the PM world.”
DS: What strategy did you take to clean up the system? Why did it not happen again?
SK: Lots of sleepless nights. I left with a VP of PM having been hired, and there's now a PM team. All my predecessors came in facing this ticket queue and didn't fix it, I think someone fixing it has helped teams maintain it going forward.
DS: On a more general note, how do you know what product opportunities to pursue? How can PMs make sense of the changing product landscape?
“You get a lot of "how" and "what" inputs, and the job of the PM is to turn them into Whys.”
SK:No matter how simple your product is, there are 2 parts - the fixing of broken things and its ongoing evolution. You have to figure out where inputs come from - where things are difficult is to understand the Whys. The good part of having a QA team for me was to get someone to keep asking "Why?". By asking Whys for customer inputs, you can start to find common threads - you get a lot of inputs that are in the form of "how" or "what" and the job of the PM is to turn that into a Why.
DS: How did you get to the why, typically?
SK:It really involves engagement and conversations, so if PMs don't leave their desks then they can't do engagement.
DS: When you get to the Why in a feature or idea, how do you approach the solution to it?
SK: I actually didn't get that far, because I put the process into place and then moved on. Speaking intuitively, it was about communication, sharing the Whys with the team, telling the engineering team these stories. The PM is the nexus of conversation.
DS: What worked effectively in this interaction?
SK: One thing PMs should note is that the fuel of good product management is trust. Whenever there are difficulties in a team, this means there is distrust, and I found that one way to be effective was to redirect traffic from top-down inputs to the engineering team. I was good at summarizing input and could show that I understood where the team was coming from as well. This really builds trust and that's what drives a lot of the interactions down-stream.
DS:What are the key skills a PM should have?
SK: Definitely, listening. Curiousity. There's a quality analysis method called the Fishbone Diagram method, that says to ask Why to five levels - do that as much as possible. Don’t be afraid of a ticket queue, no matter how long it takes. PMship goes beyond your desk and beyond 9-to-5.
DS: What is your opinion of the idea of being data-driven, for a PM?
SK: There is the old Disraeli quote - "There are three kinds of lies: lies, damned lies, and statistics." Data is a form of story-telling and any time you tell a story, it's going to be chock-full of lies. It depends a lot on what sort of data you are gathering. If you have a poll to figure out what features to build that could be the wrong way to go about it - it becomes a popularity contest and all it does is give customers a way to tell you a "how" or "what" but not a way to figure out "why." That's still your job as a PM.
DS: How did your role as a trust builder evolve?
SK: I have been doing "emotional healing" for technical teams throughout my career. I made sure I had 1:1 time with everyone, and I took advantage of the fact that some of them had been there since the get-go of the company. They knew so much about the product, and why the technology and the team were the way it was.
This helped me paint a picture of why employees were unhappy, and when customers are unhappy, there's a chance that employees are. Some of it was that employees were seeing repeated broken promises because of high management turnover. I made myself the "emotional lightning rod."
DS: What are your philosophies about leadership?
SK: It's tough. It's by-example, never a do-as-I-say. Leaders can be afraid, but even so, they have to take risks, and they should not worry about showing that the risks make them afraid. Honestly, I don't think I followed my own advice enough - I didn't take as many risks as I think I should have, and didn't manage up, when it was necessary. A big part of trust is facing the common enemy.
DS: What resources would you advise people to read to learn about PM and leadership?
SK: Richard Branson is unbeatable at creating experiences people desire. Virgin Group has done so many things - he's a guy who's not afraid of taking a chance on things that people might like. The origin story of Virgin Airlines is a great case study in itself of that - supposedly, Branson was taking a vacation, and was stuck looking for a plane at a layover where the airline had stranded him and other passengers, so he went off to charter a plane to get people out. Most people would have sat there to bitch and bitch and bitch. Branson just got stuff done. In recent years, Elon Musk is someone I look up to. He can see the future and make it happen.
“Richard Branson is unbeatable at creating experiences people desire.”

Jump In With Your Thoughts

Contact Us!