Industry Domain Experience: Let's Talk About It

Oh boy, this is one of my favourite topics when it comes to product management. Let's first recognise a seasoned product manager is very different from the associate level. Hell, even a product leader (who does not have to be the product manager) has a different level of experience. Too many job postings out there have these harsh requirements that pretty much rule out someone who will bring real value to your organisation. Even worse? Your application might not even warrant a call, and it gets chucked in the bin after waiting weeks on end for a response. Now don't get me wrong, in specific industries, it may be required or extremely beneficial for an advanced degree or domain expertise,. However, I honestly have never turned down an application because of someone's education or lack of industry domain knowledge. For me, a phone call is needed to find out who that person really is and what value they can bring to the table. Recruiters have that tough job of sorting out the CVs as a first step and often don’t get the key words correct or articulate the matching experience. So, if you are in a larger organisation and get hundreds of applicants, you aren't going to be calling 200 people for sure. However, a good recruiter should be versed in the same things I am going to talk about here, finding that product manager skillset and passion. That way, I feel confident that they are finding those candidates I want to chat with. That's why I love to see more and more recruitment firms out there now focusing on product management recruiting for organisations. Selfishly I still want to see all CVs to be sure sometimes. 😊 

Getting back to the industry domain piece. Oh, right, check out Scott Uhrig's blog about how he breaks down domain experience. What we are talking about here is both primary and secondary industry experience when it comes to the domain. Primary being something like software, and secondary would be ERP software. Getting turned down due to primary domain experience would be ludicrous, but getting nixed for not having that secondary brain grain is mind-boggling. I once hired a dude who worked with printer software as a product manager to work on a data migration tool. Gee-whiz friend, why did you hire that guy?? Let's get into that a little bit and hopefully change your mind about who you should look for moving forward. But first, back to the application process.

How many interviews have you been in where they hammer you about an understanding of the products and the industry focus? Should you have an idea of what exactly you are getting that yourself into? Absolutely, you should do some research on the company you are asking to pay you large sums of money before engaging with them. More importantly, you should be interested and excited about the product you want to manage after looking around. I'm more worried about hiring the individual who could care less about what's being built and is just looking for the $$$ at the end of the day. Steer clear of any product management openings if you aren't excited about what you are building; we beg of you. If you want to hire the right person? Look for someone who wants to get to work right away, and you can hear the passion as they talk about why they want to work for you, and that's not coming from a cover letter, folks. Sorry-Not-Sorry...

I have enjoyed being around folks who have come in with primary and or secondary industry experience and some who have had no exposure whatsoever. Even with this "needed" experience, that doesn't mean you're going to flourish, especially if the product line is different. A good product manager can first look at what problem it is that the product is trying to solve. Most importantly, what's the outcome you are looking for? What's that change in human behaviour that you seek. If you haven't picked up a book or asked your mentor about outcomes vs. outputs, you probably should after you finish this article. You might have a quick realisation that while you thought you were achieving what customers are looking for, you might not be. That's growth for you, and you're welcome. 😊 

Let's get back to the good ones out there who are the right individuals for the job. One product manager I worked with came in off products light-years away from what we worked on. I had already interviewed dozens of candidates and this person was the last one. One of the techniques I always make sure to avoid is stress questioning. You want the individual to want to work with you, not the other way around friends. It was more of a conversation for us, and I knew this budding PM was a digestive listener and looking for something exciting to build. Their value wasn't in domain experience; it was in their skills as a product manager. This person had resourced knowledge from their start as a PM to understand the customer's needs, no matter the industry. I was impressed enough that I knew they would thrive, and I could act more as a mentor than a line manager. This, this is the person you want to hire folks. They're out there, waiting for their next opportunity. Ready to build and manage something based on some crazy idea we had. I can now report back to you that this person flourished within a month's time. They took something I started and brought it even further, all because some of us believe that a conversation can tell a lot more about someone's skills than experience on paper.

Next time, I'll talk about avoiding the con artists and psychopaths that slide into companies regarding the interview process. They're out there, and if you have read Thomas Erikson's book, you will want that skill set of navigating around them.

Your Personal Brand: RND 2

“Don’t let negative people keep you from seeing the positive still around”

– Some genius

It's funny, isn't it? When you pour your heart out about a particular subject, you realize how many mistakes you've actually made along the way. I talked about a personal brand before in another article, covering things like the truth and doubling effort. I didn't talk about what happens when you start to grow and see the "toxic" people around you. Remember when I said we are human beings and we make mistakes? Yep, that's the truth! It's an illusion to think that we all navigate the same path in life, even if our circumstances are the same. Being a product manager is a heavy responsibility, especially since it's now a recognized profession needed in every organization. While you have to deal with discovery and delivery, you also have to navigate through the human emotions around you. Let's talk about that for a second…

I'm not a saint by any means. I have made my share of mistakes; some of them have cost friendships even. However, through all of my mistakes, I have learned I can be a better person. The people around us deserve that same chance that we were given (most of the time). Why do I say that? You want to see them grow and make that one-eighty back to success town. Okay, now how does this all tie into what I was rambling about in the first paragraph? When you set a positive leadership example, things generally turn out successful for us.

I remember being in a meeting once where there was a heated argument about a specific design that quite a few people had disagreements with. We certainly aren't going to name names, but a couple of them were not such friendly individuals. When I found some room to open up, I immediately broke down the problem I know we were trying to solve. Knowing that they had specific techniques on approaching customers, which I did actually like. I offered up those same options to how we can get a little solved now and that they could work with five of our customers to see where the pain points were to get us to a mature state. I remember one of my colleagues next to me, shocked with his mouth wide open after everyone had left. They were confused why I agreed with the people they were just arguing with, plus offering up them to do some more reconnaissance work.

It's simple, really, I want to be someone with whom others are comfortable working with. I don't want to stampede, fail to listen, act arrogant, or any of those other negative traits we sometimes harbor. Even though I know some people can be toxic, I have to navigate with or around them. You can still be successful and build success in others, even with these folks around you. Hell, you might even make them see something in you that they want. Next thing you know, you're chatting with them about some of the mistakes you have made in the past that they can relate to. However, sometimes you definitely have to get the hell out of there if you feel you're at a stage in your life very different from those around you. You're a valuable individual who wants to do your best work. You want to grow and be a part of an EPIC product-led company strategy. I'm here to tell you, you deserve that.

In closing, remember that there are many of us out there with shared experiences in what you may be going through. Some parts of product management can be highly stressful (failed launch dates, anyone?). How you approach a situation working with someone, even if they're toxic, is vital. You have a focus and a personal power within you. You can shine in a world of complaints by resisting the temptation. Arguments go nowhere, and we need individuals like you to steer us back to success, where we all belong.

Requirements for Requirements

Do you ever get frustrated when writing up your product, feature, or even option requirements for development? I don’t mean frustrated as in, “maaaan this is a lot”. I mean the frustration knowing they’re going to get torn apart because your friends in development loooove digging into the weeds. Rightfully so, I have always found the best developers come out swinging with concerns when we bring them what we think is enough to get them going. “Come on, really? Do you really need more information?”. The answer is a big fat, YES! It’s been successful for any product manager I know to be working with the development leads, at least when drawing up your first set of requirements to get the groundwork laid out. This helps when you bring them in front of the broader team to discuss what it is that you want to build, why, and for who.

The key is not to take any of this personally. We all get agitated when we are told to create yet ANOTHER ticket or to fix the wording of one sentence that you think is already clear enough. The apparent truth is that you need to make sure you have requirements for your requirements. Yes, the title is not a play on words; it’s serious. You need to suck your pride and always ensure you have some rules when it comes to drawing up those lovely little demands. Whoops, did I say demands? :smirk:

Here are a few that have helped me in the past when it comes to writing out requirements for dev:

1. Swallow your pride: you’re not a know-it-all! Remember that old saying, “while your opinion is interesting but invalid”? What I mean is you have to be specific and even loop in your dev friends to make sure you’re writing your needs clearly so that they understand where you are coming from. However, the more you work with your squads, the more you start to understand the lingo. Otherwise, you’re in deep…you know.

2. Read up: chances are there are some really great examples out there on how to write them up. I have been subject to third parties coming in from time to time and shouting agile until their faces turn blue. If you currently aren’t happy with how you’re being taught, why not have a look out there to see what the PM world offers. Who knows, you may find some method that really takes to you. The smart money says other PMs in your org probably feel the same way you do and are looking for a change.

3. DIAGRAMS: I cannot stress this one enough. You need diagrams with user flows showing how your thingamabob actually works with the user at the wheel. I get slammed when I am missing what would take me 10-15 minutes to make in between cups of coffee (I don’t drink that much coffee, I’d die). The best part about this is that your devs will appreciate that you have thought about all the scenarios that your game-changer will possibly have.

4. Ask for help dammit: I mentioned before about bringing in your dev pals for help when needed. Why stop there? I hope to Santa Clause that you have a mentor or people in the field around you that can provide some advice or help proofread some of your...I’m not saying go out and share your classified work with people outside your org, duh. I’m saying you should have a template by now that you use and could do with some proofreading. I’ve been lucky enough to have bosses who have been amazing mentors in the field. Now, I do realise that’s not the case all the time so search around in your company and gravitate towards that kind-hearted sole who can be tough as nails and tell you how it really is

There you have it—some examples of requirements for requirements that might be familiar to you or even new. If you’re just starting out, I know how tough it can be to try to get some ground, and quick. I hope this article helped, but if it was useless…hey no problem! I’m sure there is someone else out there who can give you the information you need. I’m just a lowly product manager, after all, trying to make my way in the world :)