The Product Guy

Jeremy: My name is Jeremy Horn, also known as The Product Guy, and I'm head of product over at Tafifi.com.

Suzanne: Cool. Who's The Product Guy? I mean you're The Product Guy, but what is that?

Jeremy: Product Guy has some interesting origins. In the early 2000s, I was running product at a startup in the ad tech space. I was running the engineering team, I was running product strategy, parts of business development. Very small company at the time, 20 people. It ended up growing around to 200 people, this organization. No longer exists of course. Once in a while, I'd come into a meeting, a business development meeting, and the head of sales would say, "Here's our tech guy." Every time he would introduce me as, "Hey, here's the tech guy," I would always say, "No, no, no. I'm the product guy."

Tech guy at that moment in time for people who weren't maybe in product was somewhat of a derogatory term to someone trying to do the product side. Not that tech is derogatory. It was just kind of a weird way to say, "Oh, it's that guy. He's sitting in the corner." It got to be a point where I started saying, "I'm the product guy. I'm the product guy." One day out of frustration you might say I went home, created the blog called The Product Guy, because I said if I can't convince him maybe I can convince everyone else I'm The Product Guy and then he'll have to call me The Product Guy.

It kind of came from a weird grayish, darkish place, but then it kind of stuck. I wrote a lot of stuff about user experience and product management over the years. This has to go back to 2003, 2004 timeframe for The Product Guy, the name itself. Then it's kind of just grown into a lot of other initiatives that I've run in the product management space here in New York, in London, around the world from The Product Group, mentorship, lots of other things.

Suzanne: Do you still like to be called The Product Guy, or is it one of those like Prince, it's like, "Don't call me Prince anymore. I'm now The Artist"?

Jeremy: Well, I have not yet found a symbol that I would like to be called. I can tell you I would love the symbol if I could find one. Not everyone calls me The Product Guy. I generally introduce myself as The Product Guy. It's also got great SEO online. If you ever type The Product Guy, the first like 30 pages will be me.

Suzanne: Nice work.

Jeremy: It's easier than searching for my name. If you search my name, you get an ultimate fighter AKA Gumby, and that is not me. I don't do boxing and fighting in my spare time.

Suzanne: Gotcha. Product Guy got its roots in the early 2000s, but you were obviously already a product guy even if your colleagues weren't referring to you that way. How did you find your way into product management? Because this was early days.

Jeremy: Yeah. I guess I have to kind of go to my childhood a little bit there. As a kid, I started programming when I was five years old. My dad used to teach programming at the Boy's Club, and I would get brought along there. It was just, "Hey, go sit in the corner," and I did the programming with the rest of the people in the class. I started very early on doing programming. And then also I did a lot of stuff with art competitions, oil painting, charcoal. I always had kind of like two minds, like for the programming side, the technical side, and the artistic, aesthetic side.

Also, my big thing that I had a lot of fun with as a little kid was inventing. I liked to create things. I liked to solve problems. They were goofy. They were weird, like earmuffs that just stick on your ear, like a lot of wacky things. Flavored toothpicks I remember was one of them. A sink you could talk to. Now it doesn't sound so wacky, that one.

Suzanne: Well, even flavored toothpicks. I'm like, "I'm pretty sure that exists."

Jeremy: Well, at the time it was like mint. Everything was mint. My idea was cherry and all these other fruity flavors.

Suzanne: Right, right.

Jeremy: Remember, I'm a little kid. This wasn't last year. In my bones I was always like an inventor. I wanted to create things, solve things, so I'm always taking things apart, designing things. I always had sketchbooks, drawing stuff. Then you kind of fast forward many years and I'm in college, and in college I actually started out looking to do a physics degree. Astrophysics was what I thought I would do. I was looking for something hard to solve, so I said, "Astrophysics, origins of the universe, that sounds pretty hard."

The way I ended up really into this product path was it was like a summer job I was going for. In going for this summer job, it was just web development. This is not when web development was even close to what it is today. Web development was like, "Eh, whatever. I'll do whatever they need. Put some pictures on a page." That's back when you would make text blank and center things. I went for a job like that. The guy I ended up talking to became like a really great advisor. I quote this guy all the time. I'm talking to him for this web development job. We end up talking about like Schrodinger's cat and all these physics concepts, and he goes, "Oh, that's too simple. You could do something better."

They were really stuck on a OCR project, optical character recognition. They had designed these neural networks and they were doing a lot of image detection and it wasn't working. They said, "We have this failed project, but we want you to fix it because we're trying to sell it to this government," this whole big thing. I start being in charge of one project, learning machine learning and AI from a lot of the people who did it. I was doing programming, but I started managing a small team, and we started to kind of build a product.

The reason I mention this is because this is where all of a sudden my path kind of switches from physics to what I thought was going to be computer science but very rapidly went from computer science to really managing the teams, figuring out the strategy, what are the features. It went from this machine learning and neural networks to the first company I ended up founding in the 90s, which is a network security company. There as the founder, you're the product person in that.

Suzanne: Right.

Jeremy: The very first job I got right after that, I think the title was VP of new products. Yes, I did not yet know I was a product manager with that title, but I was VP of new products. Then I ended up becoming VP of products. Again, product management wasn't so much of a discipline I thought of as a specific discipline where like this is how you do roadmapping or develop. I knew what worked, so everything I always did was very iterative, and very tight cycles, and always releasing. I'd say it wasn't until a little bit after more of that scientific approach, especially the kind of work that Steve Blank and Eric Ries and all of them have done, and Agile community, and the Lean communities where it's now much of a science. Back then it wasn't so scientific. It was kind of a lot of learning, a lot of mistakes, and all that kind of fun stuff.

Suzanne: Yeah. I mean the nice thing about a framework that's been kind of documented and circulated and accepted by society is it's actually just years of doing things the wrong way that ultimately results in somebody writing like a late night manifesto and being like, "There must be a better way. This is it," and then we just get to come along and say, "It's validated learning. Don't you understand? This is of course how we do things."

Jeremy: Yeah.

Suzanne: I want to go back to something that you said. You just sort of shoved it in there, which is of course as a founder you've got to be the product person, but I don't know that a lot of founders recognize that of course. I've certainly been brought in to consult founding teams who themselves do not possess product management skill sets. Well, I shouldn't say they don't possess the skill set. I think anybody is capable of being a great product manager. They haven't shifted their mind into a product mindset. They aren't thinking and doing like a product manager. I don't know that they would agree or not that they should have to be. Can you speak to that in your opinion?

Jeremy: Yeah. I'd say in a startup today, in a startup today if you're founder of a company, you hire maybe your CTO, a developer to a five person company, ten person company. You really are that product manager, whether or not you have that mindset. Maybe you need a consultant to help kind of guide you. Maybe you're lucky and you have a great technologist that can kind of help guide you through the process, or you hire a product manager. Usually if the company's really tiny and it's coming from a founder base where the next product manager you hire is not the founder, that might be a little bit of a tougher fit because at the end of the day a lot of the vision is still coming from the founder.

Back in the 90s, I was not a good product person in the 90s. I think in my first startup I made a majority of all the mistakes I ever made in product management in that first company, and I think that's actually what's benefited me so much, from spreading myself too thin across too many projects to the next shiny thing to raising money to like everything from the product world to the startup world. I made so many mistakes in that first startup, I was so well positioned when the 2000s came to do so much better.

Suzanne: Yeah, yeah. Absolutely. Did you scare yourself a little bit? Like was there ever a moment, you're doing this for the first time, you're learning as you go, you're making mistakes as you described perhaps retrospectively, where you thought, "I'm not so good at this. I keep screwing up. Maybe I should go back to the simple world of astrophysics"?

Jeremy: No. Ignorance is a powerful thing. I think a lot of people once you've got enough years under your belt, I think you look back and you go, "Man, I would never do it that way again today. I would never try that." Knowing what I know now, that's a crazy way to do it, yet it was successful, or yet you made it through. Ignorance can be a very powerful thing in driving you forward and also discovering new ways of doing product management and managing people, working with people that can be happy occurrences as well.

Suzanne: It's funny that we're talking about learning and sharing lessons learned on the job, because you've also done a fair amount of teaching. You've taught with General Assembly here in New York. You've also taught at Carnegie Mellon and New School product management. This is interesting to me because we're still very much in a time where there is not a lot of formal product management training. Is that something that you think is going to increase, that needs to increase? Should more schools be introducing these programs into the curriculum?

Jeremy: Yeah. It's an interesting question. I know Carnegie Mellon actually does have a product management course, an official one where you can actually earn credits and all that now. I am happy to see they're doing product strategy. When it came to me teaching those courses or putting together different curriculums over the years, curricula I guess you would say, it came from a place of I wish I had had this when I started out. I wish someone could have taught me this, or this is a way to do a roadmap, this is another way, this is how to communicate with different stakeholders, here's how to deal with politics, and here's just different methodologies you might want to try along the way. I had always wanted a lot of that, and that's where a lot of these kind of programs that I ended up doing came from.

As far as the curriculum, and I think you're asking like should people take the classes or where should they be and all of that, it's a bit of a hit and miss type of thing right now. I don't know a lot of great programs out there that I would say you take this to get into product management. I think if you want to learn product management, you want to understand some of the skills or some of the things that come into consideration when you're doing product management, there's a smattering of courses across the country, around the world that you can take, but I would say don't take it to get in. Take it because you're curious about something, or you're trying to like develop maybe a new skill, or they're covering something that you don't know yet.

That's also why I have a mentorship program that I do. It doesn't help you get in, but if you've found a way to get your foot in the door, your toe in the door a little bit in your current organization or maybe you just got that first product management job, the product mentorship program that I do helps people really kind of up their skills. They get paired up one-on-one for the duration of a session. We do sessions every six months. I've been doing that for I think north of four years now.

Suzanne: Here in New York specifically?

Jeremy: No, around the world. We're in over 20 different countries.

Suzanne: Amazing.

Jeremy: It just happened.

Suzanne: Says The Product Guy.

Jeremy: It just happened. I'll tell you. The way the product mentorship program came about was kind of your perfect ... I'm not complimenting myself. I'm saying this is how you should do product development. After a lot of meetups of The Product Group, people would come up to me and say, "Can you mentor me?," and I would say, "I really can't." After I'd say no enough, then they'd say, "Do you have someone else you could recommend who could mentor me?," and I'd say, "Ugh." At some point, it kind of hit this critical mass where I said, "Let me just try something."

I put together an email, a very simple email, and I sent it out to my user base. It sent you to a Google form. I still use the exact same Google form today that I did then. I just wrap it in a pretty shell. It just said like, "Do you want to be a mentee or do you want to be a mentor?" When I sent it out, it was very simple. Am I going to get X number of mentees within one week? Am I going to get Y number of mentors within one week? If I hit both of those numbers, I guess we're doing a mentorship program.

Well, what ends up happening is somehow it goes global, because at the time I had much more coverage just in the New York area. It wasn't so much everywhere. Somehow it went around the world, and I started to get people applying from Australia, and London, and India, and Tokyo, California, Argentina, Brazil. People all over the world were applying to be mentees, applying to be mentors.

Suzanne: Well, you did have that good SEO.

Jeremy: But this was something I'd only sent out to the membership of The Product Group.

Suzanne: Right, right.

Jeremy: I was like, "What?" I hit my number, which basically validated the concept. I validated there was also enough mentors and mentees to make it viable. Then at that moment I said, "Okay. I guess I'm going to have to figure out how to create a mentorship program." That's what I set about to do. Every session of the mentorship program since then, it's always been kind of tweaking it and iterating it. I'm always running experiments. Some I tell people what experiments I'm running on them, sometimes I don't. I'm always trying to find ways of making it better, developing KPIs to measure success and performance.

Then after it was happening enough and I was having enough trouble with certain parts of it, I created software to help automate parts of it. Every step of the way was very specific, validating a concept, validating an idea, seeing the problem, and then trying to solve it. It's gotten to be where most of the real big problems have been solved and we're at a pretty good steady state right now. We're able to identify very good mentors. We're able to know which pairs are doing well, which ones might need a little bit extra help, and it works really well right now. It works pretty much like clockwork. It's just kind of like a checklist I go through every six months.

Suzanne: It's a formal mentorship program then. If I were a mentee, maybe somebody listening in on this podcast and say, "That sounds like the kind of thing exactly I need," I would what, go over to The Product Guy?

Jeremy: You go to TheProductMentor.com ...

Suzanne: Product Mentor.

Jeremy: … and sign up. The wait list on the mentee side is long. If you're interested in being a mentor, which means you probably have more than five years of real world product management experience, got a good track record behind you, we're always looking for more mentors. The more mentors we can get, the faster we can go. Any particular session we probably take anywhere from 10 to 20, some sessions as many as 30 mentees, but in general it's like in the 10, 20 range.

A lot of people don't qualify on the mentor and the mentee side, so what we also try to do is we try to just open it up for the rest of the world. We have a YouTube channel, so all of the mentors, they do these live streams. When we do the live streams, people within the session, you see inside the room and can ask questions, but we also make it so anyone else on the internet, you can come to the YouTube thing, ask questions, and I'll pass them along to the mentor in real time so you can kind of get feedback. We probably have north of 140 videos at this point on differet topics in product management, so people can always kind of go and access it or participate in whatever the next live stream. I think our next one's in March 2018 right now.

Suzanne: The irony in the end is that you didn't have time to be a mentor, but then by virtue of opening up this mentorship program you got sucked into being a mentor. You're one of them.

Jeremy: Yes. I'm a mentor to the mentors at this point. Yeah, it's a weird fluke. I think I'm probably putting in a little bit less time than the mentors themselves. A mentor in the program spends at least an hour every week with their mentee, and there's some good, intense work that they're working on. There's some real problems that mentees are having, or struggling, or trying to figure out, and the mentors are working really hard with them. Mine is more the repetitive part of it. I've gotten my piece down to a science I think. Every time a mentor starts new with a mentee, it's always a new experience, always new kind of challenges to figure out and solve.

Suzanne: It's a one-to-one pairing then?

Jeremy: Yep.

Suzanne: Great, great. I want to go back to curriculum for a moment, because I really heard what you said and I think it's valuable advice for folks listening in. One, lots of classes and schools are popping up, and they're not all equal. I think even speaking as an instructor, I think that's a major variable is in theory you can develop a curriculum and try to scale it across an organization, and different people are better at teaching than other people. Say there were to be such a program that was applied product management, right, the idea of I could start class one and exit class whatever and theoretically be ready to get into product management. Not to put you too much on the spot, but like could you quickly whip up the syllabus for us on that? Like what do you think that would sort of look like as a story arc?

Jeremy: Yeah. When I was teaching my classes, I always approached it from that first class, what skills would you need to have to get that first product management job, at least get the interview. Have enough to get in there so then it's really on you to kind of prove yourself out. That initial, that 101 course I would say, I would cover everything from just basic methodologies to understanding different phases of a product. Different phases of a product of the kind of phases you would go through in the course of a week and then phases you would go through in the course of a lifetime of a product, understanding the phases, understanding what to look for, understanding what the different metrics were, how to find them, understand them, apply them. To understand about misconceptions when it comes to roadmapping, to focus on goals and objectives and not features, to hear your customers but not to do what they're asking but to identify what they need. A lot of that in that kind of 101 class was taking a lot of real world stuff, a lot of exercises, and really kind of going through a lot of the exercises and learning from each other where students were making mistakes, where people were getting things right. I think that's kind of like your 101. It's kind of like a foundational element.

The next phase of that is the trickier part, and I think this is where to be successful here I'd be wanting to partner up with more companies in the industry, because at the end of the day that first one might get you in the door. I always looked at it of kind of cover this material, be awesome at it. If you scored a good grade in my class, you should get an interview at least. That was my hope, or I would be happy to advocate for you for that interview. As far as becoming the product manager, at the end of the day you need to apply it. Whether it's like an apprenticeship sort of program or another course where you're taking a lot of that same material but now let's develop a feature or solve a problem for a Bitly or a Foursquare or some other company, but for real. That involved partnering up.

Honestly, I did actually look at that at one point, but I just never had the bandwidth to actually pull the trigger on that. I think in my mind, that would be kind of the next phase is where I could actually connect a lot of what you've learned and now start applying that and using that as the learning mechanism, working with some companies in partnership.

Suzanne: Yeah. I think they're good ideas. I would throw one in the ring as well, which is a much deeper focus on kind of the stakeholder management, stakeholder relations piece. I get a lot of people asking questions about how do I actually get buy-in from my executive when he's the founder of the company and hasn't been managing the product for a long time but continues to know exactly what's right, and it's none of the ideas that me and the team speak about. Of course, I say a lot the official product management answer is it depends, right, and it really does depend, but sometimes knowing how to navigate the nuances of personality, I'm talking more than just recognizing that a product manager needs to be a bit diplomatic, recognizing that you're working with different archetypes of people, that really understanding this is like who's on your team for better or for worse and how do you overcome that. I'm sure problems come up in the mentorship program. I would imagine a lot of the soft stuff gets raised.

Jeremy: Yeah. Yeah, stakeholder management is definitely a big one. I think what you're speaking to also is when you're talking about becoming a product manager, like what are those characteristics, what are those skills, you're looking at certain kind of components. You're looking at someone who can solve problems, who's creative, and also has a good analytical mind. Those to me are your foundational elements. If I'm hiring you, if I'm interviewing you, those are like the things I care about the most. I want to see how you solve problems, how you approach problems, how you break things down to understand the market or estimate market size or market opportunity, and then I want to make sure you're creative, because to my shortcoming I don't know how to teach creativity. The other two categories I can teach, but creativity I don't, so I'm always looking to find people who really think differently than myself. I'm always looking for people usually outside the industries that I'm hiring.

When it comes down to stakeholders a lot of it is you've got to just practice. You have to run into the problems, have to experience it. I'd say I've been fortunate in having very interesting and diverse stakeholders over the years. Because of that, I've become a better product person. If you're kind of coming at it like very blankly to the different kinds of stakeholders that you might be running into, you want to provide evidence, you want to provide data, you want to try to back it up. At the end of the day, there's personalities and you have to understand where they're coming from, what their motivations are, what they're afraid of to try to convince them.

I'd say at the end of the day the job is less about the roadmap, it's less about what features we're building, and at the end of the day the real great product managers are the ones who succeed not at the fundamental, the foundational elements I mentioned, but really at the people management. Those are the skills that carry you. Those are the skills that everyone's excited and they're ready to follow you. They'll go wherever you want them to go. At the end of the day, the great product managers are the ones that are able to build those great relationships.

Suzanne: Right, yeah. You have had a lot of executive product roles. I mean you've been doing this a long time as we've already spoken about, and I would say the last eight or ten years of your career have mostly been in the capacity of director of product management, or product lead, or head of product management. The titles vary, but I think the sentiment is in that executive tier. What is the hardest thing about transitioning into executive side of product management versus just working in product day-to-day?

Jeremy: I would say it's a misconception to think that you will transition into the executive side. Not saying that you cannot transition into the executive, because of course you can. What I'm saying is it's not so much of a transition, but it's almost like a career change. When you're doing product management, you're day-to-day product management, whether you're a junior or a senior, you're either working a sliver of a product or a larger part of a product, you're working on the roadmap, you're doing a lot of customer development, and you're kind of in that really on the ground product strategy cycle.

When you're on the executive side, you're trying to provide the guidance, you're trying to provide a different sort of perspective on it. You're not trying to get into the weeds of the features. You'll probably still be doing customer development, but that's not what's driving you every day. You're counting on the people on the front lines to know what the real needs are, understand the problems to figure out what solutions they want to try, what experiments they want to run. You're providing enough cover between them and the rest of the company so that they can do their thing and the company doesn't get in their way. You're helping educate other groups as to how product management works and how product works. You are making sure that they're budgeted, and there's clarity, and marketing and sales and biz dev are aligned with what your team is trying to do. You're keeping people at bay. You're reigning people in.

When you're thinking about what do you want to be successful at at that point, it's how do you have a successful team. That successful team in my mind translates to the successful product. My focus day-to-day becomes how can I help them be more creative, how can I help them have more time, how can I give them more of the resources they need to be successful versus how do I solve this problem or what are the wireframes I want to try out. It is a very different sort of animal when you're kind of doing the executive product management versus the junior to senior product manager type of role.

Suzanne: What I think I'm hearing you describe is there's a certain amount of humility involved, because you have to be okay letting other folks have the spotlight, letting other folks have the victories. It's like being the elder and being in the corner and just saying, "I'm here to hold this up for you and show you a way."

Jeremy: I think at all levels you need that kind of level of humility. I'd say I have a strong ego, but I'm humble about it. Anyone who knows me would probably be laughing at that as well. The big difference is your job as an executive isn't to say, "Here's the solutions." Your job is to say, "Here's the bigger goals. Here's how it's going to impact the larger company," and to get the CEO onboard, and sales onboard, and biz dev onboard, and try to keep all those pieces moving. Make sure that you've got enough staff for your team, and hiring for the next quarter, and all that.

At the end of the day, you have to make a decision, do you want to manage a product and do you have fun coming up with the features and solutions for the product or do you want to manage the process and come up with the different ways of doing product management process. For myself, at some point in my career I loved doing the product management. I loved coming up with the features. It's a lot of fun, but I love even more figuring out the process and how can we do product management better, or let's try this this quarter. That didn't work. Let's try a different way of doing it. Let's try experimenting with different ways of communication and transparency, and just different ways of just kind of moving the product management process itself forward. You have a very different focus between those two.

Suzanne: Right. What I'm hearing you describe is growth and kind of personal growth in saying there was probably a point in your career where you couldn't have imagined being anywhere other than in the eye of the storm, and then you do it, and you do it, and you do it in a different context, and eventually you want to solve different types of problems. The problem solving piece is still alive and well. It's just now I'm solving process oriented problems, human oriented problems. Could you credit any one particular job experience or company in your own career trajectory more than others for contributing to your own personal growth? Where did you grow the most?

Jeremy: There's so many different questions in one. The place I grew the most I'd say is probably Viacom. I've got enough years between myself and Viacom now where I can say that. When I started out, it was really kind of cool. It had a good startup vibe in the part that I worked in. Over time, it did not, and I'd say a lot of the challenges that I ended up encountering and solving in my time there, actually I didn't just solve there but ended up making it into the coursework that I taught, how to deal with stakeholders. I have a whole thing on how to deal with different types of stakeholders and challenges in my classes. Really it was those challenges I think that made me a better product person.

I think there a lot of it was if I can't fix this in the product right now, what can I do around the product. That pushed me I think a little bit towards the process side. That might be where I started thinking more about process, but I've always been fascinated by productivity and efficiency. I know that sounds completely weird.

Suzanne: Not to me. Not to me. You're just speaking my actual language here.

Jeremy: I've always been kind of fascinated like how do you do it. When I was doing physics in college, I used to hang out with the business people because I was kind of going, "How do you do the business side?" I wanted to hear the process and what they were doing. They thought I was crazy, but I guess it kind of came full circle now that I think about it.

Suzanne: Today you are head of product at Tafifi.

Jeremy: Correct.

Suzanne: What is Tafifi?

Jeremy: Tafifi is a product I started really only a few months ago. I have for some time now wanted to create a product manager's product. That's how I used to describe it. It was a ridiculous thing, but the goal then was I wanted a product that helped you do product management and in turn made you a better product manager just for having used it. I've used everything from Aha! to Trello to JIRA, Pivotal, every product out there. Very great for product management.

My original idea for Tafifi, I think before even I was thinking of the name Tafifi, was I saw that a lot of companies just didn't understand how to experiment and what to do with experimentation. I started there. I did a lot of customer development and ended up with a very disappointing result. The result of this customer development was I go out, I'm meeting with people in Starbucks all over the city. Like anywhere they were, I went. I set up meeting after meeting, all types of company, all types of product, newer product, older product. Everyone had this need. It was very clear from my interviews they all should be experimenting more, they all needed help in figuring out how to structure the experiments, how to execute the experiments. I was like, "Yeah."

I think out of that batch of people I spoke to, well over 20 people in that first cohort there, two maybe realized they needed the product. I was getting some weird feedback, and the feedback I was getting was weird I'd say because I was so gung ho on this experiment thing. I didn't dig too deep into it. Like I dug deep around the problem I was trying to validate, but all of a sudden I see this trend, "I need roadmapping software." I'm like, "Why do you need roadmapping? You have Roadmunk. You could use Excel. You could use PowerPoint." All of a sudden I started seeing roadmap everywhere. It doesn't click for me. I don't see what the pattern is, and if anything you're like, "All these crazy people asking for roadmapping software, what do they know?"

While I felt I had definitely validated my original idea of the product was no good, I wasn't seeing anything in the data at that moment that said go this way or go that way. At that moment, I'm like, "Okay. I don't see where to go there. Look, there's this job over here," so I ended up working a short stint at another company. As I'm kind of working at this other company, I'm working with developers, I'm trying different software, always trying new things, always trying to do new ways of product management, working through phases.

All of a sudden, I worked with this new piece of software that was kind of like a striped down version of JIRA and I start kind of layering on like the different things that I want to do in the workflow. I start layering and layering and layering, and that's when all of a sudden I kind of had this magical moment, this epiphany you might say in that they weren't asking for roadmapping software. Everyone kept saying for roadmapping. Now, if I was approaching it again from that moment a year or two ago, I would have asked like, "Why are you asking for roadmapping software?" It never occurred to me at that moment to ask that, because I was like, "Roadmapping software? You're crazy." Which again, that's why you need to do lots of customer development, because you're going to make mistakes like that and you're going to miss something kind of big.

What I had missed was it wasn't the roadmapping software. It was keeping everyone on the same page for when I make a change in the roadmap how does the roadmap get effected, how do I keep all my stakeholders aligned with what the goals are, how do I even experiment and see, because a lot of product managers, your day-to-day are spent in the backlog. When I make a change in the backlog, I don't know what that impacts. I know it's the correct priority. I might feel very confident in the priority, but I didn't see the cascade of what that might have really moved. I didn't see the roadmap, and then I discover later, "Look what I moved," and now I have to communicate it out, and it's headaches and chaos.

That's when I kind of took a step back and said, "Ooh, I think I've got something." That's now where Tafifi is today. Tafifi is a product, it's really for product managers to kind of get out of the way. It's not all these other things that are really project management oriented. It's really about helping align expectations, align goals, align knowledge around the product where it gets out of the way of the product. Use it as much or as little as you want, but also it'll automatically communicate out to stakeholders when a big change happens. If it's a big change that someone really cares about, it'll give you a heads up as the product manager maybe you want to talk to them first before they get this automated email.

Suzanne: Right.

Jeremy: There's a lot of different aspects. It's about what can I automate that a product manager has to do as part of their product management duties every day, what can I apply a lot of my AI learnings to over the years to where I can come up with estimates as to if you move this in the roadmap in the backlog, this is the impact on the roadmap so that you can see, other people can see, and it really kind of helps keep everyone much more aligned than they normally would where it's also just an enjoyable experience.

Suzanne: Practically speaking, does it sort of support a roadmapping kind of high level planning view and then a more granular kind of sprint planning type views but keeps those things in like a two way sink?

Jeremy: Everything is just real time. You can make changes. You can communicate. I wanted a very collaborative environment at a foundational level of whatever it was that I was going to end up building. I wanted it to be you could have real time conversations that are connected up to the tickets. I wanted it to be where if someone else is dragging something in the backlog, I'm seeing what they're dragging on my screen at the same time. If I make a change here, I see immediately what the impact on the roadmap is. I can look at the roadmap in whatever flavor I kind of want, the now, next, later format, the quarterly format, annual format.

It's really about very minimal but also very flexible. If you want to do Waterfall, power to you but I can help you out. If you want to do Kanban or Scrum or whatever, you can very easily do that. If your team wants to do points, great. I can be more helpful. If they don't want to do points, don't worry, my system's also going to learn from the different types of work that people are doing and estimate based off of the people and the types of work. It's there to help as much as you want to engage with it, but also just kind of get out of the way so that, you know what, you can do experiments.

It helps you also through the phases from ideation to experimentation to development. By the way, if you just care about development, just do the development piece. If you want the other parts to help communicate how everything connects, do that as well. It's really about kind of flexible but not overwhelming, which is what I feel like a lot of these new software platforms have become. I just feel massively overwhelmed, too many features, too many bells and whistles. I just want to do product management, and at the end of the day what does that mean? It means I'm solving problems for people, I'm finding solutions, and that I'm delivering that business value, I'm delivering that customer value.

Suzanne: Okay. Well, I'm sufficiently sold, Jeremy. What do I do? Do I go to Tafifi.com and sign up? Are you taking real customers?

Jeremy: Yeah. You can sign up for it right now. There's a wait list that you'll sign up for and I'm gradually letting people into it.

Suzanne: You and your wait lists and your scarcity mentality. We're al biting our nails like, "Please choose me." Okay, there's a wait list.

Jeremy: Yeah. You sign up and we're gradually letting people into it to try it out and iterate on it.

Suzanne: That's Tafifi.com?

Jeremy: Correct.

Suzanne: Okay. Listeners, you know what to do. Get on that wait list. We do a segment, Jeremy, called Get the Job, Learn the Job, Love the Job, and I expect given your experience working as a mentor and how long you've been in this industry you've probably answered these questions 1,000 different ways for 1,000 different people, but I want to frame this first one a little bit more specifically to something that you spoke about earlier. You said if you took this 101, this fictitious 101 course, you should probably be able to get the interview, but I actually get a lot of people come to me and say, "I can't get the interview. What am I doing wrong?" I know part of that has to do with smart resume readers that are kicking people out before they ever even had a chance. How do I get the interview, whether or not I have the right skill sets? Let that be decided in the interview itself.

Jeremy: Yeah. I actually spend a lot of time with people on the resume piece. I don't find people are getting rejected because of automation. That's what a lot of people think. It's someone's scanning your resume. They're actually physically looking at it. They're spending maybe five to ten seconds if you're lucky looking at it, but nothing jumped out at them. A key piece that I spend a lot of time with people, I just did this just on Friday I had a whole bunch of people in my unofficial office. I meet in a hotel in Soho and people just kind of come through, and we sit down, we went through the resumes.

Too many people just list what their responsibilities were. I don't care, and I mean that from the heart. I mean that from the heart of everyone hiring you. That's nice. If you get the interview, tell them more about what your responsibilities were, but if you managed a team of 20 people, that's nice. To what effect? How did you impact the business? What was the business value you generated? What's the customer value you generated? What number changed because you did that? When I work with people on their resumes, that's the thing I'm looking for first and foremost.

Sure, for a job you can put like a short one liner, like what was the job, what was your role. Any responsibilities you want to talk about should always be, "I did wireframing." To what effect? Or you managed a team and because of that what happened? You reduced defects by 20%? What was the number? If you don't know the exact number, estimate it, but at the end of the day I always kind of think about a product manager's resume should just be screaming business value for every single one of these bullet points, and that someone who's looking at that resume is almost looking kind of at like a Chinese menu, like, "Ooh, customer acquisition, I want one of those. Retention, two of those I want." They're just kind of looking for the things that they're hoping you can do in your job. That gets you in the door for a lot of places. Because I see that, now they're going to bring you in and say, "Tell me about what you did there," and then you can talk more about the responsibilities, you can really go into more detail as to how you generate those numbers and what other relevant numbers there were.

Especially if you're not in product management, you should demonstrate that you have a product manager's mindset. Whether you're a developer, customer support, how did what you do impact the business? If you worked on a three terabyte database with millions and millions of records, that's nice, and I love that you want to switch into product management, but how did your project with that database impact the business? Think about it. Figure it out. Estimate it. A lot of people, "I don't know the numbers. I don't know the ref." Back of napkin best estimate. You're trying to start the conversation. You're trying to make the resume the thing that starts that conversation, that gets your foot in the door. At the end of the day, you've got to sell yourself in the interview, but get in the door by having an appealing, interesting, engaging resume.

Suzanne: Yeah. One of the things that I like about the OKR framework is that I think of it as like a syntax for goal setting. It's like objectives on their own are ambitious, and kind of pie in the sky, and don't really create shared understanding. The key result appropriately anchors it. What I'm almost hearing you describe is like RKRs, responsibilities plus key results. Like don't just tell me you did the thing. Show me the measurable impact. I love it.

Jeremy: Everything I do is OKR driven.

Suzanne: There you go.

Jeremy: Mentorship program as well.

Suzanne: All right. You spoke about making every mistake in the book earlier in your career. You obviously talk to a lot of product managers. What do you think is the most common mistake that people make? It's like you can already predict somebody getting into the field is going to do this?

Jeremy: When I think about what mistakes I often see, I'd say one of the most common ones are really just people getting too attached to their product and building a feature, talking to maybe one or two customers, waiting just enough to get the answer they were looking for, and then building it. Then when no one uses the feature, it's the customer's fault because they should be.

I remember that I had a product manager work for me. He went down that very path.I remember sitting in my office. At first, I just let it sink in. I just let it like saturate the air. He's like, "I built it. It's the customer's fault. They're supposed to be using it. We need to tell the customers they have to use it." I remember sitting there going, "Okay. I have some work."

It's too much of the product manager thinking that they do know all the answers. I think a lot of people when they get into product management erroneously get into it because they want to be the ones in charge. Except once they're there, they realize, "Oh, wait. I'm not the one in charge." They don't have a team, and they have to lead through influence, and oh wait, you actually have to do research. It's not just your gut feel. There's still a lot of places that they, "This is the feature we should do because I feel it's right." I think that you alluded to that with some of the companies that you referred to kind of earlier.

Too many people don't realize that there is that research that you have to do to identify the problems, to test the solutions, to not force customers to use it, but have a feature they want to use and to do that right kind of customer development. Too many come into it thinking that they're going to just know the answers, or this is the feature, or they're so excited about the feature they just don't hear the other feedback or they stopped after talking to two customers, which is never enough. It's never enough, no matter what you're trying to do. You've got to talk to more than two.

Suzanne: Yeah.

Jeremy: I see that happen a good bit where just the wrong feature gets built, and what does that do? That can kill. Just even one bad feature could kill a product manager. Especially if you're already in like a challenging, politically charged environment, that can destroy trust. The development team maybe spent weeks on it. Maybe they spent months on it. That just freaks me out, just that idea alone. They spent a lot of time on it, and it was hard to do, and they built it, and now no one's using what they built. Why should they ever listen to you again? That's the kind of credibility you don't want to be losing, especially early on, because getting it back, that's tough. Some places, it's not possible. It might be a tough mistake where you have to go to a new job after that, but that is a very common mistake. You really want to earn people's respect, and the way you earn their respect is you're not wasting their time.

Suzanne: Love it. What keeps you in this? You've been doing product. You can't leave. It's your Hotel California. Why do you love it so much?

Jeremy: I like solving problems. I like people. I like every week I talk to maybe five new companies a week, ten new companies a week. I just like hearing other people's products. I like hearing how other people are solving their problems. I just like hearing other people's stories. Even more, I just like solving a problem. Tafifi isn't about creating a tool. I'm not trying to create a tool. I'm trying to change how people are doing product management. I'm trying to change how products get made. That's kind of what I'm trying to effect through what I'm trying to do with Tafifi. I want to have that kind of positive impact on the product management community, but just people.

When I designed The Product Group, The Product Group was designed about what I like. I used to go to meetups all the time and they were so dry, and I never liked the presentations. It didn't feel interactive. I didn't feel like I was necessarily learning. I was falling asleep. You had these moments to do some networking, but that was okay. I'd come home like, "Yeah, I went to a meetup.." The Product Group was about I wanted to learn. I wanted it to be interactive. I wanted other people to say they learned something at the event, but I also wanted to have a featured product, and that's what I do at each of these meetups. It's round table style and I have a featured product, and each of these featured products, what we do is we take it apart. What product person doesn't like to dissect another person's product and think about how you might do it differently, and different strategies, and different approaches? I like that. I like solving problems. I like hearing problems. I like hearing how other people solve those problems. That's really what kind of keeps me going.

Suzanne: Yeah. I think, you like helping people too, which I definitely resonate with. My guess is that your wait list at The Product Group mentorship is about to get a whole lot longer, but that's okay. That's okay. He wants to help all of you, listeners. Are there resources that have been help to you? I mean you're a senior person. You've got a lot of ideas, but is there a pundit out there, a book out there, just something that you're like, "This shaped me, helped me"?

Jeremy: Yeah. I can't recommend enough Eric Ries, Steve Blank, their blogs, their work. What's had the biggest impact on me is really just networking with other product people and learning from them. For me, I never fully internalized Lean until I met this person who did Lean in a whole way I had never thought of it. I said, "Oh, my God. Now I get it." That was like a very magical moment. It was 2010 I remember, and it was very kind of a special thing.

I didn't get that from the books. The books are very abstract. They don't feel like they're applied. Some of the blogs are interesting, but for me it's you want to hear the stories, you want to interact with the person who did it, and you want to ask them questions. Whether or not it's The Product Group, which is New York and London, or other meetups, you really want to network with these people and take them out to coffee and pick their brain. Like how do they do the product management? Maybe they don't do it well, but learn what they're doing, and what works, and what doesn't. You've got to talk to a lot to find some of those golden nuggets, but I've found it's really been the networking.

A lot of the stuff I do generates a lot of knowledge, so that's why like I have that YouTube channel, I have the blog where any knowledge that I'm capturing in product management I can kind of share back to the community. I try to do that as much as possible, but at the end of the day if you're looking to just learn product management, whether it's process or you're trying to solve a problem, I'd recommend networking at a lot of the product management events, but networking in a way like go out for coffee for an hour and pick their brain on something. I try to do that with as many of the people at my own meetup as possible.

Suzanne: Great. Typically, I ask my guests as a last question about a personal or professional mantra, but earlier in the conversation you alluded to this mentor of yours and had a bunch of soundbites that you've stolen. You promised that you were going to litter this conversation with them. I don't know that you did. Is there one or two of these gems that has served you well you want to leave us with?

Jeremy: Yeah, there's one. I actually told people this, and I know when I don't deliver this well it comes across as very mean. He was not a mean person. He was a very scientific person. He was a very matter of fact person, but he always wanted to kind of drive home the point. I remember the lesson he said to me was, "Jeremy, this is a very important lesson. You're not special." I remember sitting there going, "Why, thank you." Then he continued. He says, "Your idea is not unique," and I'm like, "How do you know?" The lesson really was, that he then went to explain, was if you're on the cutting edge in your field, whatever you're doing, there are other people on the cutting edge. You are not alone. That means that it's not just you. It could be someone on the other side of the earth. There's like many other people doing the exact same thing as you. You're not special. You're not unique, and actually other people already have your idea.

He was saying that at the time because I was doing so many different things, but really what that kind of boiled down to is pick one thing and execute it well. Don't hide your product. Don't be secretive. Tell everyone what your thing is. At the end of the day, it comes down to who executes it better. That's from him saying, "You're not special," that's what he was getting at.

I constantly requoted it over the years, because too many companies, too many products, "It's a secret." They can't tell you, or, "Sign this paper." I just look at you like you're a crazy person. I don't know if you can execute. Someone else might be able to execute better than you.

At the end of the day, do you know what? You want to talk about it because you're going to get better data, you're going to get more information, you get other people's ideas that'll mingle with your ideas, and hopefully you end up in a better place. If you're secretive, you're not going to get the data you need, and you're going to be operating in a black box, and you might luck out. Congrats. But why not maximize your chances and minimize the risk by talking to as many people as you can about it? Because at the end of the day, you're not special.

Suzanne: Well, listen. Jeremy Horn, you may not be special, but you have been so fantastic to chat with, and I really thank you for being part of our project.

Jeremy: Thank you. Thank you.