Collaborating with business analysts in product – Dr J Harrison on The Product Experience

Hey Lily, I had an interesting chat today. One of my clients was telling me that they just arranged training for their entire product organisation of about 50 people, and they were going to get them taught about how the company actually makes money. Have you ever come across this before, product teams that are maybe great on product theory but kind of short on understanding their actual company?

Wow. No, I haven’t. That seems kind of shocking to me. But then I do work in smaller businesses where understanding the business model is sort of fundamental, although sometimes I have struggled to get close to the details. Some founders and CEOs can be a little bit protective of it.

It’s just amazing to me that basic business analyst skills sometimes get missed as people try to become great product managers without mastering all of the basic skills.

Well Randy, you are in luck. We just happened to have a guest today who can tell us all about BAs, why they’re so important and how best to work with them. That’s Dr. J Harrison, a master BA and harbinger for change at ThoughtWorks.

And Lily, I bet you thought that our opening today would’ve been about the fact that BA is short for bad attitude, and that was Mr. T’s character on the A Team. Or, even that another Dr. Jay was Julius Irving and one of the greatest basketball players of all time. Obviously, I’m starting to actually mature.

I literally love the A Team, and I never knew that B.A. Baracus was bad attitude Baracus. You’ve taught me something. But, let’s stop waffling and get chatting to Dr. J before you make a joke we all regret. The product experience is brought to you by Mind the Product. Every week on the podcast, we talk to the best product people from around the globe. Visit mindtheproduct.com to catch up on past episodes and discover more.

Browse for free or become a Mind the Product member to unlock premium content, discounts to our conferences around the world and training opportunities. Mind the Product also offers free product tank meetups in more than 200 cities. There’s probably one near you. Dr. J, thank you so much for coming and joining us on the podcast today. It’s great to have you.

It’s lovely to be here. Thank you for having me.

For anybody in our audience who doesn’t know you, doesn’t know your name already, can you just give us a quick intro? What are you up to these days? And how did you get into… I know you’re not exactly a product person. I think for all intents and purposes, or at least for our purposes, you’re product adjacent your product D, but how did you get into this world in the first place and what are you up to these days?

Right. Super fast. I’m Dr. J or Dr. J Harrison. Use they as a pronoun. I’m a service designer, business analyst type. I got into this wonderful world of analysis process, product service type world, mostly analysis from my PhD where I was working on the… Well, it used to be really a niche area, but now in the last couple of years people have been asked me a lot. I worked on molecular immunology and how the immune system interacts with other parts of the body.

From that, I ended up running an environmental virology lab before I was 30. And then when I jumped out of that, I went into internet help desks, and from internet help desks, I went into becoming a business analyst for internet help desks. And since then I have just spent my life either building call centres or putting in processes for call centres, moved to the UK and have since spent my life making help desks, and then getting really into the different processes that people use and how to make… I described somebody, “I make your stuff just a little bit less shit.” Was one of the selling points that I was using at a job fair. But it’s very much thinking about the processes and people and technology, and how those three things fit together. And yes, I do swear slightly more than one should.

That’s all right.

I’m sure you’re going just have to deal with that. I’m not very PG 13. I don’t think I ever really have been.

That’s all right. Okay. There’s one thing I want to get straight right from the start. And it’s, I want talk about BAs and product managers, because it’s kind of a contentious subject sometimes. And I’ve been in tonnes of large companies where they go through a process and they say, “All right, we’re going to be a product company now, we’re going to be product led, or do a product transformation.”

And they take everyone who used to be a BA and they give them a new title, and they say, “Right, you’re a product manager or a product owner now.” And then sometimes we also say that product managers should have BA skills and it’s one of the things they should do. So let’s just get this straight. Please help me on this. What is actually the role of a BA?

So straight is probably not the best thing that I’m good at. For me, it breaks down slightly differently, possibly on your focus. I consider myself a pure BA. I’ve put the service designer on because that explains a lot of the process work that I do and the way that I think about how the longer value chain fits together. It’s not just the piece in the middle, it’s how you get there, how you get away from it, how this fits into the entire lifecycle journey of what you’re doing and things like that.

I have found over the years as a pure BA, I’ve constantly been told that I need to become something else to improve my career. And I’ve rejected that, because I’m always told to be something else. And I think that’s a queerness thing, and a trans and non-binary thing, you’re always told to be something else.

So even in my job, I was always told, “You can’t just be a BA, you’ve got to be something else.” And we used to be a project manager, and then it became a product manager or a product owner. And to me the viewpoints are slightly different. So my viewpoint is about the value, the value. And like I said, that people, process technology pieces my sweet spot, but it’s also how money flows across that, how value was driven across that in the short and the long term.

What is the entire company’s value stream? How does that all fit together? What’s the value stream of the development department that I’m working in, or the technology development department that I’m working in? How does that deliver value across to the end users, across to the people who are supporting it, across to the company who’s wanting to create it? And keeping in mind all of those different pieces and being aware of that huge picture.

Now some might say, well that’s kind of larger project programme management, but it’s just being aware of all of those pieces with every single decision that you are getting people to make. And every single question that you are asking, you’re always driving into, why would somebody use this? If somebody says, “I need to see a value on the screen?” It’s like, “Well, what are you going to do if you see that? What decision will it drive? Will it make you change the way that you invest? Will it make you change the way that you staff people? Will it make it change the way that you make a decision somewhere?” It should always be driven by what people see. And to me, that’s kind of the analysis style questions that a lot… And it’s one of those things, yes, our jobs massively overlap, but also they don’t.

And I find it really difficult when people say, “We’ve become a product organisation.” They take all of the BAs and just tell them they’re now product owners and don’t train them on what the difference is. They don’t give them the skills to make that change, or they send them on a couple of hours of courses and give them some computer directed stuff to do. And everyone then struggles to understand where they fit in the new organisation. And that’s where I often come in. Working with ThoughtWorks as a consultancy, you’re often coming in when things have not gone completely to plan. We’re the we kind of people who get bought in. It’s like, “We tried to do this transformation, it didn’t go to plan, come in and try to tell us what went wrong.” And you’re like, “Well, your product owners don’t know what a product owner is. And everyone’s reinvented it differently. Every product manager is much the same because you took your programme managers and told them, now they’re product managers. You’ve tried to do this product focus, but you haven’t changed how your funding happens. So your funding still happens on programmes, but you’re now trying to work on products.”

And that’s one of the big things that happens. And this is where I think that business analysis skill is analysis. It’s that pulling everything apart and going, “But why? But why? But why?” On every single piece of the cog work, that I don’t think a lot of product people do because they’re wanting to do the product thing, not this wide analysis thing. But that’s just my… This is a very queer thing of, this is just my view of the world. This is not the only view of the world. There are many other views of the world, and it’s all subjective.

And I think you’re totally right in that there’s a lot of overlap in all of these roles. And I guess different businesses can have slight variations on that as well, which makes it even more confusing. But, if we were going to boil it down to try and make it a bit more simple for those to understand, like with project management, I always said that’s delivering the thing, and product management is helping understand what the thing should be. So is business analysis kind of defining the thing?

It’s the value of the thing. It’s looking at the thing and going, what value does it provide? So, for me, it’s always got to be about what value. If you want to make the thing and if the project manager wants to make the thing or the delivery manager wants to make the thing happen, and the product manager has an idea of what the thing is, it’s like, but what is the value of the thing? What is the value of this piece of the thing?

If there’s three or four different ways of doing it, are the team looking at it from a value structure? Are they going and looking at what’s the best long term? What’s extensible? What’s going to open other options? Or, are they closing doors, technically that also lead to closing doors in terms of products? So it’s about really understanding where all the value is driven and driving down into that.

But I’m always about the value, which makes me sound very kind of capitalist, which I’m very not, because value can be many, many things. And it’s knowing the ecosystem that it’s going into, and understanding where those value drivers are, I think is the business analysis thing. And it’s also about getting the right thing done at the right time in the right way. So I think also, there’s a role of the business analyst on the team about helping the team set their norms and set their behaviours and set their understanding of what we understand to do, how we talk about what we do, and how we balance out things like our cross-functional requirements, tech responsibility, environmental concerns.

Are we making something that’s eventually going to become evil way too easy to do? How do you ensure that you’ve always got the best ideas in mind, so that you don’t create taps that don’t recognise non-white skin, for example. We’ve all seen those examples of incredibly racist and incredibly sexist technologies. And to me it’s down to, it’s not just the business analyst, but it’s down to everyone on the team to be driven to think about those things, to bring in all those points of views and go, “Okay, so what is the thing that we’re trying to make?”

If this is what the product person wants, does that make sense to everybody? Can we go back and challenge it? “Hey, product boy or product person, why do you want this? Is this actually going to drive value for the end users? Is this going to fit into the ecosystem, or is this just the latest bit of wank that somebody’s come up with as a technology?” I’m so sorry. You really-

No, it’s all right.

I was trying to think of another way of saying it. And I’m like, I’m sorry. You are probably going to have to censor this a lot.

Well, I’m going to ask you a question just to be explicit, but in a different… You said the word explicit in this case.

Yeah.

I’ve been in places again where the BAs are seen as… Kind of similar to expanding on what you were saying a moment ago, making sure there’s no unintended consequences of anything. Which also kind of means writing all the acceptance criteria, writing all the things that make sense, which kind of puts them in the place of some companies as I’ve seen it, as kind of the junior product manager, as in you are the person who writes the Jira cards and does all the details and all that. Does that make sense? Is that what the job is, or is that the total misunderstanding?

Oh, no. But it’s the BA’s role to ensure that that happens. So I always kind of play the Yoda. A BA never prioritises, a BA never writes an acceptance criteria, a BA never decides that the testing strategy. They just ensure that everything is prioritised, that there is acceptance criteria that meet the testing strategy. You just ensure that it’s all there.

And yes, there is that view of being a wall monkey, and I think it’s almost like the BAs have had the worst of the marketing around their role for so long. And that yes, sometimes I have to write stories, and I enjoy writing stories I enjoy, but I also slice them so fine that they are there as a placeholder for a conversation. And it shouldn’t be a huge ginormous five page list of acceptance criteria. If it’s more than three acceptance criteria, I often say to other BAs that I’m working with, “Could we slice this story another way? Why is it so hard to test this story?”

Because as you develop the story, as you slice it out, you should be talking with the development team to say, “So, how would we put this in? And then how would we test that we got it in?” And that is helping you understand how you would look for it, how you would test it, which helps you write your acceptance criteria, but also helps you see that you’ve got it small enough. Because I’m all about writing, I call them atomic stories, tiny, tiny, tiny stories that just, everything provides some value and is discreet and all the things, all the investment principles and all of that. But they stack up very nicely into building the feature. And it’s about ensuring those conversations happen, not about doing the work, if that makes sense?

So it’s almost like you’re not really… A BA never does, they just take notes of it actually happening. And it’s running those conversations. It’s also finagling those conversations, because sometimes those technical conversations can get really full on as to if there’s two or three different ways of putting out a story of building a feature, and it’s ensuring that everyone on the team gets together and gets a chance to share those viewpoints. And then you then know the way forward, you don’t constantly have this trying to change the text strategy with every story. It’s recognising when you’re going to run into that and breaking it down.

So you are a wrangler, a finangler, an enabler rather than… You’re not just a story monkey. Moving the card across the board is the least of my things. I still have a drawer full of index cards and I use them occasionally, because your story should fit on an index card. If it can’t be written on an index card, it’s too big. And I also have a trick of putting all the context in the top, because if I say as a user, I’ve got to put a lot of work into describing the rest of the story. So I say, as a user wanting to register and coming to the site for the first time, I want to give you my email address so that I can be updated.

Just create such a nice tiny little story that everyone knows, okay, we need an email address field, fantastic, right off we go. And it gives you those starting points without having to go deep. And I know that I’ve gone into specifics, but it’s kind of trying to break it down. It’s really difficult, because it’s not a binary, nothing is ever a binary, even in code.

And so, how do you like to work with product managers? How do you both support each other in the roles that you’re playing with the team?

So with the current team that I’m working with, I’m working as kind of the strategy analyst, and I’m working with a BA and two product owners. So it’s kind of like setting the long term vision and looking at the future stuff is where I’m currently playing. The product owners, product managers are then taking that down into those smaller bets and figuring out what’s next, what’s the priority, what’s going to give value, what are the kind of hypotheses that we need to play out, what do we need to research and what don’t we need to do?

And then the business analyst is very much, “Okay, so we’ve got this research, we’ve got this UI description and we’ve got this notion of how we might do it. So let’s get the team together and figure out do we have enough to start breaking this down? Let’s break it down into some reasonable stories. Let’s break it down into things that we can start going off and doing Cody, Cody stuff with. And then once we’ve got Cody, Cody stuff, can we test that we’ve done it?”

Because we’re running with no quality analyst, which various people find very weird on the team, but it’s about having the entire team think about how to test it, the different ways that we might test it all the time. Right from the very start. Even if I’m looking at a big strategy thing, how do I know that I’m going in the right area? How am I going to test the strategy? How are we going to test our hypotheses? How are we going to test that it’s this part of the feature, not that part of the feature that should be prioritised. And then when you get it down into the user research, how do you test it with users?

Do you do card sorting? Do you do one to one-to-ones? And then it becomes how do you test it Cody, Cody type? So your tech team can look at how they’re going to deliver it. And how do they test the different ways of doing it? How do you cope with those arguments of… Because there’s always at least six different ways of Cody, Cody Makey stuff, and it’s about the team being able to contribute and think of the best ways of doing it.

What one person thinks is really complicated. Another person goes, “Oh, actually if you think about it this way round, this might actually be a really simple two line piece of code thing. Let’s go away in and run a spike, if that’s actually possible.” Real story from this current statement of work that I’m working on, something we thought could be done, incredibly complicated, somebody’s gone, “Actually, if we look at it this way round and do this…” Which was a completely unexpected way of thinking, “It might just be a couple of lines of code. Let’s just go off and check and test that.”

And I’m like, wow, I know that I write really bizarre statements of work, but to have a statement of work that’s literally about writing two lines of code is insane. But it’s also giving somebody the space to have that time to think about it from that weird angle and getting them to communicate that. That’s part of that BA role, but it’s also part of that whole strategy role as well, of kind of layering it down.

Is this something that you need to have a dedicated person as the BA doing, or is it a skillset within the team that other people can make up?

Ah, because this is fun, because our dedicated BA is about to be off for a month. So we are trying to cover it with both our product owner who was a BA, and myself who can play BA. So you’ve got us playing BA, we’ve got a delivery manager who can also do some BAing. So between the three of us, we are going to work with the team. It doesn’t need to be a dedicated role.

I think there’s enough work in there that it should be, if you’re on a team with more than about two pairs, if you’re on a team with less than two pairs, one of the other people on the team, or the team can cover it as part of what they do. But it’s having that mindset of break things down, look for the value, how do you describe the value? And I’ve taken some of this way of thinking to a team that was essentially three people who were working on a little skunk works corner. And they didn’t need a BA, but it was, okay, so here’s… What they wanted was some ideas on breaking down stories.

So I went in with them and took them through how I break down a story, and gave them some examples. And with them we built our login. Registering and logging in as kind of one of those things of pretty much every single project wants you to do it. So you just, if you’ve got a standard set of stories or a standard structure for stories, it can give people a kind of idea. So me and another BA spent some time just very quickly building out what they would need as a registered login set. So they had it to play with, we could take it away and use it on other projects. And it also gave them a structure, so they could see an example of how to break it down and they then use that for the rest of their projects.

But it’s enabling people. It’s giving people the skills and not just saying, “Go on, be a BA, write a story. It looks really easy.” It’s not. And it’s like saying, “Well, product’s really easy. You just prioritise what you’re going to do.” How do you know what you’re going to do? How do you know what to look at? How do you know what your users are going to like? How do you know what users are crying out for? Or saying, “Hey, I totally need this.” And you’re like, “Do you really? Do you need a faster horse or would you like a car? Or would you just like a bigger horse?” And it’s trying to understand.

And I think those nuances are all about those different roles. Sorry, I know that I can be quite elliptical when I talk, so I’m looking at you both going, have I circled around the point enough that I’ve landed on it? Or, you are like, whoa, where have we gone? Why are we talking crocodiles?

Actually, so at the beginning of that answer, you said something about being on a team with more than two peers. I just want to make sure that everyone understands what you mean by that because-

Oh, two product owners. So it was two product owners. So we’ve got a lead product owner, but that’s their first time of being a product owner. So we’re kind of pairing on the role to give them a lot of coaching on being a product owner, helping them build an outcome based strategy using a lean value tree and looking at outcomes and hypotheses, and using some of the work… What is it called? The Lean Experimentation book, I think it’s called. I’ll send you the link. Because it’s a short little 120 page read that really clearly explains how to build these lean hypotheses with some ideas on it. And it’s just a really good way of getting somebody to think about, okay, so if we need to understand the desire for this, how do we quickly test it? What’s a quick and dirty hypothesis?

Do we just go and talk to five people? And if we choose the right five people, can we get enough information to know whether or not to do this? Or, where it sits in our priority, is it now, a next or is it a sometime later type thing? This is a great idea, but there really is no need for it right now. We’ll just keep it in the later bin until it bubbles through, until we get proof that it’s actually wanted. So there’s a lot of that.

So yeah, it’s two product owners working in pairing to ensure that there’s a lot of coaching there, just to help somebody get up through the skills and all of the fine pieces of learning how to do the role and the thinking behind it. Especially when you’ve got lots of computer-based training, and go do this course and then you’re expected to suddenly apply it.

And the real world is never like the training scenarios. You’ve got, the system that I’m currently working on is a dataset. It was born in the two thousands. I can now literally take it for a drink down the pub, but it runs the public transport technology for the entirety of the UK. But, it is used on a day-to-day basis by about 200 people. So it’s a really tricky ecosystem to play with. It’s a really tricky system to play with, and you’ve got to be thinking about things in some quite different ways.

So having that pairing is helping somebody take it from theoretical knowledge into something that’s a little bit more based on the reality. And it’s kind of unusual to have two product owners. We will hopefully end up with one in a couple of months time, but it’s giving somebody those skills and that enablement to look at how they do this. And I mean both of them are just getting on like a house on fire, and it’s actually really good to have two minds looking at every prioritisation decision and challenging each other as to whether they’re making the right decision. Because that’s also really interesting.

And just thinking about that sort of role of the BA again, are there particular products that require a BA more so than others? Do they tend to be more complex technologies, or is it more of a case of, it just depends on the shape of your team and the BA skills of the product manager that you’ve got and that kind of thing?

I think it depends, and I think it’s a lot more on the team. I know that a lot of teams talk about not needing a BA on a technical on something. Somebody is called a technical product, or somebody is called, “Oh, this is just a technology change.” But that technology change will always change the processes, will always change the product. Because it’ll change the product and what it can do in the future. It will change the product in terms of its stability or something like that.

So every technology change will have a value somewhere. And to me it’s important to have BAs, even in those situations because they enable people to have those wider discussions of, if there’s three choices of tech, which one do we go for? I mean, literally you can sit there and go AWS, Google Cloud or the Microsoft one, Azure, and just having that discussion, you can break it down.

Dr. J, A lot of us have never had a BA on our team, and it sounds like it would be a great thing, if we had the luxury, if we were able to make the case for it. But if I’m hiring someone for the first time, how do I know what to look for? How do I know what a good person is to bring onto my team?

Well, they’ve got to fit with your team, obviously, but you also want to bring in that diversity, that diversity of thought, that diversity of experience. I look for mindset. I look for somebody who’s got the right way of thinking, rather than has done it before. Because you can have done it for 10 years and have done it wrong for 10 years, if that makes sense? And not be curious. It’s about being curious. It’s about thinking structurally around processes, and thinking, how does this fit in with everything else that’s going on? And how does this fit in across the entire life cycle of the system? Where does the money flow? All of those things that I answered previously about a BA.

I think it’s also about making sure whoever you hire, especially when you’re hiring somebody who’s diverse, somebody who’s different, somebody who’s maybe not been a BA before, how you bring them into the team and how you ensure that they’re included. How you make your team better by building your team together, rather than having an outsider and then dropping them in and going, everybody get together without kind of promoting that inclusion or that inclusivity. Which is kind of like inclusive teams deliver, which we’ll talk about next time, perhaps, if you have me back.

Absolutely. I was just going to say, we would love to have you back to talk more in depth about that topic. I think we probably have time for just one more question before we have to wrap it up on this topic about BAs. If you were going to offer some advice to someone who was considering the BA role, and who thought that that was the path for them, what advice would you give them?

Oh! So, you don’t have to be anything other than a BA to be a BA. Being a BA is about thinking curiously, thinking sometimes holistically. And it’s hard to say you’re thinking holistically when you are building a login page, for example. But it’s like asking the questions, why do I want to collect this person’s data? Am I going to secure this person’s data correctly? So do I have the process in place to remove this person’s data, i?

Just thinking about those small things. When somebody says, “I suddenly want people to log in to view something.” It’s like, “But why?” And just asking, “But why?” Being confident in doing that. It is a role in and of itself. I know that the market has a tendency to throw people who are BAs and say, “Oh, you’re just a board monkey.” Or, “You’re just this, and you need to become a product owner or product manager to have a career.”

I am proof positive that you do not, despite me throwing the service designer at the front. That is simply me trying to explain to people all the work that I do around the process side, all the work that I do around that thinking that I do around the entirety of the service, the start to finish of how somebody will use this thing. That’s kind of part of where my thinking goes. And that was the shorthand to say to somebody, “Look, I’m going to think about how this company makes money, and also how this company will die or be sold or become a trillion dollar company.” All of those things are an end point. So how will this product end? Will it fire into the sun? Will it end only when dinosaurs return? All of those things are those questions that you kind of need to take into consideration.

If you’ve got the kind of brain that does that, yeah, you can be a BA forever. And you don’t have to change who you are. You don’t have to suddenly go, “Oh, I’ve got to call myself a product person to get ahead.” Although I did give myself a job title that was harbinger of change, and I did that because some of the places that I was going into as a consultant for ThoughtWorks, they were very against having a business analyst. And they were like, “We don’t want no business analyst. We want a product owner. And I’d be just like, “But everything about the role is business analysis. You’ve just put product person on the top.” And that is also one of the things that I think we are struggling against, of people will literally write a business analyst role and then go, “Oh no, I can’t hire any BAs, okay, we’ll call it product owner.”

And it’s just like that isn’t a proper product owner role, that isn’t giving somebody the agency and autonomy to make those feature decisions and to go out and understand the market and all of that. You are literally just asking somebody to do that very core piece of analysis, which is generally, you’ve described a BA role and just put product on top as a find, replace product owner, as a find replace product owner, as a find replace product owner/analyst. And it is that.

So be aware that those jobs are out there. And I mean, as somebody who screams about not being a product person, I know that I do a lot of stuff that is kind of a bit producty, but it comes in with a different lens. And it’s having that slightly different lens, that slightly different way of thinking about it is the juicy stuff that you will bring to the role. Nom, nom.

Oh, well, thank you so much for joining us on the podcast. It’s been great to hear all about business analysis, and clearly you are very passionate about it. So yeah, it’s been fantastic. Thank you.

Ah, no worries. Thank you for having me. I’ve really, really enjoyed this, and I look forward to coming along and ranting at you again.

Yes, absolutely. The product experience is the first-

And the best-

Podcast from Mind the Product. Our hosts are me, Lily Smith-

And me, Randy Silver

Louron Pratt is our producer, and Luke Smith is our editor.

Our theme music is from Hamburg based band Pau. That’s P-A-U. Thanks to Arne Kiler who curates both Product Tank and MTP Engage in Hamburg, and who also plays bass in the band for letting us use their music. You can connect with your local product community via Product Tank, regular free meetups in over 200 cities worldwide.

If there’s not one near you, maybe you should think about starting one. To find out more, go to mindtheproduct.com/producttank.