The Saeed Khan Hypothesis: Understanding the State of Your Product, Your Processes, and Your People Sets the Foundation for High-Growth Products

Saeed Khan is the founder of Transformation Labs and has over twenty-five years of experience in the tech industry. Today on the Product Science Podcast, we look at how moving past the “build mindset” to focus on discovery for products, processes, and people creates a foundation for product success.

Subscribe for the full episode on Apple, Google Play, Spotify, Stitcher, and more. Love what you hear? Leave us a review, it means a lot.

Resources

Questions We Explore in This Episode

Understanding the State of Your Product, Your Processes, and Your People Sets the Foundation for High-Growth ProductsHow did Saeed get involved in product management? What were the twists and turns in his career? How has he translated that experience into what he currently does now? How have things matured in twenty years, and which problems and patterns have stayed the same?

Why is an improved ability to build prototypes a challenge for good product management? What are the traps inherent in overvaluing speed in product development? How do we take advantage of improvements in the speed of research that are possible today?

How do you build a solid foundation for your product by focusing on evangelizing the problem? What examples does Saeed have from his own career? How do you make sure you really hear what your customers are asking for, as opposed to what you can easily solve?

Why did Saeed go beyond pirate metrics to develop the product life cycle metrics framework? How does he break down his product lifecycle steps of build it, nail it, scale it, extend it, milk it, end it? What does a shared framework for analyzing metrics enable for a product team?

Why should product managers think about and design their processes for continuous improvement? What can we learn from manufacturing’s focus on continuous improvement?

What is the state of understanding and development of the product role that Saeed sees today? How does he break down the areas for the people metrics? How do you identify which skills you need to hire for versus which skills you can develop?

Quotes From This Episode

If someone else can research and figure something out quickly and then build the right thing, where does that leave me, who's struggling and iterating and trying to move my way forward a bit at a time? - Saeed Khan Click To Tweet You have to understand the customer problem, because we all too often make the assumption that what they're saying is similar to what we know. - Saeed Khan Click To Tweet Pirate metrics is really funnel metrics. And I was trying to think of something a little more holistic, because understanding your funnel doesn't really tell you what the state of your product is.- Saeed Khan Click To Tweet So we can build things really efficiently. The question is, can we figure out what to build efficiently? Can we take what we've built and take it to market efficiently? Once it's in the market, can we manage it efficiently? - Saeed Khan Click To Tweet

Transcription

Holly Hester-Reilly: Hi and welcome to the Product Science Podcast, where we’re helping startup founders and products leaders build high growth products, teams and companies through real conversations with people who have tried it and aren’t afraid to share lessons learned from their failures along the way. I’m your host, Holly Hester-Reilly, founder and CEO of H2R Product Science.
Holly: In this week’s episode, I sat down with Saeed Khan, a thought leader and thought provoker for over 25 years working in high tech. He is a cofounder of Transformation Labs, which you can find at transformationlabs.io, an advisory firm that helps companies harness innovation, product management and product marketing to drive growth and market success. Now, here’s our conversation.
Holly: Welcome Saeed, to the Product Science Podcast. I’m super excited to have you and for us to get started. I’d love if you could share a little bit about your own journey through product management and what you do today.
Saeed Khan: Sure, yeah. Thanks Holly. And I’m glad to be here as well. In terms of my journey, I started in product management over 20 years ago. I think back then, it’s the olden days, it was the early days of the Internet and people didn’t know what a product venture was. And so, when I was applying for my job, my friends were like, “What’s the job?” and I said it was a product manager at a software company. “What is that? And I had to explain it to people, “Oh, it’s, Amy the project manager will know. Oh, what do you do?”
Saeed: And it was funny because I knew what a product manager was, but very few other people did, and now you look 20 years later, not only does everyone want to be a product manager, but everyone thinks they know what product manager is. And probably still many people don’t. So, it’s been an interesting journey. And over those 20 years I’ve worked in startups, I’ve worked in public companies. I spent six years in the Bay Area working, arrived I think the week before the dot-com bust, which wasn’t a good time to arrive, but things turned out well.
Saeed: And then, for the last 10 years … 12 years, actually, I’ve been back here in Toronto, which is my hometown.
Holly: One of the things from that that makes me think is, a lot of people, I think, we still have that experience and maybe it has to do with whether we’re talking to our peers or our parents or our grandparents. But, I think we still have experiences in our life where we go in and there’s people who have no idea what it is, and having somebody say, “Oh no, you must be a project manager,” it’s like a rite of passage.
Holly: So, tell us a little more about what you’re up to these days and, when you came back to Toronto, what kind of size companies are you working with and what kind of products are you working on?
Saeed: So, I came back like 12 years ago, work in a couple of startups here in Toronto. One was [inaudible] called PlateSpin, which had software to manage virtualized servers, another company copped up by Novell, which no longer exists. I was actually surprised Novell still exist when they acquired us, quite honestly. My manager came to me and he said, “Hey Saeed, come into my office, [inaudible] some music.”
Saeed: I said, “Sure. What?”
Saeed: He said, “We’re going to get acquired. I just want to let you know that. Announcement’s gonna come up tomorrow.”
Saeed: I said, “Oh wow, that’s great.”
Saeed: And he goes, ” guess who?” and I’m thinking, “Wow, who could have acquired us?” And then I’d call out these companies, all the big players at the time. And then the second tier players and then what I thought were the third tier players. And he kept looking at me like, “No, no, no, no, no.” And I said I’d give up.
Saeed: And he goes, “Novell.” [inaudible]
Saeed: “The networking guys?”
Saeed: So, it’s just funny. Like, yeah, [inaudible] Novell. I didn’t know they had a whole enterprise software arm. But, yeah, that was interesting acquisition. Some interesting things, working with the company not based in a high tech center like California or in Austin or Boston, they were based in Utah. So they had a very unique culture. I left from there, went to a startup, a software company here in Toronto that did network management software. And then I went back to CO Network out in California called Informatica and I spent quite a while there.
Saeed: Then a couple of years ago I left and thought, “Okay, I’ve been doing this for 20 years. Maybe it’s time to take all that experience that I have over these 20 years and then start applying it for my own benefit and not just for a company’s benefit.” So I’ve been doing consulting for the last couple of years working with quite a wide range of companies; a number of startups within a number of medium sized companies and then a couple of larger companies as well. And really helping them address various aspects of their product processes.
Saeed: So, everything from introducing new product management to smaller companies to fixing product management in medium sized companies, to helping with things like messaging, new product research, et cetera. So, taking that 20 years experience in the bits and pieces that I learned and then now helping other companies benefit from that.
Holly: Awesome. So it sounds like you’ve gotten a big range of experiences and projects, hopeful it keeps you interested in what you’re up to.
Saeed: I’ll just say that some people ask me, “Hey, how’s it going? How’s the business going?” And the one thing that always comes to mind is, it’s so intellectually satisfying that I’m working on new problems all the time, and thinking about new things. I’m learning a lot.
Saeed: We did some work for a company that has software for manufacturers. I don’t have a manufacturing background, and there’s a bit of imposter syndrome because you can’t just tell them, “Oh, I’ve never done anything in manufacturing,” but the principles all apply. But I had to learn some domain knowledge about manufacturing. And so now I feel really good because … I’m not an expert in manufacturing, but I know enough about it that it makes sense to me. And there were problems, there’re challenges. I can map to things that I’m more in tune with.
Holly: Yeah. So, what are some of the things that you started to see now that you have gone a bit wider? I think sometimes when I talk to people who had a career working for a company and then another company and then another company, then they go out and start consulting, they start seeing a wider range of things. And sometimes from that come lessons. What are some of the things that stand out for you that you see patterns or principals?
Saeed: So, it’s interesting. The patterns that I’m seeing now are kind of strange in the sense that if I look back 20 years in the problems we had when I started, I would’ve assumed that in 20 years or so, maturity and structure and discipline that’s come in. And in a certain level it has. There’s a lot of things we didn’t do 20 years ago, but there’s still a lot of dysfunction, a lot of disorganization and a lot of ad hoc work being done. And so, if I was to look at how things matured in 20 odd years, it’s yes and no. And I think some of the more disciplined companies are really making progress.
Saeed: But there are a lot of new startups. You see the same patterns all over again where … it’s a good friend of mine and she works in the startup here in Toronto and they’re trying to identify some new products and things and they’ve taken this … she didn’t use these words, but I’ll call it the lean startup approach, which is build … it’s not quite lean startup cause it’s not build, measure, learn even, it’s build, promote and try and market.
Holly: Yes. Skip the learning. Go straight to the build small things, push out to market.
Saeed: Even the build part troubles me because before you build anything, you probably should go learn something first. It should be learn, understand and then build. It shouldn’t be build first. Anyway, she’s a really good product manager and she wants to do some core research and understand some problems before building something and trying to market it and sell it. And she’s having a tough time convincing her management that that’s a better approach. I think those are the kinds of problems that still exist. And I think it’s exacerbated not just by this … I won’t blame lean startup, but that kind of mindset; build first then do other stuff.
Saeed: But I think because it’s never been easier to build something. The amount of effort to build products or prototypes or whatever is [inaudible] less than it was 20 years ago. And so that investment is small, so people say, “Yeah, sure.” And then there’s a bit of a mindset that you have to build something before you can learn and that kind of complicates it.
Saeed: So, I think that part of the industry is still very immature. There’s a quote, and I forget how it goes exactly so I’ll try and paraphrase it, but it’s, “We never have time to do it right, but we always have to find time to do it over.”
Holly: Oh, I haven’t heard that phrase before but that sounds very correct.
Saeed: Yeah. I read it a while ago and I’ve always searched for … it was really well articulated and I tried to [inaudible] it further, but you get the meaning of it, right? Which is …
Holly: Absolutely.
Saeed: … you go, go, go, get it done, get it done. “Oh, we didn’t do it right. Okay, now let’s go back and fix it.” And if you spent that time upfront investigating, learning, understanding, you won’t have to go back and fix and you’d be ahead of the game. And I think that mindset really needs to come into play. And it’s really important because software can be built so quickly and because these things can be taken to market so quickly. I think it’s even more incumbent in companies to go and do that initial homework first. Because it’s a false sense of speed or velocity or whatever term you want to use that people have, “Oh, if we don’t get it out right away, we’ll be late to market.” And the reality is, that extra little time … and it’s also easier to research than ever was before. How do we get contact with people?
Saeed: I remember doing this stuff 20 years ago. We didn’t have the means to communicate and connect with people the way I did, so it was hard. I spent one whole quarter, which isn’t really a long time, but I spent one whole quarter just doing basic research on data migration, over a dozen years ago. And that wasn’t even the end of it, but if we did that again today, I could probably do it in half the time or less. And so, I think that’s the thing that we really need to achieve. Because, if someone else can research and figure something out quickly and then build the right thing, where does that leave me, who’s struggling and iterating and trying to move my way forward a bit at a time. And I just find that to be a bit of a challenge when I talk to people because this mindset of build, build, build, build, build is so ingrained.
Holly: Yeah. I see the same thing. And one thing that I love about what you just said is there’s a lot more attention placed on the fact that we can build things so much faster and cheaper than ever before and not enough attention placed on the fact that that also means we can research so much faster and cheaper than ever before.
Saeed: Yes. Yes.
Holly: I, just recently, was with an enterprise market insights person and I remember hearing them talk about ways that we could go and test things and talking about things that would be fast to them. Fast compared to what their company was doing five years ago, but still aren’t as fast as what I see in the research-driven startups. And that’s a pattern I see a lot, where they just don’t even know what tools have been developed and how fast we can do it now.
Saeed: Yeah. And I’ll just say this, and I’m not criticizing your last sentence, but fast and speed and all these words, I think there’s an overemphasis on them in the sense that yes, it good to move quickly, especially if your competitors are, but you don’t have to put speed at the forefront of what you’re doing. I think it’s really … quote and say, if you’re building a product that’s gonna last for 10 years, hopefully it lasts for 10 years, but if you’re going to build a product that’s going to have some legs to it and lasts for some period of time, an extra few months of really understanding what you’re doing and getting the right direction and so on isn’t meaningful.
Saeed: It doesn’t matter in the long run. You can do it and it’s not gonna … if you look back three years later, you go, “Oh, was that month wasted? Or was a couple of months wasted?” No, because the things that will change over time are going to factor in. So, the way I look at it, if you’re building a house, you can build a house quickly, but if you don’t build a solid foundation, you’re going to have problems later on, because you want that house to last. And that initial understanding and contextual knowledge and the basis for what you’re doing, to me, is equivalent to that foundation. And if you start out right and you start out with a strong foundation for what you’re going to do, then that carries forward.
Holly: Yeah. I absolutely agree. So, I’m curious if you have any examples from your time where a team that you worked with or know of did build a fantastic foundation and can you tell us more about what that looks like and how they did it?
Saeed: So, I’ll use a story from my own experience. And it’s interesting because it was a bit of deja vu. So it involves my time at Informatica, when I worked there. I worked there from 2000 till 2006 in California and then I left, and then I rejoined them based here in Toronto in 2009. And in around 2005, one of the products I was responsible for in Informatica was a data profiling product. For those who don’t know what data profiling is, it’s analysis of data and trying to understand the characteristics of the data, in terms of patterns in the data, errors in the data, things like that, outlying values, et cetera. And so, anyone who’s working with data in some way or trying to analyze it will probably profile it upfront to understand the characteristics before they dig into …
Saeed: And at the time it was very early in the market for these kind of products. We had a pretty good product and we built it in-house from scratch and it was doing okay in the market. But I was always getting these requests from the customers. And these customers were enterprise customers who were looking at data management and data integration. They were always asking about, “Well, I know profiling is meant for early analysis, but after I move the data, how could I use it for that? Do you have some tool for analyzing what I’ve done and making sure what I’ve done is correct?”
Saeed: And at the time it was that, to a hammer, everything looks like a nail. I said, “Oh yeah, you can profile the data afterwards and see what it is.” I didn’t really think it through.
Saeed: And what was funny was, they were asking actually a different question than my answer because they weren’t saying, “Oh, can I actually use the profiling tool there?” they said, “Well, there’s this other kind of analysis I want to do. Can you help us with that?” But I didn’t think of it that way.
Saeed: And then I left the company a year later and I moved to Canada. And then when I rejoined in 2009, the first thing I worked on was … they said, “Look, we have a partner company, who’s built this product for something called feeder validation, and we’d like you to work with them and see if you can help us build a market, understand what’s going on there.”
Saeed: I said, “Yeah, sure.” And so, when I spoke to them, they gave me a Webex and told me what their product was and they said, “Yeah, so you guys have this profiling product but this is really a product meant for after you’ve moved data and you can verify that what you’ve done is correct.”
Saeed: And I hadn’t really thought about things for those three or four years I was away. But all of a sudden the light bulb went like, “Oh my God, this is the question that people were asking you.” These guys understood that and built something. And what was really funny was that yes there was similarities in these products. In fact, internally in the company there was a lot of questioning like, “Do we need two profiling products? What’s going on here?”
Saeed: And a lot of my time internally was spent explaining, “No. One is for one thing and it serves a certain purpose, another’s for another thing, it serves a different purpose. Yes, they both read data, they both analyze data, but they’re doing very different things.” And so, to make a long story short, we could have sold the profiling product originally to the people and maybe modified a bit to address the use case of validating data afterwards, but it wouldn’t have been successful. Whereas these guys did it and we end up acquiring the company and I worked with them and this product grew like gangbusters and we ended up, in a few years, having over 250 to 300 enterprise customers using this, which was a huge success.
Holly: Yeah.
Saeed: So, that’s an example I’ll say, of really understanding the problem and finding a solution that’s fit for purpose. And even though yes, you could have maybe retrofitted something or taken something else and applied it, you wouldn’t have been successful the way this thing was. And it’s hard to explain why upfront. I speak from my own experience as a product manager of that original profiling product, because I didn’t get it. Had I pulled myself away back in 2005 said, “Wow, there’s this question that deserves more attention,” I probably would’ve gotten it, but it would’ve taken me a little bit of time.
Saeed: And to me, when that light bulb went on, when they told me what they did, they were like, “Oh my God, that’s the question from three years ago.” Something else clicked on, said, yeah that’s why you have to understand the customer problem. Because we all too often make the assumption that what they’re saying is similar to what we know and therefore we’ll apply what we know to address what they’re saying, and that’s not necessarily the case.
Holly: Yeah, that’s a really great story. I imagine there would have been a lot of things going through your mind when you first met them and saw what they were doing those years later.
Saeed: Well, I asked all the same questions, it’s really funny. I was trying to be open-minded but I said, “How is this different than profiling?” Because architecturally they were very similar. And in fact, the irony was one of their slides that they were using, because they’ve been partnering with Informatica, was actually a modified slide that I had created for the profiling product years earlier.
Holly: That’s awesome.
Saeed: So even internally, the concepts were like, “Yeah, they’re pretty similar, so hey, maybe this site can help you.” And it was funny. But the point there is that, the real piece of the puzzle that they had addressed was really hearing that that problem was a different problem. It wasn’t a variation of the first problem. It really was a different problem. And in fact, I spent a lot of the first year or two evangelizing internally why this was a real problem.
Saeed: So it wasn’t just, “Hey, we have to go tell cu…” Customers knew it was a problem. In fact, we didn’t.
Holly: Yep. Yeah. And it sounds like you had a very human reaction of at first, wanting to be like, “But didn’t we cover all of this?” And then as you dive more, you realize, well, actually there’s more here.
Saeed: Yeah. And it was different people. So, it was different people are doing profiling their data analysts or data stewards versus QA people or development teams who are actually doing the validation. And then there are other operational use cases and other the things that profiling was [inaudible] and in fact, it was very interesting. Not to belabor this whole profile industry, but the profiling people were seeing validation questions still, that many years later. And they were hearing it from their profiling customers. And so then they were thinking about, “Okay, how can we upgrade our profiling product to do some of these other use cases.”
Saeed: So, there was some contention internally, but we resolved it. But, even from the customer’s point of view, “Well, yeah, your product sort of solves our problem. Can you adjust it to really solve our problem?”
Holly: Yeah. Yeah. That’s a really good story. So, do you have any specifics? You mentioned it grew to 250 or 300 enterprise customers. I’m always curious to hear, the people who had built this product, did they see that they had something great or how does somebody who’s on a team know if they’ve found the solution that’s growing and is growing well or if they need to keep searching?
Saeed: So, I think they knew. It’s interesting that, like I said, my first indications of this problem were back in 2005 and it was in 2009 when I returned and the company was already working with this partner and I think they had heard the same kinds of messages and signals that I had ignored, basically. And so they said, “No, there is something here.”
Saeed: So, when I saw what they had done and I understood how is it different than profiling and understood the use cases and things like that, I got it right away. To me it was like, “Oh my God, this is the thing that I should have thought about building.” And then, it was still an early stage product and all those standard things have to be considered in terms of connectivity and performance and all that. But in terms of addressing a clear use case for a target audience, they had really found a niche. And then, that actually grew over time as companies realized too that, “Yeah, this tool …” because by the way, companies were doing this validation work, but they were doing it manually.
Saeed: That was the other side of it that blew my mind was like, “Wait a minute, it’s 2009, but you’re still writing SQL by hand and doing all these things that …” And these were large enterprises too. It wasn’t just small companies. So they had really figured it out. But I think their challenge was enterprises weren’t open necessarily to buying from tiny companies.
Holly: Yeah, enterprises have a different go-to market challenge for sure.
Saeed: Absolutely.
Holly: People selling to them.
Saeed: And when we partnered with them, we lent credibility and then when we eventually acquired it, suddenly it was so much easier. “Oh, it’s from Informatica paper. Okay, great.”
Holly: Yep. Yeah. I see that kind of thing as well. From both sides of it, from working with enterprises and coaching them on what tools they should be using and from the startup trying to sell to them and it fascinates me. But, it is in the enterprise credibility and stability and there’s that saying, “No one ever got fired for hiring IBM.”
Saeed: Yes.
Holly: That is real.
Saeed: Absolutely, I think in B2B software and enterprise software, level of credibility matters more. I saw many other examples of that, a similar pattern. There was another small company we were looking to partner with and we went out and did some research with some large enterprises and I thought they had a fantastic product. I really did. They had done a really good job. And after one particular meeting, are being contacted. I did a followup with him and his first question was, “When are you guys going to acquire this company?”
Saeed: And I said, “Why?”
Saeed: He goes, “Because we’ll buy it from you. We won’t buy it from them.”
Saeed: And I said, “Look, I can’t make that decision.” But that was validation that the value was there and the need was there and so on.
Holly: Yeah. Yeah. So, when I think about some of the other things that you and I had chatted about before that I wanted to ask you about here, I was wondering if you want to talk a little bit about metrics. I have written down that we talked about product life cycle metrics, but also, the importance of process and people metrics.
Saeed: Yes.
Holly: Can you tell us a little bit about what that means to you, why you talk about it and how you came to talking about that?
Saeed: Yeah, sure. I think from a fundamental level, I always think in a systems mindset; how can we make the system better? And I think that’s important product managing as well because we are cross functional, we should be looking across the company and kind of optimizing things where possible. And around 2009, 2010, again, this goes back to my time at Informatica, we had a big all hands product, all hands meeting and all the product managers from everywhere came and we were going to do a state of the product internal forum. And for two days, essentially, we were meeting and every product manager was presenting their product.
Saeed: And what I noticed after two days was, every single product manager viewed their product differently, presented it differently, focused on different things. And it was very difficult. Even though we all worked in the same company, in fact, we worked on very similar types of products, we didn’t all speak the same language. We didn’t measure things the same way. We didn’t value things the same way.
Saeed: And so, it made it very difficult to kind of compare even. Like, “Okay, how’s this product doing? How’s that product doing?” And the only commonality you can think of might be revenue or something. But in some cases, with other stage products revenue wasn’t a big goal it was customer acquisition or something. And so at the end of it, there was a bit of a retrospective and our GM asked, “Any thoughts or comments? Anything we could do better next time?” That kind of stuff.
Saeed: I put up my hand and I said, “Well, yeah. One thing I noticed is that we all looked at everything differently and spoke about things differently and it’d be great if we could kind of figure out a way to come up with a standard definition of what state of the product is.”
Saeed: “That’s a great idea. Saeed, why don’t you work on it?”
Saeed: And I was like, “Great, my big mouth.” But the thing is I actually felt it was important. I really was like, “Yeah, you know what, I’ll work on it and I’ll see what I can do. And maybe next year we’ll have a common way of talking about it.” And so I spent a bunch of time thinking about it and I talked to a few people, but I did some research and back then there was nothing on metrics except for a pirate metrics, which had come out a few years earlier.
Saeed: But pirate metrics is really funnel metrics. And I was trying to think of something a little more holistic, because understanding your funnel doesn’t really tell you what the state of your product is. And so I came up with a framework and I blogged about it back then. And it turned into what I call today product life cycle metrics. And fundamentally, all it means is that depending on the stage of life cycle of your product, whether you’re at an early stage or growth stage, et cetera, your objectives will be different. So I have this mantra that I use. I always ask people what are the stages in the product life cycle? And people always sound like, “Build, grow and end of life,” and I say, “Yeah, and the reason you don’t know about it is because you never have to think about it. It doesn’t matter.
Saeed: But the product life cycle is important. It’s the objectives of each stage that are important. And so I have this mantra that I use, it’s called build it, nail it, scale it, extend it, milk it, end it. And I guarantee you, if you say that three times to yourself, you will not forget it. So, when you’re building something, you’re focusing on product. Let’s say maybe a bit of go-to market or a bit of business, maybe more than go-to market, when you’re trying to nail it, which means you’re trying to get product market fit and you’re trying to really understand the dynamics of the use cases and you have a different focus when you’re scaling, you have a different focus when you’re extending into new markets and new use cases, you have different focuses and different objectives.
Saeed: And so, that was fundamental to why we were talking in different terms in the company, because we had different products at different stages in life cycle. And then I thought, “Okay, what are the characteristics? What are the things that are common though, across each stage?” So I don’t have to go at every stage, everything’s different. And so I thought, obviously business objectives are common in the sense that I always have some kind of business objectives, some kind of go-to market will always be there, some kind of product, obviously. Focus at every stage, and also some kind of organizational alignment. As I go forward, I definitely need more of that. And so then I just worked out a model and I said, “Yeah, this makes sense,” and I defined some metrics and I started using it internally and trying to evangelize it.
Saeed: And, I’ll be honest, it wasn’t very successful internally, but they started blogging about it and I started getting a lot of feedback from people that, “Oh, this is really cool,” it still helped me and I’ve had some one-on-ones with people on it, I talked about it in various product camps. And so that’s what I call product life cycle metrics, which is a standard framework to think about the health and state of any product at any stage of a life cycle. In fact, I just did a workshop yesterday here in Toronto and that was one of the topics. It was really interesting to get that feedback on how you’d apply to meet people from different types of companies. So, that’s one. Process metrics are another area.
Saeed: And I think, when you think of any kind of process. And process metrics are not something you in general … you’ve been around for a long time. But I think we should be applying them to our own processes. I ask people, “Hey, of all the processes you work in, which one is the most effective, most well-defined, and if I’m kind of product people, the answer is, “Well, the agile process.”
Saeed: And I say, “What? Why do you think that is?” and people hum and haw and ball, “Because engineering demands it?”
Saeed: I go, “Yes, because it’s not even your process.”
Saeed: You’re an actor in someone else’s process and they’ve defined what should be done. And so my next question is, “Why can’t we do that to our processes, discovery processes or planning processes or launch or other things.” And I think that’s an area of maturity that really has to happen. So, I really just put some focus there and said, “Okay, how can we think about our processes? Have we come up with success metrics to measure them? Then how can we improve them over time?” And I mentioned manufacturing software earlier. Continuous improvement is just core to the culture of manufacturing. And so that opened my eyes as well when we did some of that. Yeah, we’re manufacturing. We’re in effect manufacturers of something, right? Our something is physical goods, but why can’t we be doing the same thing? So that’s another, I started focusing on and trying to evangelize.
Holly: Sorry, before you go onto the next one, what kind of response do you get to that? Do a decent amount of people go, “Oh yeah, we should be doing that.” Are they like, “Huh, that’s interesting, and I’m going to go back to focusing on scrum.” What do you get?
Saeed: That’s actually a good question. So, one of the comments yesterday was that one [inaudible] they’re heavily invested in SAFe. So, skilled at jobs anywhere. And so, I don’t know if it’s heavyweight, but it’s a very structured process and it was imposed on the company of that management that posted on the product development folks. But, it talks nothing about product management really. It’s really about the developer side.
Saeed: And so, the person said that this was interesting, they would think about it, but a lot of their time is consumed with this other one, and I understand that. So, I think it’s a maturity aspect that we have to take on ourselves as product leaders. And I think that people will start understanding it because, yeah, hey, we’ve got that build process down pat, we can build things really efficiently. Now the question is, can we figure out what to build efficiently? Can we take what we’ve built and take it to market efficiently? Once it’s in the market, can we manage it efficiently? And right now, most of that other stuff aside from the build is ad hoc or slightly better than ad hoc.
Holly: Yeah. Yeah, I think there’s some frameworks and processes that I see in different places, because I have a process focus and I seek them out and I checked out what’s happening. But I think on the whole it’s not well adopted yet. So in most places it’s ad hoc.
Saeed: Yeah, I use the term heroics. A lot of times in companies success comes through heroics. People stepping up and going that extra mile or whatever euphemism you want to use, but if they leave or something changes, things don’t continue.
Holly: Yeah, very much. One other thing I want to just share there is, you mentioned that continuous improvement is a big part of manufacturing. And a lot of times I think about how manufacturing was one of the big developments of the 20th century. The business world spent a lot of time figuring out how to get it right. When I went to school, I studied chemical engineering and one of the things that we studied, we definitely studied process engineering, but there’s a concept called control, and control processes that are meant to guide things back towards the place you want them and identify if your plant is about to explode, switching back into the mode where it does not explode.
Holly: And that’s actually something that I think about with respect to product discovery because I think, how do we make sure that there’s a control built into the process. That we’re making sure that it’s going to identify, if it’s going to be a big crash and bring it back to the growth mode instead.
Saeed: I think one of the reasons though, in manufacturing you have a physical plant and physical systems and physical risks. If something can explode or something harm going to happen to people or physical property. And on that level, we don’t have those kinds of risks in software. There’s other risks. But I think people tend to downplay them because they don’t manifest themselves in that way. So I’ll take this back analogy, so back with the data validation world. In the early days, a number of our customers were very interested in our product because they’d had some kind of data breach or data anomaly that their manual system didn’t catch. And then they found out much later and the cost to fix it was large.
Saeed: And they said, “Oh, we’ve got to do it right.” It’s the same way that a lot of security software sell today. Things are good until there’s a breach. “Oh my God, we need to get something.” I think that’s kind of the model that a lot of software processes are in, which is that, well, things are going good until they’re not going good. And then we have to figure out how to fix them as opposed to being proactive and saying, “Let’s get ahead of the curve and let’s make sure that what we’re doing is not going to end up there.”
Saeed: And the other thing is, I think, those kinds of problems don’t manifest themselves in the same way. So if you have a data breach, you’re in the news. If you have an explosion you’re in the news. If you have an internal process that failed, okay, you might get grief from your management, but it’s not getting out into the world.
Holly: Absolutely.
Saeed: I think those are some of the reasons why people aren’t paying as much attention to it because nobody wants to be in the news. And if there’s no risk of being in the news, well then…
Holly: Yeah. No, I think you’re very right. It’s true. It’s never as immediate or scary, the things that can go wrong with our software products.
Saeed: But the consequences can be huge. And, I’ll use an extreme example, but, look at what’s happening with Apple, the iPhone. So, Apple’s phenomenal company, phenomenal company. I mean, you can’t deny the things that they’ve done and the iPhone is the most successful kind of technology product ever. And yet 10 years after its introduction, roughly, things have not gone the way Apple would have wanted, and now they’re in the news.
Saeed: Some people internally might’ve look back and go, “Wow, after when the iPhone 7 came out, we saw these signs but we didn’t pay attention to them or we ignored them intentionally.” And I think until it becomes a problem, until your stock drops and all these other things happen, then suddenly things will change in that. And, you’ve probably heard the news that Apple’s going to come out with a bunch of new phones later this year and one of the things that they have is that they’re going to play catch-up with their cameras and other things.
Saeed: And I expect the specs on these new iPhones will be phenomenal compared to what they’ve been releasing in the past few years. And I think that’s just indicator of, hey, internally, whatever process are you using to make decisions and figure things out and predict what’s going to happen in the market fundamentally, stopped working. And so, I am interested in seeing what happens with Apple, but that’s the rare case of things getting so bad that they get out in the news. Otherwise …
Holly: Yeah, absolutely.
Saeed: Like the fire phone, the Amazon fire phone.
Holly: Oh, yeah. Yeah. I like that example a lot.
Saeed: Public failure as well.
Holly: Yup. You get some of those public failures, but a lot of the things that happen aren’t so grand.
Saeed: No.
Holly: For sure. So then the last metric that you had talked about was people metrics. What does that mean to you?
Saeed: So, there’s two aspects to it. And this is, again, a place where things with product roles are different than with other roles that come. Not that we’re unique in any way, but that, for example, when we think of how we hire for certain roles. So, when you think of sales. Sales is, in a way, almost the easiest one because you want people who can sell, who can make or exceed quota, they have certain skill sets, but it’s not just you hire anybody. There’s certain skill sets that they look for and then they can measure them. And if you’re not selling that to two quarters or whatever your ramp-up time is … it’s easy to understand that. And then you can either address it or you can move them and replace them.
Saeed: Engineering, again, there’s some hard skills that you look for and there’s some ways to measure output and productivity and things like that. With product roles, it’s a mess. First of all, roles are not even well understood, let alone defined well, let alone hired for properly. There’s a broad range of hard and soft skills that are really necessary for success. It’s hard to find those people. So then we go through alternative means to hire product people. And maybe you start with the hard skills, are they technical, do they have a certain amount of domain knowledge, can they do certain things. And that’s okay, because you’re trying to mitigate for a difficult situation. But then the question is, how do you measure the gaps and how do you work to improve those people in a meaningful way?
Saeed: And it’s not just the individual, but it’s the combination of those individuals on the team. People talk about, “Oh, if I could hire someone who has domain knowledge and technical skills and can speak and communicate and lead and who can work cross functionally, and who understands design,” and all these attributes. And I once talked about that in seminars, “Yeah, we just need a unicorn, right?”
Holly: Yeah.
Saeed: And they realize, yeah, maybe you can find one or two of those, but you can’t build teams based on that assumption. And so, how our jobs are defined is a mess, how our roles are implemented is a mess and how things are measured is a mess, because there’s no single metric or simple set of metrics to use. And so what I’ve tried to do is think through that problem and say, “Okay, let’s start with the definition of the roles.”
Saeed: And if you ever see job descriptions on jobs sites, it’s this ginormous long list of strategic this and analytic that and tactical this and works with this and executive and this … I saw one job is to actually use it in my workshop and it’s got this huge long list, it doesn’t even fit on the slide, but the last line of the response of the requirements is “and other duties as assigned.” 20 lines of 17 other duties. It’s like, “What else is there?”
Holly: Yeah.
Saeed: And so, I try and break down, okay, what are the skills you need for what types of roles? So, if you’re a technical product manager versus let’s call it a business product manager versus a product marketer versus some other roles you might have, how do you break that down? And there’s five main areas of skills. So I think I mentioned them already. So this is knowledge, technical knowledge, domain knowledge, systems ability and leadership, communication and soft skills. And I leave that last one a bit open because it can be quite broad.
Saeed: But, different people need different levels of skill in that. So, an entry level person won’t be as good on the leadership, but they might have the domain knowledge or technical knowledge. Someone else who’s higher up may have more of the leadership skills and may not be a strong technically actually, quite honestly. The technical product manager, you really want that technical ability and that communication ability. So you can use those five buckets and break it out and then measure very discretely on those five areas and then identify where action is needed to improve or someone wants to, say, be promoted or moved forward in their career, how you can develop them and move them forward.
Saeed: And then you can assess the combination of that and look at a team. So if you have a product team, do you have gaps? Maybe you’re really strong on technical knowledge and domain knowledge, but you really don’t have that leadership well set in your team. Maybe then you can decide how you can work on it. So it’s really a more analytical way of thinking about these jobs, given the diverse skill sets and then measuring either on an individual level or on a team level and then coming out with actions to drive the outcomes you want for the overall team.
Holly: Yeah. That’s awesome. One of the things that you mentioned in there that I hear a lot is, it’s really hard to find the people we’re looking for. So, can you tell us what kind of actions you often recommend or think are feasible for people to take once they’ve identified the gaps in their product management team?
Saeed: So you’re saying you have an existing staff of people and you’ve maybe done this assessment and then what do you do next?
Holly: Yeah. I mean, whether you have any existing staff or not. I’m wondering about build versus buy for the product managers. Like how often do you go and find them? How often do you train? What other things do you do?
Saeed: I think it’s situational. I’m a big advocate of developing people. I’ve managed people, I manage good people. A couple of times I met people who were strong in certain areas, but weak in others. And we’re all learning. I’m learning. I look back at myself when I started product manager and I wonder how the heck did I even do the job back then? I’m a big advocate in developing people and I think that a big challenge people have is that the haven’t, (a), defined the rules clearly and they haven’t defined the skill sets required for those roles clearly. And so it’s really hard for companies to then say, “Okay, we can then fill these gaps because they don’t know what the exact gaps are. Fred, really nice guy, Fred works hard, but he’s not really great at this.”
Saeed: And that’s the level of assessment they have. And I think that once you do that and make that assessment it becomes very easy to say, “Oh, yeah. You know what, Fred needs some communication training. We can help Fred learn how to present better.” We can learn these things. And I’m using a very simple example but things are more complex. But if you haven’t defined the jobs, if the job is just a long laundry list of stuff to do, and yet we need an MBA and five years of experience and… you’re never going to get to the point where you can take that and translate that into “How do I develop people and move them forward?”
Saeed: So, I think that’s the first step, is really start with the fundamentals. Do you understand what these roles are? Do you understand what the skills are and do you understand where your gaps are? And I think that’s just basic stuff. You will do that in any role. If you think of engineering, there’s hard skills there, so it’s a lot easier to ascertain. But, if you have a back-end developer who understands databases and servers and whatever they need to understand and you need to develop them into some other role, oh yeah, well, if they need some front-end JavaScript knowledge, they need this and they need to figure this out and they need to understand this, you can work that through because it’s very discrete and it’s very tangible. So, the process of analysis is not new, but it’s how do you make those definitions? And so, again, this people metrics concept, I’ve broken down into these five skills areas and that we go through some exercises to do a self assessment.
Saeed: Say, okay, what’s the requirement? So first of all, let’s define the job. What are the skills in each of those five areas that are important? What’s the self assessment that I can do in those areas? And, you’re honest or something. Yeah, maybe I’m not a great communicator and maybe I don’t have certain financial background that I need to understand my product. But then you can also do a manager assessment, you can compare. Because sometimes, we have a higher impression of our skills versus what our manager thinks. And maybe your manager is wrong. Maybe I am right. I really have that, I’ve never had the chance to show it.
Saeed: So, this very discrete identification of skills leads to the conversations that can then identify action plans. But it takes a really ingrained culture in a company to say, “Let’s think about people in that way.” And I’ll just say, in my experience over 20 years, I’ve only worked in one or two companies where the management thought that way. Most of the time, “Oh, let’s fill the gap. Let’s find someone who has that skill, let’s hurry and let’s bring them in. They can meet the team or whatever,” as opposed to, “Let’s take someone internally and make that person the leader.”
Holly: Yeah, absolutely. I see that too. Well, this has been a fantastic conversation. Do you have any final thoughts that you’d like to share with either a startup founder looking to hire their first team or a product leader who’s building out their team?
Saeed: First of all, we talked about earlier, let’s get away from that build mindset. You don’t have to build everything right away. Let’s slow things down a bit and really understand what’s going on. I think that’s not just about product, it is also about people. And I think if most companies I’ve worked in say this, that our biggest asset are our employees, then live that mantra and say, “Okay, I want to hire people or I need to have gaps to fill or I want to move my team forward.” Really understand the skills your employees bring and figure out a way to develop them. And it may be hard initially because it’s the first time through, but once you start doing that and you start seeing it and your employee starts seeing that there’s pathways forward, then they’re going to stick around and they’re going to be invested in the company.
Saeed: And I think that aspect alone will bear fruit later on, because you lose so much institutional knowledge. It’s so easy to find another job these days. I can work locally, I can work remotely, someone will poach me and give me a bit more money. But getting those people and keeping them institutional knowledge and in giving them the path forward and then making their lives easier by understanding process and making those processes clear will lead to great outcomes with product. I mean, there’s no other way that you’re going to get it done. Just working harder isn’t going to help.
Holly: Yup. Awesome. All right, well thank you so much. Is there a way that our listeners can find you if they want to find out more?
Saeed: Absolutely. So, my company is called Transformation Labs. It’s transformationlabs.io. They can also find me on Twitter, saeedwkhan. And if you just search for Saeed Khan and product manager on Google, I think I’m the one who shows up first.
Holly: Awesome. All right. Well, thank you so much for your time today, Saeed. I really appreciate it and I’m sure our listeners will as well.
Saeed: Thank you very much, Holly. Thanks for inviting me.
Holly: Product science podcast is brought to you by H2R product science. We teach startup founders and products leaders how to use the Product Science methods to discover the strongest product opportunities and lay the foundations for high growth products, teams, and businesses. Learn more at h2rproductscience.com. Enjoying this episode? Don’t forget to subscribe so you don’t miss next week’s episode. I also encourage you to visit us at productsciencepodcast.com to sign up for more information and resources from me and our guests. If you love the show, a rating and review would be greatly appreciated. Thank you.