Zohra Mubeena-Mutabanna: 0:04

Hello, listeners. Welcome to Inside Tech Comm With your host Zohra Mutabanna. In season three, we shift our focus to shed light on why Technical Communication is a core business asset. In this regard, we will speak with guests who are our stakeholders, such as product managers, marketing professionals, UX designers, QA and customer support, who engage with writers to create a seamless experience for the customer, and meet business goals together. Let's get started. Hi, folks. Welcome to Season 3. I'm excited to interview our next guest for this episode. Our guest today is Bill Gly. Bill is a customer-focused product management profession with extensive experience in Agile and Scrum. He is currently the Director of Product Management from Massachusetts, currently residing in Florida. Hey, Bill, welcome to the show.

Bill Glynn: 1:07

Thank you. Zohra. Good to see you again.

Zohra Mubeena-Mutabanna: 1:10

Good to see you. Good to see you, too. I'm so excited. And full disclosure, guys, Bill and I have worked in the past many, many moons ago. And Bill was actually the first product manager that I had the good fortune to interact with. And I walked away with so much knowledge and positivity. So I'm really excited to talk to Bill.

Bill Glynn: 1:32

Thank you. I had no idea I was the first product manager that you had worked with.

Zohra Mubeena-Mutabanna: 1:37

Yes, as a matter of fact, you were. And with that Bill, please tell us about yourself.

Bill Glynn: 1:42

So I am a product management professional. I started my career as a software engineer in data comm and telecomm space. But I made a career change and focused on product management, and moved into identity and access management and risk management and software as a service type products. And that's where I met you.

Zohra Mubeena-Mutabanna: 2:02

Yes, absolutely. Now, would you like to share with us what identity and access management means, risk management means because I think our audience could benefit from understanding more about that field. Sure.

Bill Glynn: 2:17

That's a pretty broad topic. But the way I usually explain it to folks, that identity and access management is focused on people within companies and making sure that these folks have appropriate access to the resources that they need in order to do their job. And so managing that so that they have appropriate access, but not too much access, which introduces risk into the equation, such that they can effectively do their job without having access to things that are sensitive in that could be personal data, or financial information, et cetera.

Zohra Mubeena-Mutabanna: 2:55

Awesome. Another thing that probably would benefit our audience is understanding what is product management.

Bill Glynn: 3:02

That is a big topic. So product management varies greatly from company to company, and industry to industry. But product management is a discipline that resides, it has a foot in each side of a company, meaning the business side and the development side. So it spans the gap between the dream of what the product needs to be and the development of that dream. And product management is the bridge or the conduit between those two endpoints, if you will. So product management is responsible for working with the sales team and marketing team and the market and understanding customers and working directly with customers to understand their challenges and their problems. And bringing that information in house and working with the development teams to focus in on the most appropriate problems to get addressed and defining what a good solution to those problems would be. And then bringing that information back out. So it's a continual cycle of going outward, in and then inward out.

Zohra Mubeena-Mutabanna: 4:19

I love that I think you have encapsulated your job description so beautifully. It's something that I have known, and I think this summarization will really lend well to our conversation as we talk more about how your role impacts what technical communicators do and how this partnership sort of feeds into each other across disciplines.

Bill Glynn: 4:45

Well, I was just gonna say a former colleague of mine from Juniper had and probably still has on his LinkedIn page, a little tagline about what product management was to him and the thing that really appealed to him was you get to have all the knobs, and you literally do you interface with every discipline within a company at some point in time, and you have responsibility to all of those disciplines, you need to interact with them all. None of them report to you, of course. So you have all that responsibility, but none of that authority. So there's a lot of negotiation, there's a lot of interaction, it can be a pretty broad job,

Zohra Mubeena-Mutabanna: 5:27

I can understand that. I was reading an article yesterday, as a matter of fact, and the thing that this product manager was trying to say, you're not just like how you, you were trying to summarize, he called his profession, a cross functional leader with no authority.

Bill Glynn: 5:42

I would definitely agree with that. Okay.

Zohra Mubeena-Mutabanna: 5:45

Yeah, and the challenges that come with it, but also, because you are at the intersection of so many disciplines, I believe that you will lend some great value to the conversation that we're going to have today. And the reason we are here is for season three, in this season, we are going to talk about so far in my previous seasons, we have talked about how technical communicators became technical communicators, what are the different disciplines within technical communication? And in this season, we are pivoting, and I'm interviewing stakeholders such as you to share with us why, in your opinion, is technical communication important and why we are a business asset? Because that's something that technical communicators have, have sort of tried to find a voice within a company? How can we sort of shine a light on what we do? It's been a challenge so far. And hopefully, with this conversation, we shall discover, in what way do we contribute to the business side, not just to development? And what can we do as writers to support our stakeholders?

Bill Glynn: 6:57

That's a pretty broad topic as well.

Zohra Mubeena-Mutabanna: 6:59

It is a very broad topic. Absolutely. And we are not looking for answers. We are looking for partnership collaboration and some learning, and some insights from each other.

Bill Glynn: 7:10

As you may remember, when we work together, that was a big part of it, which we spoke a lot. And we sat down and we talked and we use the whiteboard, I would share with you what we were building and why we were building it and how it was going to operate. Not all the way down to the minuscule details, but at a sufficient level so that you could take that and turn it into a customer facing explanation of what they were getting, and why that was important and how that would operate. And what benefit they would derive from that. When you talk about technical communications. Just like in agile, it when we develop products, we talk about personas, because you're not talking to a single person, you have multiple audiences, just like when we build a product, we have multiple audiences that are going to be using it. And so that has to be kept in mind, as I know you do.

Zohra Mubeena-Mutabanna: 8:07

Absolutely. And what you just said, where we sat down together and talked about it. The one thing that I want to draw attention to is you talked about agile, and Scrum. Now, in my past, when I was with companies that had waterfall as their development process, I did not work with a product manager. So one of the drawbacks that I faced as a technical communicator was I did not get the opportunity to sit with someone such as you to understand the why of the why of the product, why it is being developed. What are the customers needs? What are their pain points, when I worked with you, that was an opportunity for me to ask you those hard questions before I went and just wrote the customer-facing documentation,

Bill Glynn: 8:56

it's important to have that resource to get further detail. So I don't know how you would have done it. Without having I mean, it could have been someone else. But when you mentioned in Waterfall development model that you used, you didn't have a product manager. Now it could have been someone else but you need that resource that understands that bigger picture. And then whether it was waterfall or agile that really is an aside really stems to who's driving the train.

Zohra Mubeena-Mutabanna: 9:23

Right? You make an interesting observation that it doesn't matter whether it was agile or waterfall. However, the challenge that I felt a with and again, I'm not trying to say one development lifecycle is better than the other. But I just felt that with Agile we had more access to to more stakeholders, because with waterfall we were only working with generally with QA. So the product was already developed and it was solid. What we were doing was documenting what was already developed. And that was the challenge. With Agile you have the opportunity to pivot, just like the product pivots, you get to pivot with the product, and you have a chance to really address your audiences, the personas, the challenges that they may be feel facing, and address that upfront, rather than wait until the product is ready to ship out the door.

Bill Glynn: 10:21

It's another voice along the path that would potentially influence what you're doing or how you're doing it. So you mentioned the example of being at the sort of at the end of the process, it's already been developed, it's been tested, it's close to ready to ship. And you're just documenting what is, as opposed to telling the story a little bit further back in the process to say, here's what we're doing that you wouldn't document all this part. But your writing would be influenced by the part that says, here's what we're building. And here's how it's going to work. And as you that's the technical communicator there, as you're writing about that, looking at what it is, you have the sense because you're going to be close to the customer. Does this make sense? And that's another audience that can help influence that. So product is trying to determine upfront, does this make sense? What are the requirements or the acceptance criteria for a product deliverable, but you in that role would also be part of that if you are involved further up front.

Zohra Mubeena-Mutabanna: 11:30

And this is a good segue, the case that I'm trying to promote, is to try and have writer's voice more upfront, just like you mentioned, to some extent, you also shared the why or why that would benefit one because I become an informed writer. And of course, I'm not going to say the story of I'm not just saying the "what" is, but I understand the "why". And then I'm able to get closer to the customer. So that's an advantage. I have been at companies where writers have not been given their due. And it has, it's sometimes been a struggle. Now, when you and I worked. I think that partnership worked really well, from my perspective, one, because we were agile. And to some extent, I've worked with several companies since then. And I believe that at Courion, we had a really good Agile Model, or we implemented it in a way, that from a writer's perspective, I cannot speak for the other stakeholders, but from my perspective, I really got to be part of that entire journey all the way even when UX was in the picture trying to get the wireframing or the conversations prior to that. Sometimes you and I and the UX engineer, and the team would sort of sit around the table. And just, you know, like you said, we would whiteboard and we would discuss what are we doing here? What is the intent? What are we trying to achieve at the end of it. So those discussions helped me tremendously, to really become an informed writer. And I think it also sort of helped me understand the business goal. That's something that was not obvious to me, as a writer at places where we didn't have this access to information.

Bill Glynn: 13:18

I think that's important, because ultimately, you're writing for the customer, who's going to accept the product to address a business goal. So the product has to be built with that business goal in mind. And the documentation that goes along with that product has to be developed with that business goal in mind. So that all forms together. Otherwise, it's disconnected. And it doesn't make sense. Or it may not make sense.

Zohra Mubeena-Mutabanna: 13:48

Right, right. I mean, so far, it may appeal to our audience that all I'm doing is complaining. So. And that's not the objective for me here. My goal, really is to understand, from your perspective, how do you see writers? What is that partnership from your end? And what do you expect to see in achieving with that partnership?

Bill Glynn: 14:11

So for me, unfortunately, this is not necessarily the case for every company, right? Every company operates a little bit differently. And I've seen writers are the technical publications department, how do you like to refer to it? We can

Zohra Mubeena-Mutabanna: 14:29

call it technical publications.

Bill Glynn: 14:31

Okay. So yeah, that discipline that group has is not always given the appropriate latitude and a voice at the table. And that's also true of product management and some companies too. So it's the companies that do better at this tend to do better in the marketplace, my personal opinion. So I think it's important because it represents something thing, it's part of the whole product. So as a product management professional when I sit down, and I'm looking at what are we doing, we're building a product could be a software based product is software as a service, something resides in the cloud. And it's an application that you just log into. But ultimately, you're providing a product to a customer or a stakeholder as a general statement. But it's not just the software. It's the whole product. So in other words, if I provide you an application you can log into, and then you say, No, how do I do X, whatever X may be, if you don't have good quality documentation that you can refer to, that's a ding against the product. That's a detraction from the whole product concept. If you have a problem with something, and it's not working correctly, and you can't get a quick connection to support and get your question answered, that's another type of failure on the whole product side, looked at the marketing brochure, talk to the sales folks. And they described something that the product really just doesn't do. That's a different, and yet another, but a different type of failure. These things all have to hang together for the customer experience to be a quality experience,

Zohra Mubeena-Mutabanna: 16:19

Customer experience to be a quality experience, I think, that says so much. From this insight, what I'm taking away is you consider this is what I'm inferring, rather, is that you consider probably documentation to be part of the product itself. It's not something separate from the product. Am I understanding that correctly?

Bill Glynn: 16:42

Absolutely. The documentation, the marketing collateral, the white papers, you know that you might write the brochures, it's all part of the product, they serve different functions, but it's all part of the product. But documentation is even more closely aligned with the product than the other thing I mentioned. Because that's part of the deliverable the like, you can't, or you will struggle to use one without the other. Right. So I can sit down and read documentation and sound that makes sense. But if I'm not sitting there with the product and able to log in, it's abstract, logically, it might make sense or whatever, but I'm not going to remember it, and I'm not. And likewise, if I sit down with the product, then I'm trying to fumble my way through. Some of it may be intuitive, and everything. But if I can't look things up to go, how do I do this, I may be in the wrong area, I'm going to struggle. So those two things need to go together. And when we spoke earlier about the different types of audiences, if I am a day to day user, and I am going to use that product, I'm going to log in every day, I'm going to spend a good chunk of my day using the product, I may use the product documentation early on. And then I become more familiar with it. And I don't need it as much for the functions that I'm doing day in and day out. Right? As soon as I stopped doing one, then I go "How do I do that I want to go back and and relearn that?". But now take in that's one example of a heavy user. But now take the admin of that, or the manager of those heavy users of something, they're not in the product every day are certainly not using it throughout the day. So they have to go do something where are they going to go? Are they going to call on the phone say, can you walk me through this? And the answer is no, not not usually, they need good quality documentation to refer to in order to at least get them to an appropriate place where they can start to do whatever it is they're trying to do.

Zohra Mubeena-Mutabanna: 18:46

The second use case that we just talked about, where if I want to understand how this works, I'm not going to call support to ask them, Hey, how do I use this? I would usually call support when something I have used and it's not working as expected. Would that be right?

Bill Glynn: 19:04

In my opinion? In my experience? Yes, that's an accurate depiction, which is I'm calling support when there's a problem. Now the problem could be didn't read the manual, or I don't know how it works. And I thought it should work this way, and it just doesn't. And so then I may call support, and smart and support may direct me that, you know, it doesn't do that. Or you're in the wrong area to do the particular thing. You want to do something like that. Right. But in other words, that's not my first move is to call support to go, oh, geez, I need to do X and I don't know how to do X and I'm not willing or I don't have the manual handy or whatever. I don't call support. I'm either going to look at the manual, or I'm going to try and figure it out. And I'm only going to call support if I get to the point where I feel something's wrong.

Zohra Mubeena-Mutabanna: 19:51

Again, I want to kind of elaborate on why I sort of painted that picture is generally you mentioned the different personas and some personas are highly technical, for example, the admins, maybe, you know, if you're configuring a product, and that may require you to, you know, there's a high likelihood that something may not work as expected, and you will have to call customer support. But somebody who is technical, they will, in my experience, it's been that they will try something first. And if it doesn't work, then they will reach out why? Because those customer support calls can be expensive, too. So from that perspective,

Bill Glynn: 20:29

Yes, customer support calls are very expensive for the company, and as well as the user, because you usually don't get right to to a human being, you have to go through some automated phone logic to get and then due to heavy call volume, have you ever heard that greeting. So you could be on hold for a long time waiting. So I think, you know, certain types of user behavior can cause their own problems. So in other words, you've probably heard the phrase, you know, read the manual, usually has a little bit more color to that, but read the manual, because the manual will tell you how to do something. And people don't necessarily want to go read the manual for everything they want to do. There's this expectation that the product should be intuitive enough that a reasonable person should be able to log in and do something. And you could make that argument for up to a point. But the more complex the product is, the more things you can do, the less likely that argument holds water.

Zohra Mubeena-Mutabanna: 21:36

Yeah, I think I would agree with you on that the more complex the product, no matter how much intuitive the design is, there has to be content that goes along with it to improve the user experience.

Bill Glynn: 21:52

Exactly. Yep. And I mean, the user, many users, certainly of the business applications, I find are willing to pick up the documentation. And when I say pick up the documentation that can come in multiple forms, right, that could literally be a book or, or something, it could be an online document that you could roll, or it could be context sensitive help, right? That type of thing, but engage with the documentation process to figure something out. And the good quality and quality has many aspects to it, but clarity, that I can understand it comprehensive so that it covers all the things that are really needed. And understanding, is it accurate, right? So does it flow through. So the good news is, in my experience, good quality documentation has been beneficial to overall customer satisfaction. But the flipside is also true. It can detract from an otherwise good quality product, it could drive people to call customer support, and be frustrated, etc. So when we measure customer satisfaction, and do capture metrics, such as NPS scores, people have called out both pros and cons, the documentation has been outstanding, the documentation is horrible. No, whatever it is, and of course, neither one of those cases is accurate, right? It's a lot, I went to look at the documentation for the particular thing I was trying to find, I had a hard time finding it, or it wasn't clear as to what I needed to do. So they're gonna say it was horrible, right? Or I found the one thing very quickly and easily. So it was awesome. Those are data points. That's not the general status of the documentation. So it's important to find out okay, well peel that onion back a little bit. What were you doing when you did that? Why did you think it was this or that? Net Promoter Score, Net Promoter survey. So basically, it tries to establish how customers feel about your company in your product. So it's through surveys, direct surveys to the customer, to get a sense of how the customer is feeling? And would they recommend you to their friend or other prospects, that type of

Zohra Mubeena-Mutabanna: 24:19

thing? That is definitely helpful. I learned something new today. Coming back to what you just shared, you know, documentation can be good, or it can be horrible. And generally, I believe in a user journey, when somebody is trying to look for those answers, they are already frustrated. And that is the time when they're probably looking at documentation. So I believe nobody just picks up documentation and reads it for the heck of it. I would agree with this. Unless you're my daughter because my older daughter does that. Even before she opens her new phone. She wants to go through the documentation first, before she interacts with the product. As a technical communicator that makes me so happy. Because somebody out there values, what we do, again, thinking about the user journey, when you're looking at documentation, you are looking for quick answers. And if you're not able to find that it is hard, so how content is architected, how it is not just written, but you know, architected and presented, and the medium through which you're accessing that content can really break or make that experience better.

Bill Glynn: 25:27

I definitely agree with that, you know, we're all consumers as well, right. So even though I build products, more or less for a living, I'm also a consumer of products. And I get frustrated when, you know, the product isn't up to standards, or the documentation isn't up to standards. And I have a little device that I bought to do. And it was cheap, it was $10 or so. And it was just an Ethernet tester. It was a cable tester. So I could test my Ethernet cables. And it came with, you know, you've probably seen this just a little folded up piece of paper, you know, it's very tiny. And so it's very small, hard to read, etc. But that's my first impression. Right? Before I pull that out. And I, I may look at it, like, oh, how do I need to use it? And it's horrible in this particular case. So that's my first indication that, if that's kind of the care that they put into the documentation, what kind of care do they put into the design in the building of the product, and it turns out that there, it's about the same level, which is very poor.

Zohra Mubeena-Mutabanna: 26:36

Oh, I mean, that is an amazing, amazing insight there because it is so important, it really sort of reveals to you how they treat the customer at the end of the day, because you're not thinking about the customer experience.

Bill Glynn: 26:51

Right? You know, and then when I went online, and you know, I bought this on Amazon, I looked at the ratings, and whenever you buy anything, I don't care if it's the closest to perfect product, you're going to have these people that read it as a one for one reason or another. So you have to go through that and kind of figure out, it had a reasonable rating, so I bought it. But after I ran into this, these problems, that the documentation was an indication. And then when I started using it, it didn't work correctly. And so I had to reverse engineer what was going on with the device and determine that it was defective, the device was defective. And so then when I went online and looked at some of the reviews in more detail, I saw people saying exactly that, that they one person said basically don't even bother to pull the document, you know, to open the little pamphlet, it is garbage and throw it away, it will have zero benefit to you. And I would agree with that. So that's just an indication if you buy. And this is part of going back to my whole product concept, right? We're talking about consumer goods at the moment, but which is not my area of expertise. But if you were to buy something, and it shows up, you've seen how Apple products are packaged as an example, I had another little thing here that was packaged, but it doesn't matter. The point is, if it's packaged nicely, now you can go over the top with that tip. But if it's packaged in a reasonable way, that's all part of the feel of a quality product, as opposed to it shows up in a clear plastic bag with tape. And you know, it's in plain cardboard box or whatever, right? So these are all indications of what is going on when people sit down to think about this product. From all aspects.

Zohra Mubeena-Mutabanna: 28:44

This is an interesting analogy. I'm trying to get a little metaphorical here, all these little stories that you shared, metaphorically speaking, if you have an excellent product, but everything else around it has been forgotten or left out or compromised, then the product experience is not going to be as great. For that reason alone. It is important that all stakeholders not just technical writers, but all the other stakeholders such as UX designers, product management, writers, and probably UX research. If you have the access, I mean, all these different stakeholders need to be collaborating and interacting from the very start, and not at the very end. So that I think to me, it sort of reveals that problem as to why this conversation needs to happen. sooner than later.

Bill Glynn: 29:36

I would agree with everything you've said with one slight change, which is it's not just at the start. It's continuous. So in other words, yes, it's important to be there at the beginning, but it's continuous. So it's continuous engagement, not just capturing your thoughts at the beginning. And then by the time we're into something we've made 100 different decisions that brought us to a different place than what we initially have spoken about. So going back to the person you mentioned earlier on in the conversation that said, the cross functional leader with no authority or something like that, I mean, that's what we're talking about. It's a cross functional team, making sure all the stakeholders have a voice into this. And that it's, I'll use the word continual, but it's not literally continuous. But it's periodic. And it's regular. And it's, there's a cadence to it. And so, I think that's very important.

Zohra Mubeena-Mutabanna: 30:34

I completely, completely agree with that. It has been beneficial to me personally, when I have been, quote, unquote, continually involved. Because what I've noticed is that when I am continually involved, not only am I able to address whatever may have come up, but I'm able to pivot quickly. And I'm able to be again, going back to what I started with being an informed writer, I'm able to ship the product with documentation faster out the door, because I've been part of that continuous journey from the beginning.

Bill Glynn: 31:12

Exactly. Omitting documentation or tech pubs from the process would be just as detrimental as omitting the software team, right? Because they're writing the code to make it work, the way that you're writing, the documentation says it works, those two things can't be divorced from each other. So it's important to keep them aligned. You mentioned earlier on that I was the first product manager that you worked with, and the fact that you stayed in the discipline, I'm really happy. But when we work together, that was actually my first experience with Agile Scrum, I had always worked in waterfall up to that point. So when I was an engineer, I developed under the waterfall methodology. And when I transitioned into product management, I did that under waterfall for many years. And it wasn't until we work together, that was my first journey into Agile Scrum. And it was completely foreign to me. And, and I remember struggling with it saying seems like an awful lot of wasted time, and et cetera. But I was coming with a different mindset. One of the differences because there are many, but one of the differences is that in the waterfall methodology, you do all that work upfront, and you solidify a lot of decision, you say this is what we're going to build. And we're not building that. And this is how we're going to build it. And this is how it's going to work. And it's only going to do that. And that's all locked down, then it goes through the process of getting built. So the cross functional team aspect, although it still has a place and that methodology, not to the extent that it does an agile scrum, because the plan doesn't change. And if it does, it's usually a big event. And so whereas in Agile Scrum, you are figuring it out as you go. In other words, you have an idea, you have a kind of game plan in mind. But you're iterating on that all the time. And so things change. So it's more important to have those cross functional team meetings, keep everyone aligned. Because you're changing the game plan. It's changing, it would be like, you know, in a football game, just run it out onto the field and not having the huddle and say, Okay, this is what we're going to do now. Right, everybody has their own idea of what the and you would have disaster

Zohra Mubeena-Mutabanna: 33:39

That really drives home the point as to why cross-functional teams need to be collaborating. You got to huddle, as you said, you got to huddle. And I think that's probably become a very common practice, at least at the company that I'm at, where we use the word huddle for stand ups. Yeah, yeah, it was interesting, I would have never known Bill that you came from a waterfall background because you fit so perfectly in, because I felt like you were sort of the shepherd, for the team. And with the project requirements, and backlog and the prioritization, it really sort of made my job much, much easier. Because I knew I knew, like you said, I was aligned, I was better aligned with the team. And I knew what the expectations were, nothing was thrown over the wall. So I think the process itself worked. Personally, this is my personal opinion, it worked in my favor. And for all the above reasons why because we were continuously engaging. And you know, we were not just at the start of the process. We were not at the table just at the start of the process, but throughout the entire process. And we got to pivot if needed. But we were all doing it together. This journey was not just the developers or the testers, but everybody together. And that's why we've been talking for a while Bill, and I know I promised you that we will kind of get to the meat of it quickly. But it's been so interesting so far, and I'm hoping In that, with every conversation that we are having, we are bringing to light, sort of, like you said, peeling the onion. Right? You can do that quickly, you got to shed some tears before you get to the meat. Okay.

Bill Glynn: 35:13

But there is this cry now?

Zohra Mubeena-Mutabanna: 35:17

Hopefully not. I hope I hope not. But I wanted to ask this, this one question. In your opinion Bill, you know, you worked with writers, hopefully those experiences have been good. Because even if the customer feedback is whether it's horrible or great, the partnership that writers and product management sort of share, my goal is to elevate if writers are doing something that has not worked for product management, or in your experience, what is it that we can do, that probably could make us a better business asset.

Bill Glynn: 35:55

I think being engaged is the most important thing. So product management, this, again, will vary by company greatly. So product management is a varied discipline, going back to our earlier conversation, I talked about spanning that gap. And that that gap is different at every company, sometimes the gap is easy to cover, sometimes the gap is hard to cover, and sometimes all of the gaps exist. And so product management has to pay attention to all of that, you know, so we're constantly cycling between different teams, etc. So I think, from your perspective for the technical writers, is to stay engaged, make sure you're communicating with the product management folks, and asking questions, right, product managers are really good. They are should be really good answering questions. So they do that day in and day out for a variety of stakeholders. So asking questions about what's going on, and what you're doing, or how important this is, or that type of thing. I really appreciated that you involve me in the reviews, I, I tend to do write a lot. So I'm not sure if you appreciated me being involved as much as I appreciated you involving me, but involve them and get their opinion and, and stay in touch. And that's not just product management, right. So do that with the engineering team as well. And I would say that take an approach similar to what product management is doing, which is to talk to a variety of stakeholders. So because this documentation that you're writing has different audiences, and you have different audiences within the company sales will have a voice, understanding what the customer is expecting, and that type of thing. Engineers will understand what they're building and whether it's accurate. So and those two things are really important, right? So the accuracy, staying in touch with the development team, and the QA team, and then being able to explain it in a way where the average business user can understand it. And you're gonna get that from sales as well as product management. But I'm just saying if product management is not involved, not available.

Zohra Mubeena-Mutabanna: 38:21

But okay, I want to answer your question. You used to give me some great feedback. Now, yes, I have to admit, Bill, the first time you gave me feedback, I was scared of you. I was scared because I think that fear came from not you particularly, but because I was getting feedback from a product manager, who was sort of, you know, had that direct access to a customer. So I was scared, I thought, I'm getting the direct feedback from a customer, so to speak. And I was scared, but when I got your feedback, and as I started applying those, the feedback that you were giving me, it made such a big difference. And I hope that you considered me to be that I did justice to the documentation to and to our customers.

Bill Glynn: 39:08

I remembered that I liked the documentation when it went out. So I mean, I don't recall the details. But I recall reading it and writing a lot and giving you some feedback and comments. And I recall that when we had the when the docs were done, that I liked it. So it's, I would say it worked.

Zohra Mubeena-Mutabanna: 39:29

I think it's sort of set the expectation for me in what I expect from my product managers since then. And I've been lucky in my current job where I have that, that partnership and that engagement with several different types of stakeholders. And one of them is the product managers and they are my key subject matter experts, actually at this point in the current company. And I have benefited so much and I totally rely on them. And like you said asking those questions, and being engaged are very important and I think that is the biggest thing takeaway, that was actually going to be my next question to you. And you, sort of, with your wisdom just went ahead and gave me the answer. Do you have something to add, though?

Bill Glynn: 40:09

I saw Oh, no, I had a different thought. But I'm gonna wait for your next question.

Zohra Mubeena-Mutabanna: 40:13

Oh, okay. My, I think we could continue talking. But in the interest of time, I'm going to start off, I want to, I want to summarize this for our audience. That's, that's something that I'm trying out with this new season. So my question really is, what are your takeaways or highlights from this conversation? That would be that would benefit the writers?

Bill Glynn: 40:35

I think, I think my takeaway is that writing needs to make sure that the technical writers are immersed in the process. And that's not limited to technical writing. So in other words, we talked a few times about the cross functional team. And this meetings can be challenging in the sense that there are all different types of stakeholders at the table, and what are we you know, everybody to a degree is speaking a different language, it has a different interest? And how long can I have all these people at the table engaged when they all are worried about separate things, right. So there's a lot of side meetings that have to go on as well from between product management and other disciplines. But that that central cross functional meeting is to make sure that everyone's aware of the pivot points, the big ticket items that are happening, you know, what's coming up, what's changing, et cetera. But I look at it and make. So my general statement, which applies to technical writers, as well as it applies to the marketing folks, as well as it applies to sales, everyone, all the other disciplines other than development and QA. And that's because product has a sort of a special relationship with them. But all the other disciplines, I think, would, this advice or this thought would apply equally well, which is to stay immersed and be engaged in the process, because there are so many nuances that usually take place. And you you can't just take a snapshot and go away and expect good things to happen on the back end, you can't do it as an afterthought. You can't do it at the culmination of a process. It's an engagement throughout the process. And I guess that's my biggest takeaway

Zohra Mubeena-Mutabanna: 42:32

that was so beautifully articulated, you literally stole the words from my mouth, each one of them, you can't work with a snapshot, and just walk away. That continuous engagement is what you need, because you want to see a running picture.

Bill Glynn: 42:46

Exactly. And I mentioned, you know, and this is where I, you know, I probably said this, a lot heard me say it when we worked together, which was, I feel like we're trying to lay down the tracks as the train is running up our back, you know, that literally, we're trying to figure this stuff out, and the engines just barreling down the road at us. And that was kind of my first foray into Agile Scrum. I'll circle back to that, because I don't want to leave folks with the impression that I kind of had a, that was a shock to the system, that transition. But I'll come back to that way back when I was a guest speaker at Boston College, which is where I got my MBA, and the professor brought me back a few times to talk to his classes about product management and things like that. And I remember one person asked, when we were talking about all the stuff that product management is responsible for, and it's like, so how do you know if you're doing a good job? And that's a tough question to ask or answer. And I said, basically, you'll know because everyone will be upset with you. It's because you have to be able to tell sales, no, you have to be able to tell engineering, I need that buy more a certain time or no, you can't go do all those bells and whistles. We only have to do this. You have to give feedback to folks that I'm writing it down. We're not necessarily having a conversation. So how was that going to come across and you shared your story. And thankfully, you took that in stride that it was professional to professional feedback and not personal not a critique nothing.

Zohra Mubeena-Mutabanna: 44:37

It was very objective and very helpful actually.

Bill Glynn: 44:40

But that was you know, my answer to that person was a little bit caustic. But basically, you don't have authority over any of these disciplines and you're responsible for everything that goes into it, which effectively means that you are having to push, negotiate, coerce. Could you hold people into doing things or not doing things as part of the whole orchestration of the product development process? And that applies in many different ways.

Zohra Mubeena-Mutabanna: 45:12

Yeah, and I can, I mean, I have never been in your shoes, and I can imagine how tough it can be probably. And hopefully, like you said, the negotiation is what writers should also be trying to engage with. It's a negotiation, no matter which way you look at it, and trying to help each other out. And to see how do we best fulfill our customer needs?

Bill Glynn: 45:35

Exactly, ultimately, because that, you know, the success of the product, the success of the business success of the company, is all tied to what you just said, which is how well are you servicing the customer needs?

Zohra Mubeena-Mutabanna: 45:50

Customer needs? Exactly. Bill, this has been such a fantastic conversation. And I think I should mention, again, that Bill is from Massachusetts, living in Florida, because he wants me to mention that specifically for him

Bill Glynn: 46:04

Against my will. Can I mention one other thing? So lest anyone walks away that you or I have a deep

Zohra Mubeena-Mutabanna: 46:09

Yes, absolutely. love or hatred for one development methodology over another. I have also done contract type work on Agile Scrum, and not just teaching it, but putting processes in place and tuning processes and working with teams to modify those processes to suit them. And I have a friend that we've worked together on that. And I was sharing some information late last week about it, because I had found out a company that was still using waterfall that was I won't mention the company name, but it was it kind of came as a surprise. But it's not 100% either. But the point was, it was something that just I never would have thought that waterfall would be in place in that type of a company still. And so we were talking about that. And we've gone back and forth. And I said, do you know what the best development methodology is? And he's like, okay, here we go. Because we have debates all the time. I said, No, it's not what you think it's the one that fits the team. Because if the team can work well, and waterfall and that works well, you can still iterate with a waterfall development methodology. It's a little, it takes some work. But don't try and force someone who is left handed to be right handed or vice versa, fit the methodology to the team, don't try and force the team into a methodology that doesn't fit Well taken. And I think that's a good suggestion. To create a process that works in the favor of the team and hopefully engages all stakeholders, I think that would be the only thing that I would add no matter which methodology you go with, but to be cognizant of the stakeholders and to engage them throughout the process. That would be like only ask.

Bill Glynn: 48:31

Absolutely, yes, absolutely. And, and study after study has shown that in various disciplines, not just in the business world, but and having everybody on the same page.

Zohra Mubeena-Mutabanna: 48:44

Thank you so much. And for again, you know, going back and clarifying that we are not in favor of one methodology or the other. It was fantastic talking to you.

Bill Glynn: 48:52

Thank you, Zohra. It was great to talk to you again after so many years.

Zohra Mubeena-Mutabanna: 48:57

I know it's been great. subscribe to the podcast on your favorite app, such as Apple, Google, or Spotify. For the latest on my show, follow me on LinkedIn, Instagram, or visit us at www.insidetechcomm.show. Catch you on another episode.