Nail It, Then Scale It

Saeed: My name is Saeed Khan, I work for Transformation Labs, it's a company that I founded, and we help companies with their product outcomes and product teams and generally help them improve their product organizations.

Suzanne: And you and I have something in common, which is we're from Canada. We're two Canadians in Australia right now.

Saeed: That's right.

Suzanne: We're far away from home. What's your experience of Australia been like so far?

Saeed: It's been great actually. I landed in Brisbane, we went to Melbourne, we had the conference there, and now we're in Sydney. The only thing I'll say is that it hasn't been as sunny as I was promised. It's been rather rainy while I've been here.

Suzanne: But you're in Toronto?

Saeed: Yes.

Suzanne: I think it's snowing there, isn't it? Or there was threats.

Saeed: There's threats-

Suzanne: There's always the threats.

Saeed: ... yeah, but, you know, threats of snow are fine.

Suzanne: It's true, it's true. It rained a lot in Melbourne I noticed.

Saeed: Yeah, and Brisbane was three solid days of rain.

Suzanne: Oh, gosh. Well Sydney's been impressive.

Saeed: Sydney's been gorgeous.

Suzanne: Yeah, well let's never leave Sidney. Now we know.

Saeed: Sidney feels like Toronto, I'll just say that. So I've felt very comfortable here.

Suzanne: Now you weren't always in Canada. You left Canada to go and do the Silicon Valley thing. It's still mysterious sounding I think for people who have never been to the Valley, but then if you go to the Valley you're like, "Oh, so it's like a weird suburb with strip malls?"

Saeed: Yeah, yeah. You know it's funny, I had traveled a lot to the bay area from Canada for work, and then we, back before the dot com bust we had decided to move down there. And it's funny, it's sort of like the reality versus the fiction, so the fiction was this is an amazing place, everything is so different and everyone's so smart, and I got there and we literally landed in March of 2000, which is when the NASDAQ peaked and then started going down, and then all of the sudden I looked around and go, "Wow, it's just like home." But as you said, strip malls, and you know, the shininess that I expected wasn't there.

Suzanne: Yeah, yeah, and it's still not. It's a bizarre place.

Saeed: It's a bizarre place, although I did very geeky touristy things, like I went to One Infinite Loop, which is the address of Apple's head office and I had a picture taken. I don't know why, but it's just, you know, the coolest address at the time.

Suzanne: Was that a good move for your career, leaving Canada, being part of the US tech scene? Would you recommend that for someone?

Saeed: So I'll answer the first part, first, which is, I think for me it was really good. The technology ecosystem in Toronto at the time, this was the late 90s, was very small. I had had a number of friends who had moved down there, and, you know, lots of good stories. And then I got to do things and meet people that I could never have done in Canada. So, taking that experience back was great. Things have changed a lot since then.

Suzanne: Since November 2017, approximately.

Saeed: Well, I moved back in 2006.

Suzanne: Yeah.

Saeed: So, I think if I was younger I would consider it again, but I would probably approach it differently. I would really look at it more strategically, where do I wanna get to? We kinda went down, I got a job in the startup and that was, you know, wow, I got a job in the startup. But I probably should've been a little more deliberate about which startup and what kind of startup I was looking at, and so on.

Suzanne: That's interesting, tell us about that. If we could go back in time and chart your career with more rigor-

Saeed: With more rigor.

Suzanne: ... what would you do, what would you tell young Saeed not to do?

Saeed: No, that's a great question. So, one of the things I've learned over the last 20 years in product management and I would apply it to myself back then is play the long game. So really have a clear vision of where do you wanna be five, 10 years from now, and then make those choices very deliberately. You know, one thing that I didn't do, and I probably should've do, is I look for interesting work, which, you know, at the time was what could I never do in Canada? But I took some risks with some companies and it didn't work out as expected, and so I would've made a little more deliberate choice and maybe said, "Okay, here's the path I want, and maybe a job from now, or two jobs from now I'll get to that really great place." And it's always risky, but you know, people respect name brands, so there's all these people in LinkedIn that say ex Google, ex Facebook, ex Twitter, and somehow people think that makes them much better. Maybe they did great work, maybe they didn't. So I think I would have picked couple of name brand companies before taking risks with some unknown startups.

Suzanne: Yep. How long did you work as a product manager before you stepped into your first product leadership role?

Saeed: It depends what you define as product leadership but I think once I started managing people it was probably. I was a product manager in Canada for a few years and then I was in California, so about five years of product management work and then I started managing people as a team.

Suzanne: What changes? What changes from being a product manager to being a manager of product people?

Saeed: Well I think it's not specific to product management, I think it's general management outlook, right. So first of all it's, you turn me to we. You're thinking more broadly, you're thinking more in terms of forward, what's important. And I was much more closely aligned with the business as opposed to when you're a product manager and, at least early on I was very product focused and it's all about my product whereas later on it's about the bigger picture. And then people management is always interesting. I once worked for someone and, in fact it was my first boss when I was a product manager and he was great. He was like, I don't know if you remember Wall street but the Hal Holbrook character who kind of shepherds Charlie Sheen around and gives him words of advice, he was kind of like that and he had all of these little mantras that he would share. And it seems obvious but we'd talk about the employees as like chess, it's not checkers, you're not all the same and I know what you're good at, I know what you're not good at, we move forward and then I'll help you get better. It was just very interesting to hear that and when I started managing people that always stuck in my mind, like really get to know them and their strengths and weaknesses as opposed to focusing on just outcomes.

Suzanne: You have a talk here at the conference which I want to hear more about but you also came out and taught a workshop, the workshop was on metrics.

Saeed: Yes.

Suzanne: Did it have a fancy title?

Saeed: No.

Suzanne: No. It was just Metrics with Saeed?

Saeed: Metrics with Saeed, exactly. It was Driving Product Decisions Through Metrics. I probably could have had a fancier title but I was just trying to keep it very simple.

Suzanne: You want to tell people exactly what they're gonna get.

Saeed: Yeah, the thing that I was trying to convey is that, so as product management folk, a lot of our focus seems to be on product and you read about what people are writing and it's sort of product, product, product, product, and yet in the word product management, management is the thing that you're doing, product is the modifier. We're managing product. And so I've always been a little, just a little concerned that we don't spend enough time focusing on the management side of things and what does that really mean. Because in the end that's where the success story comes from. Like, you can build a product, but if you don't manage it well you can't succeed.

Suzanne: Yeah. I mean I think what I'm hearing you say or how I frame that is, so I talk a lot about the different roles of product manager, kind of like that business owner role, that designer role, that developer role, and not role but mindset, and so that's kind of part of it. And then the other part of it is that the levels at which we operate from those roles dial up and dial down depending where we are in the specific kind of design or delivery cycle, but that steady state is in theory the place where we get to be balanced and we get to be thinking about all of those things. It sounds a little bit like what you're saying is, we're like always in that design delivery mode or we're hyper obsessed with the work around that?

Saeed: Yeah. I think it's easy, first of all it's in the title, product, right. And then a lot of the focus obviously is, no one else is gonna work with the product team and so it's very easy to just to get involved and say we're going to get the best user interface and the best experience and our product will be rock solid and all these things, and yet there's so many other aspects to product success that don't have to do specifically with the product, right. You know, basic things like how you position, how you message, how you differentiate, who you target, how you organize and align in your company to move things forward. All these other aspects of, elements of success should be focused on. And I've seen average products, good products but not the best, do quite well. And on the other end I've seen what seemed like really good products do poorly simply because they just didn't do those other things, right. So I think we're technology focused, overly so. I think it's rampant in Silicon Valley.

Actually, if I can tell a little story. When I lived in California I went to the Computer History Museum in Mountain View and there was a talk and it was called 20 Years in the Valley, and there were like 3 early founders. And I forget who two of them were but one guy was an early guy at Electronic Arts, and there was Scott Cook from Intuit. And they gave their talks and it was so clear that Scott's perspective was very different from the other two and Scott was formerly a product manager at Procter & Gamble and then he founded Intuit and he built Quicken and he told the origin story of Quicken. And he talked about their customer obsession, how they were so focused on making sure that the product was really easy to use, and this was on a, you know, as he described it 80 by 24 monochrome character display, sort of way, way back in the early eighties.

And I just asked him a question, I said Intuit is an unbelievably successful company, you guys are very open about how you function and what you do and you have all these things like the follow me home program to really understand what customers want. Why is that not filtered through to the rest of the valley? Like it seems like a really good formula for success. And he kind of stopped and he said, first of all I'm not a technologist, I didn't come from a technology background, I have a team of developers and I work with them. And he said, but most companies are started by technologists, right, and I think their approach was very different from mine. And he said, not that mine was better or is better but it's just a natural progression, if you come from a technology background you do things a certain way and for me my background was at Procter & Gamble. So I always remembered that sort of mindset which is, like he's not a technical guy and yet he built a huge, successful company. And that's the way I always like to think.

Suzanne: All of the non technical founders listening and are rejoicing just hearing this anecdote.

Saeed: Well I hope Scott Cook is listening.

Suzanne: I hope Scott Cook is listening too, actually. Scott if you could then retweet this.

Saeed: Yes.

Suzanne: If you were to come into an organization that was just like, “metrics, never heard of them”, how would you start to establish a process around there? Like I think it would be interesting to just get super tactical for a moment in how do you start to stand them up, where do the metrics begin, and how do you do that in a way that's achievable so that you're not drowning under the pressure of?

Saeed: Sure. So I think every company has some metrics whether they admit it or not, right. So you know the one metric almost every company has is revenue, it's something they do measure and track or if it's very early they might talk about customers. You know, we have something we're measuring against. But I think to kind of get more sophisticated the way I would talk about is I wouldn't talk about metrics first of all, I would talk about outcomes and what are the outcomes that we're looking for, right. And yes, maybe they're going, well the outcome we want is more revenue, but there's a way you can decompose that. Okay, so what does that mean, how are we going to get more revenue? Oh well, we're gonna target this or we're going to go geographically here or we're going to do certain things. Okay, great, so those are the outcomes you want to achieve so how are you gonna drive there and how are you measure those outcomes to happen because not all of them are as cut and dry as dollars or whatever currency you're using. So I think I would start there.

It's really a cultural shift that you have to go through and help people work towards. And then once you can kind of help them see these small wins then you can help change them to sort of now we can get more rigorous and let's see, well why did we not achieve our target, oh well we didn't do this over here. How can we measure that and make sure we don't do it next time? And so then, you know, people, it's an awareness issue and a cultural issue and then people go, oh okay, this actually make sense. So that's the way I would approach it is, I've found always it's easy, easier, it's not always easy, it's easier to align people on projected outcomes because, yeah we all agree we want to do this. And then how you get to it is a different question but you're aligned at least in the practice of what you're trying to achieve.

Suzanne: Yeah, I mean I think that this raises such an important, it's a simple idea around data which is the collection of data and the analysis of data begins with a question or series of questions about what you wanna know.

Saeed: Exactly.

Suzanne: And that's the conversation. You wanna know when people come to the site, what do they do next.

Saeed: That's right. In fact, in the workshop I give a definition, kind of a formal definition of metric and then I give Saeed's definition and I change the formal definition and that's exactly what I say. I say, you know, a metric is the answer to an important question that helps you decide what you want to do or how you want to adjust what you're doing. And that always helps people because the question that people always have on metrics is well there's so many, how do I know. So, what's important to you, what question do you need answered, and then suddenly it becomes simpler.

Suzanne: Yeah. Are there specific best practices that you think are, like, you have to do this, you have to have these metrics, or you have to have these tools, or you have to have this approach to creating a tagging plan, or this approach to defining outcomes in your roadmap?

Saeed: Yeah. So I'll be honest, best practices come from widespread usage and then measurement of what works and what doesn't work and I can't say that I've done that so I don't want to say this is a best practice or that's a best practice. But I will say there are better ways of doing things clearly than others. I used to joke in my first product manager job, and this is nothing, the very first job I had was great because it was very holistic in terms of product and technology and business and so on, but there were three product managers and we each had a separate product line and we always joked that it's so funny how no matter what the sales target is the company meets it, but if one product did better that quarter another product did worse. So we used to say product A plus product B plus product C is a constant, right. And the idea was like, wow someone was so smart that they predicted exactly within a thousand dollars how much we'd sell, and no of course it's not true. It's we set a target and we worked towards the target and we achieved the target.

And so, you know, you take that analogy from sales which nobody argues about and then you start apply it in other areas. Say okay, if we want certain outcomes then let's set some targets and work towards them and we can always measure our progress hopefully towards that target, right, it's not always as cut and dry as sales but it works. And once people start thinking about that, yeah. And compared to 20 years ago things are much more objective focused and target focused than they were. Back then it was just you did stuff, you know? Is the checklist checked off? Yes, okay great, we're done. I think we're beyond that today.

Suzanne: You have a talk here at the conference, it's got a fun name. What is it?

Saeed: Don't Release the Kraken.

Suzanne: Can you give us the little nuggets of wisdom? Just the Coles notes for the folks that didn't make it all the way down here.

Saeed: You do know that in Australia Coles is a grocery store?

Suzanne: I also realize, you know, because I live in Los Angeles, that no one knows what Coles is there either so I have to, CliffsNotes I guess is the thing.

Saeed: Yeah, Coles is Canadian, right? Yes, exactly, yeah.

Suzanne: Yeah. And it never occurred to me until I was saying it. But there's been a few things that I've said down in the US that I'm like, like process. But everyone says process here because we're back amongst our people.

Saeed: I actually asked that in my class. I said what do you say? Because when i was in the US, when I lived there I would say process and I would get either one of two responses. One of them was, it's process. Or the other one is, you're Canadian aren't you.

Suzanne: And you're like, sorry I am.

Saeed: Yeah. So essentially when you think of sort of planning what you're going to build, and things have changed since 20 years ago and we're agile and some people don't plan as much but when companies are working on major releases and I'm talking about not just ISVs but enterprises who are building usually really sophisticated applications, or they might be under some contractual obligation to build something it's still a challenge. No one's going to build everything at once and they have to prioritize and decide how to allocate resources and there's always competing interests and what I've seen is over the years people are pretty good, they're a lot better at, once they've decided what to build they're pretty good at doing that minus some hiccoughs or unknowns or things like that.

But that decision process up front is still quite rampant with inefficiency and politics and all this stuff so and I've always found it kind of odd that as product managers our job is to analyze problems and understand what the solution should be and then make it easy for someone else to do their job whatever product you're selling and yet we haven't been as good at doing that for ourselves. And this idea of planning releases, like why is it still so political and so chaotic? So essentially I just kind of took those same skills I apply to other things, applied it to this problem that I have and, you know, I'm selfish, I want my life to be better, if I can make it better, great, if I can make it better for someone else, even better. And just apply it to release and just kind of try to simplify it into something that is very clear and cut and dry. And it's not the ultimate solution but at least it's sort of the 80% role. Like, yeah this really gets us 80% of the way and the other 20% is variable depending on your situation.

Suzanne: So distill the advice then for folks listening in who are nodding their heads and saying, yeah release planning in my organization is chaotic, it is political, how can they shift that?

Saeed: So the way I look at it is that when people think about a release often they think about, what features should we put in and that's where their discussion starts. And then they go, okay how should we prioritize these features. And that's kind of starting at the end in a way. Because a release actually is based on some directive or some road map or some objective that you have, right? So something higher level. And that roadmap, if you're thinking about a product roadmap, that's based on a product strategy, right. So the way I talk about roadmap is, a roadmap is a product centric articulation of a product strategy. Because a product strategy is more than just what you're gonna build. But that strategy comes from product objectives and that objective flows out of product vision. So there's this cascading effect and things like product vision and product objectives are sort of longer term and release are shorter term. So you have a framework already if you think about objectives and roadmap and things to narrow down what you're going to build in a release.

So that's the first step that people should understand is it doesn't start with what should we put in a release, it starts with the bigger picture. And they should socialize that with the other stakeholders if it's an ISV with sales and marketing and other people so that the context is common across the groups and then, and get the other people's context as well but now your kind of talking about the same thing. You're not thinking, oh I'm a product manager, I'm thinking long term strategy, and I'm a sales rep, I need something next quarter. And then once you get there and you say, okay we have a common understanding of this framework of thinking about it and we can eliminate some things that we're not gonna do, then you have to get into how do we do the tactical work that defines what's in the release. And then there's just a bunch of things like who are the stakeholders, what are our targets in terms of timelines, what's the core functionality that we have and why, and that should align with those higher level things, what are the risks, et cetera. And you have that discussion and the, again, it's about this common understanding and framework and then saying yes we have had a very conscious and clear discussion, we can come to an agreement.

And then what happens then is, okay you started down the right path, you've built what you have to build and when you come to launching it and making it available it's not a case of, oh this is not the right thing, we need to change it, right. You've done all that hard work up front. And you're not building for 12 months or 18 months, you know you're building for a short period but still you've eliminated that, I call it the beast. Like, there's this product that's going out and no one's going to be happy with it and when it goes out it's going to cause damage, that's the kraken.

Suzanne: That's the kraken.

Saeed: So don't release the kraken.

Suzanne: Process in general is interesting. I mean I'd love to get your perspective because there's a time when you can afford to be flat and chaotic and not scalable in the way that things are getting done tactically and then there's a time when that starts to hurt. Can you talk a little bit about where you see that showing up? Like when and where in company's life cycle does the need for process start to show up and what are some of the processes that you think are most important for product organizations to adopt?

Saeed: Okay. So let's start with this, there is one process that everybody has whether they think about it or not, it's that development process. And product managers just, it's not our process, it's engineering's process but we adapt to it. So from the very earliest days in a startup there is process. People don't think about it maybe but it exists. And so it's kind of funny because people often hear the word process and go, oh like yeah.

Suzanne: I better quit.

Saeed: Yeah, I don't want any of that. But, and so it's not to say you need process from day one but it's there whether you think of it or not. And in the early days when you're small, and when I say small I'd say less than 30 people, everyone knows everyone, the communication lines are open, you're all aligned hopefully, if you're not aligned that's a problem but you're all aligned and you know what you're doing and you just move forward as a kind of a unit and everyone goes out of the way to make sure that gaps are filled. And so you don't have a formal process because people know what to do and people know who to talk to and there's no gaps. But as a company grows, as you kind of get sort of larger, and when everyone doesn't know everyone, you know those communication lines aren't clear, then you start need, you need some structure to kind of fill those gaps. And in my experience somewhere between 50 and 100 people is when it happens.

So my very first product manager job I joined, there was 70 people. It didn't take me long to recognize everyone. I didn't know everyone what they exactly did but I recognized every face and I probably knew 50 out of 70 people. When we got to about 100 I was like, ah when did that person start, what do they do. So that's when you start needing some structure because it's not just for the old people who are there, it's for the new people to be able to come in and work effectively so I think that's one thing to think about is just as you grow you need to formalize that. And then in terms of product management process, I think we shouldn't think ourselves any different than any other group. Every other group they have, there's clear sales methodology process, engineering will put rigor on what they're doing, et cetera, so why aren't we doing it? And just because a lot of our work is more soft skills or creative doesn't mean we can't at least have frameworks and structure what we do better.

Suzanne: Yeah so I mean the release planning process that you spoke about I think is an example of one that a product manager could begin to implement or advocate for, are there others that you think are just like, hey if you're a PM listening in here and you don't have a process for how you do X, like get on that?

Saeed: So I think there's 5 or 6 fundamental processes that we do, right. So at the highest level you can call it product strategy and plan and sort of portfolio management. Another one is product discovery and new product identification. There's the sort of development process that we work with, development on and that's there. I think launch is another one that's really important. I mean, we don't necessarily as product managers always own it, in larger companies it's product marketing and other groups but it's critical to product success. There's what happens after launch and I don't know what to call it, I just call that post launch, but we should be monitoring and we should be managing the products and making sure that things are going right and trying to adjust and it could be organizational issues or other things. And then there's end of life. So those are kind of the 5 or 6.

And those fundamentally, in my opinion, define what we do. And if you're doing something that's way different than that then you're probably not doing product management at that point. So I think those things should be well understood, they should be defined and they should be repeatable at minimum. At minimum, you know if you run a beta program and then someone else runs a beta program their beta program should not be crazy different than yours, you know you should have that structure, you should know what metrics you're using, you should understand how to get beta participants and get the feedback, et cetera.

Suzanne: What about the reporting cadence, right, because I think to tie this back to metrics for a moment and outcomes really, there's definitely a habit of setting goals at key milestones. Like the way that everyone goes back to the gym on January 2nd and it's kind of like, okay we're in Q4 we've got to plan for 2019, oh we gotta do whatever. Or, oh we just did a roadmap, we've set up a bunch of key results and outcomes that we want, and then people forget, stop talking about it, I mean how often should we as product people be reporting on our key metrics?

Saeed: It depends on where the product is in the life cycle. Early on you're really tracking things very closely but I think at minimum on a quarterly basis, you're looking at the health of your product and you're understanding what's happening. I mean, in a lot of products, I won't say it's every one, a lot of things don't change day to day, one day you're great the next day you're bad or even weekly. But if you're thinking of like a strategic kind of analysis and review, minimum every quarter just to say, okay how are we doing, what's changed, what things do we need to look at, are we okay on our sort of the people side, or on the organizational side, or our go to market and things like that. And then that's kind of the way I look at it is that's more of a holistic thing.

But then you're obviously reacting to market changes as they happen. So I worked in a company in Toronto and Citrix bought out a small virtualization player, I forget their name, and all of a sudden this virtualization player that we were ignoring suddenly could not be ignored anymore because Citrix had entered the market. And so we adjusted our plan. But those things they don't happen every day either so as you go along you make those adjustments and then you decide how to move forward.

Suzanne: Tell us about Transformation Labs. What, how do you create value for your customers?

Saeed: Okay. So Transformation Labs it's a business, it's myself and my business partner, Lee Bonnell, he's had over a dozen years of enterprise product management experience. He worked at Blackberry and PTC and some other software companies and-

Suzanne: Blackberry, what's that? Just kidding.

Saeed: It's what the iPhone was before the iPhone. You know, a Canadian company, for those who might not have heard of it. But, and then prior to that he had a lot of enterprise sales experience and worked at HP and so we're actually friends from university, way, way back. And so we had this sort of parallel path and so we decided, it's time to take all of this experience and start applying it helping other companies. So fundamentally what we do is we help software and technology companies create better product outcomes. So this could be new product identification or product success or organizational change for product teams, so anything that's product related sort of help them out and sort of move them forward. Oftentimes companies have, you know they've been around for a while but now they've gotten to a stage where they're trying to scale. So they have a business and they're trying to scale, and if you're scaling it's a different world and so sort of helping them make the organizational change in whatever they have to do to scale their business.

Suzanne: So do you just sort of come in and then observe and prescribe, or do you kind of roll up your sleeves and immerse yourselves for a period of time?

Saeed: So both although it depends. So if they have the staff then we'll work alongside them and help them and maybe guide them. If they don't have the staff then we'll come in. So I spent 3 months earlier this year as acting head of product at a company in Toronto and then part of the job was to find my own replacement. And so there was recruiters and we interviewed and I think it actually took 4 months but we found someone. And then my goal at that company really, you know I was just describing, is that when I joined and when I sort of went there they were in a bit of disarray for a number of reasons so my strategy was stabilize, organize, and then optimize, right. And I did the stabilize and I did the organize and by the time the new head of product came in it was his job to take it forward and optimize it. So that's the kind of thing that we normally do.

Suzanne: Yeah. No, it's very similar to the work I do at The Development Factory. And yeah, big believer in the sustainable in sourcing part at the end, right. So it's like the benefit of bringing in the consultant is high performance, can drop sort of right in, can quickly understand context and reduce a lot of the friction and cost, but then there is a time where if you're committed to being a product organization you have to, you can't just lean on that plus you'd get bored if you were solving the same problem for too long.

Saeed: Yeah. Well it was a really interesting company to work at, I didn't have problem there. It was actually a 10 year old software company. Really, really good people. A lot of heroics going on though to get things done. What I didn't like was the commute, it was an hour and a half commute so.

Suzanne: Where was it?

Saeed: It was in downtown Toronto, but I live out.

Suzanne: Oh, you live out of the city, got it.

Saeed: I'm not in the center.

Suzanne: Don Valley parking lot they call that.

Saeed: Yeah. Yeah. See, no one will get that reference.

Suzanne: That's okay. You know what, this is for us.

Saeed: That's for us.

Suzanne: This is for us and our thousands of listeners as well, but some of them are from Canada. Okay. We do a segment on the show, Saeed, called Get the Job, Learn the Job, Love the Job, so what advice would you offer to, you already told us what you would tell young Saeed, any other advice that you would offer for someone who wants to get into product management. So they've already worked backwards with the end in mind, they know what they want their career to look like 10 years from now but they're like, no one will let me get that first step, how do I do it?

Saeed: So I'll relate how I got my first product manager job which when I look back it was kind of, I'm surprised they hired me. So we have to go way back, it was 1997. I was working in a start up in Toronto, we were doing real time data visualization, like 3D data visualization software which was so cool but there was no market. And I was responsible for, it was called manager of customer education so I had customer support, documentation, and training under me. So I was very close to customers, we'd train every one when they came in, and I understood our domain and our product and we had a product manager and that product manager essentially did whatever the engineering manager wanted and I wanted, I realized, man I know customers better than him, I want to do that.

And so I tried to move into that role in that company and it wasn't possible so I started looking and then lo and behold a few months later I saw an ad in the newspaper which is so ancient by today's standards, and it was like product manager and it was a decent sized ad and it was for a software company in Toronto and the company was called KL Group but they made charting software. So we had visualization, this was charting, development tools on both sides and I was like, that's my job and so for me I was like I can see myself in that job, how do I make them see me in that job.

And so I started trying to understand what do they do and why would they want someone and, I'll be honest, I mean I had essentially analogous domain knowledge and I think that was one of the big key factors, right, that I understood what they did, they actually knew our company very well, we weren't competitors. We had a class library, they were development tools, development components, so that was a good fit. And then it turns out, I didn't realize it, but I knew one of the product managers at the company and so I had a bit of an inside reference but I didn't realize it until the first day I went to work and I was like, oh Lee you work here. And it wasn't Lee my business partner, it was another Lee.

So you know what I took away from that was, it's one thing to say I can do the job but from their perspective, what are they looking for? And the things like domain experience is critical, communication skills, they gave me a written test, back then I had to write some essays and it was like, okay no problem, I used to be a technical writer. But then, you know, it was I think, fit. And that was the big thing. I remember the CEO asking me some questions about how I would resolve disputes and things like that and apparently I heard later on like what I said really resonated with him because that's how he believed it. So this combination of fit and things like domain knowledge and skill sets are all important.

And I would say for people who are entering the market today it's kind of this conundrum because like you can't get a product manager job unless you have product managing experience and in fact they asked me that question, they said well you've never been a product manager, why should we hire you? And in a way I was like, well who's been a product manager, it's 1997. But I just said, I've done this, I've done this, I've done this, in fact I've done most of what a product manager will do just not in one job. And I think that's the way you have to look at it is how much overlap, how an you fit what you've done. And sometimes you might have to make a transition, maybe you get a job, maybe you're an engineer and you get a job in the company and learn the domain and the knowledge and then move into product management or something like that.

Suzanne: Yeah, well and customer success is a great domain to sort of pivot from, right, because like you say you're on the front lines with the people and you learn a lot and we've heard that story on this show before from folks who've come in that way. What about hard lessons learned? So you come in to a lot of organizations and kind of help coach and guide as you say, where do you see product managers not really doing it so well in practice?

Saeed: I would say one of the things is, you lead by influence and you have to work collaboratively with people and you have to have empathy and it's not just empathy for the customer, you have to understand what others in the company are trying to do and what I've seen where it fails is when product managers come in and think, well I'm the boss or I get to tell people what to do. I once interviewed someone and I said, why do you like being a product manager, and he literally said because I get to tell people what to do. And I was just going, I don't know what you've been working at but that's not product management.

And so I think where you don't work in that collaborative way and lead, you know, you direct and you'll never be successful there. There's always more engineers than there are product managers and boy their influence will gang up on you pretty quickly. So I think the real thing is to understand you are a leader by influence, you work collaboratively, you have to have empathy for what's going on and you have to be able to communicate a vision for the future that people can get behind, right. Often it's like well here's what we need to build, why, well because that's what I wrote. No, show up half forward, make sure you have credibility and people with align with you and if you can do those things you'll be successful and if you can't do those things then there's always 10 other people that will fill in the gap.

Suzanne: Do you love it still? I mean you've been doing this a long time, you aged yourself not me, do you still feel as excited about the world of product?

Saeed: I do.

Suzanne: Why?

Saeed: You know, I gave a talk last year and the guy who introduced me, he said oh Saeed's going to give this talk and he's been doing product management for about 20 years and he has lots of experience to share. And so I gave my talk and then half the questions were about the talk and half of the questions were about how long I'd been in product management. And someone said to me, they said, “you've been doing this so long could you do anything else?” And I was like, wow that's a very existential question, maybe I can't, maybe I like it because there's nothing else I can do. I think for me, I studied physics in university and I took math electives, I got in a wide computer science I guess. I have the analytic background but then I became a technical writer and I love writing and I worked with customers and I've done all these different types of things and this is the one job where everything comes together. And it's always a job where I'm learning and I love that. And you know imposter syndrome, yes, sometimes, but it's ever changing. So I really think that, for me, this is kind of the good blend of all the things I like, and there's always something new. So that, for me, I think that's why I still love it.

Suzanne: I love that answer. Do you have any recommended resources that we can add to our site? So at 100productmanagers.com/resources we have a growing list of books, blogs, podcasts. They don't have to be product specific, just anything that was impactful to you that you wanna share along.

Saeed: So I'll be honest, I kind of because my kids, I have three kids in university and they're all studying some aspect of biology and I studied physics, so I'm getting my science kind of nerd back through them. And I said to them, I said if I went back to school today I would study biology because it is so fascinating and it's changing in it's dynamic and I think that, you know when I went to university and again I'm gonna no date myself but physics was a hard science, like hard meaning like very analytic, chemistry was analytic and biology was birds and trees and things like that. And we used to kind of make fun of biology. And now biology is the place to be if you're in science. I tend to read things that I can share with my kids so I don't have any specific, I usually just go do searches and I go oh, there's science news is a site and I'll go there and I'll look and I'll see what's happening in biology and I'll share, I'll find a link to somewhere else. So that doesn't really help product managers so.

Suzanne: What can product managers learn from biology?

Saeed: So I think, and we're still early, this is the next field of productization. So the kinds of analytics and the kinds of insights that we're getting from biology are gonna allow people to take this kind of science and turn it into technology. And we're starting to see very early examples of that. So when you look at vaccinations right, so everyone we all got needles and things like that and now they're looking at targeted immunity therapies that are specific to individuals based on their genome. There's ways that they’re thinking about taking things in biology and turning them into something so there's research into batteries so you know big problem with batteries is, yes we can store lots of energy but discharging it actually takes time so if you want to build large scale batteries it's very difficult to do because when you need power you need it now, you don't need a slow trickle and so they're looking at how plants take energy from the sun and then release it internally and they're looking at that and kind of saying can we build analogous batteries because those mechanisms in plants can actually discharge very quickly. That's the kind of thing that fascinates me because it's taking something from the natural world, understanding it at a very sort of specific level and then productizing it, so it gets back to that. Everything comes back to product.

Suzanne: You can't help yourself. I think your friends are right about you. Alright last question for you. Is there a side of the mug quote or mantra that you use to kind of guide you in the world personally or professionally?

Saeed: There's a few but if I think of what I use with my kids and the ones they always groan about because the one that I always come back to is, nail it then scale it. And I've kind of used it over the years in different contexts but fundamentally from a product perspective it's where, whatever you're doing, get it right on a small scale, really understand it and then take out all of the efficiencies you can and then scale it up. And this applies to product, it applies to business, it applies to things I do personally and you know it kind of rolls off your tongue so it's easy to remember.

Suzanne: Yeah, I mean you have a t shirt of that?

Saeed: I have a mug.

Suzanne: You do?

Saeed: I do.

Suzanne: That's amazing. Awesome. Nail it then scale it, yeah that's practical advice.

Saeed: Yeah.

Suzanne: Saeed Khan, all the way from Toronto, down in Australia. Thank you so much for being a great traveling partner and for joining us here on the show.

Saeed: Thank you Suzanne.