In this week’s In-Ear Insights, Katie and Chris talking business requirements gathering. Often seen as administrative overhead, business requirements gathering can dramatically increase revenue if you do it right. Learn what business requirements gathering really is, why it’s often done incorrectly (or not at all!) and how you can implement the process better to make your organization more efficient, cut costs, and boost profits. Tune in now!
Subscribe To This Show!
If you're not already subscribed to In-Ear Insights, get set up now!
- In-Ear Insights on Apple Podcasts
- In-Ear Insights on Google Podcasts
- In-Ear Insights on all other podcasting software
Advertisement: Google Search Console for Marketers
Of the many tools in the Google Marketing Platform, none is more overlooked than Google Search Console. Marketers assume it’s just for SEO, but the information contained within benefits search, social media, public relations, advertising, and so much more. In our new Google Search Console for Marketers course, you’ll learn what Google Search Console is, why it matters to all marketers, and then dig deep into each of the features of the platform.
When you’re done, you’ll have working knowledge of the entire platform and what it can do – and you’ll be ready to start making the most of this valuable marketing tool.
Sponsor This Show!Are you struggling to reach the right audiences? Trust Insights offers sponsorships in our newsletters, podcasts, and media properties to help your brand be seen and heard by the right people. Our media properties reach almost 100,000 people every week, from the In Ear Insights podcast to the Almost Timely and In the Headlights newsletters. Reach out to us today to learn more.
Watch the video here:
Can’t see anything? Watch it on YouTube here.
Listen to the audio here:
- Need help with your company’s data and analytics? Let us know!
- Join our free Slack group for marketers interested in analytics!
What follows is an AI-generated transcript. The transcript may contain errors and is not a substitute for listening to the episode.
Christopher Penn 0:00
In this week’s In-Ear Insights, let’s talk about business requirements.
An awful lot of the time, people think of business requirements as sort of a unpleasant administrative must a cost center a waste of time, even when a lot of stakeholders and a lot of people who are talented practitioners, like no, let’s just do the thing.
And yet, Katie, there may be a case for saying that business requirements can make you money.
So tell us how do business requirements have make us some money?
Katie Robbert 0:35
Well, I want to walk backward a little bit.
So they can be a waste of time if they’re unfocused.
And so, you know, there’s, there’s a right way and a wrong way to do business requirements.
And so the wrong way is to just start asking everybody their opinion on, you know, the thing that you’re trying to build, it could be useful to gather that information.
But if you don’t plan on taking action with it, or incorporating it, you’re wasting your time, you’re wasting their time.
And quite honestly, they’re going to be pretty angry that you wasted their time and didn’t, you know, take their opinions into consideration the right way.
And the way that can save you money and make you money is to you know, start with something a little bit more focused, like a user story, as a persona, I want to so that.
Starting with that gives you some focus, because it tells you the question that you’re trying to answer.
And so, you know, Chris, you’ve recently been working with a fan base, to save a Netflix show where you’re not.
And so you’re the question that you’re trying to answer is how do you get the attention of a streaming service like Netflix or other streaming services, and demonstrate the value of keeping certain programming? That’s, that’s the question you’re trying to answer.
So everything you do, in addition to answering that question should sort of roll back up into that.
So any data that you’re pulling any people that you’re talking to any analysis that you’re showing any sort of anything relates to that, where you’re posting it, how you’re posting it, when you’re posting, it needs to feed back up into that question of, as a fan of this TV show, I want to get the attention of Netflix so that they will uncancelled it.
Everything has to be backed up into that.
Christopher Penn 2:29
It’s funny, because I think I was channeling you in one of the the fan groups team meetings, because I actually made them do this exercise.
But I said you need to put yourself in the shoes of a studio executive was there you just right? We know what our user story is getting.
And we know that yeah, we want more of this content.
What’s their story, and so it took a little bit of doing.
But eventually we got folks to realize, as a studio executive, at a streaming service, I want to retain more subscribers, so that my cost of acquisition goes down, where as a studio executive, I want to acquire new subscribers so that I can make my numbers for the quarter, right.
And once we refocus that lens, you know, we’re putting together a pitch deck, essentially, of all the data that we’ve collected, like search data, and social media data and streaming, services, data, reviews, data, all this gets pulled together.
But basically, it’s trying to make a case, if you buy this thing, you will get this outcome, you will, it follows the user story.
If you buy this franchise, you will get this amount of loyal members and their multiplier effect in, in marketing such that if you spend $1 on market with an avid fan base, you can have them multiply the impact of that dollar by $100.
Because they’ll share pretty much anything you tell them to share.
And so once you have that user story, it is it’s a focusing point where people can look at that and go, Oh, so this thing I’m doing over here, yeah, that doesn’t really matter for this cool how to do it.
And obviously, in an all volunteer group, you can’t tell people what to do, you’re not paying them.
But we’re to help people to stay on on task.
It’s like, here’s the bubble light, we’re, we’re the prison we’re looking through.
It’s either gonna bring in new subscribers or retain existing subscribers, that’s what it execs gonna care about.
Katie Robbert 4:24
And so, you know, it’s interesting.
So if we go into that, you know, question of how does, how do business requirements boost revenue? Well, I can see as I see the two scenarios playing out where there’s no business requirements, and the exec says, I need to make my numbers I need to get new subscribers.
I know let me go ahead and start creating net new content and see if I can attract subscribers.
That’s going to cost a lot of money that’s going to cost a lot of overhead and it might not work versus having requirements around.
Hey, you know What if I explore this fan base and see if I keep the show around with a stick around? Would they be returning users? Would they, you know, tell their friends who also want to be subscribers.
And then I could make my numbers that way.
And so you have two scenarios, one where you’re just sort of shooting from the hip, probably spending a lot of money, maybe getting it wrong, versus doing your due diligence and saying, What is my subscriber base actually care about? Let me do more of that.
And how can I really activate that subscriber base to be an advocate? For me, for my streaming service to bring in more users, that’s not going to cost me anything.
And so if we bring it into the context of a business, and so we are talking about this, but in terms of like, a business that wants to, you know, do a B testing or business that wants to run an attribution model? Answering the question about why you need to do the thing, why you want to do the thing is going to continually focus.
You know, your, what, how you approach it, and so you can have your user story, but then you need to dig a little bit deeper and sort of follow the five P’s.
So the purpose, your user story, is your purpose, what is the question you’re trying to answer? Why are you doing this thing? But then you should be able to understand who are the people who need to be involved? From an external standpoint, from an internal standpoint? What is the process that we’re going to follow? To answer this question, what platforms and data points do we need? And then what’s the performance? What’s our measure of success? And so those are the basic requirements.
And so this, this exercise is not a time waster.
This exercise actually tells you, if you have all the components, you need to answer the question, and or what you’re missing.
Because the biggest problem with a lack of requirements is, most of the time, there’s things missing, that you aren’t even aware of.
And so you start, you know, start to just do the thing, because it’s more interesting than documenting what you want to do.
And then you’re like, Well, I’m actually missing three years worth of data.
So I can’t answer the question.
But I’ve already wasted $50,000 Trying to get this question answered.
So I guess I might as well just keep going, because I’ve already dug the hole.
Christopher Penn 7:19
And this concept of building requirements, technical requirements, business requirements, anything, it doesn’t have to be huge.
It doesn’t have to be some massive undertaking equates to 800 page binder.
I mean, sometimes it can be if it’s like a $50 billion project, yeah, you’re probably you probably want to write that out of more than just a note card.
But even in practical application on a small scale, these things are really important.
And one of the things that it’s really important for is artificial intelligence, artificial intelligence, when you’re working with large language models, needs detail.
If you go back to the livestream we did recently on how to do prompt engineering.
One of the things that prompt engineering essentially is if you do it well, is requirements gathering.
So what we’ve got here, this is an example of a piece of code that I had chat GPT-3, right recently, this isn’t the code.
This is the prompt this, these are the business requirements.
I said, here’s who you are, here’s the background information, here’s the steps.
And here’s the 1234.
Here’s what I need this piece of code do write and it’s very clear what the requirements are, what format it should be in what libraries it should be using, etc.
Even if you’re just working with AI as a single person, being able to write out your requirements is a massive time saver is a massive money saver.
And it dramatically accelerates just how good the quality is that you get out of any of these AI based tools.
Katie Robbert 8:53
So if you go into sort of you if you take a step back, so you know, whether it’s AI or, you know, if it’s, you know, a website, or if it’s a marketing campaign, doing the requirements.
First, is that opportunity to work out any of the issues, you know, sort of the, you know, play with the scenarios of like, well, let’s say this does really well, what do we do? Let’s say this doesn’t perform well.
What do we do? Can we accept the, you know, loss of dollars, so building in the time to document what you want to do, why and how he is actually what’s going to make you money, because without that, at least a thought to what it is you want to do and how you’re going to approach it.
There’s no repeatability, first of all, repeatability is what’s going to make you money, because that’s where you have opportunities for automation, for artificial intelligence.
You know, without sort of understanding what the intended outcome is meant to be, how do you know you were success? So like, I can run an A B test on anything.
But how do I know it was successful or not? I don’t know.
Because it it performed better perform better.
How were from better for what what was my intended goal? Why did I do it in the first place? Because I was bored, because I was curious.
That’s a waste of that’s a waste of my time.
And that’s a waste of resources.
Because then I have to go back and look and say, Well, what happened? And then I have to backtrack and say, Why did I do this in the first place? What did I learn from this.
And so when you think about business requirements, making you money, you really need to think about it in terms of it’s saving money upfront.
So I used to run a software development team, I think I’ve mentioned this, before Easter run a software development team, and they hated doing requirements, they thought it was the worst part, they just want to start developing.
It is 10 times at least 10 times more expensive to fix broken code and re engineer features that were wrong and unusable.
And don’t resonate with the market, that it is to actually sit down and write down what the heck it is you want to do.
And so I can hand these requirements, this blueprint to my you know, team of developers say, This is what I want you to do, and then they execute it and we get the intended outcome.
Or I can say, I don’t know, we’re thinking that we want a contact form.
And you know, we want it to feed into our CRM.
You know, it should be straightforward.
But there’s a lot of variables there, like, how much information do we need to collect? Are there privacy guidelines that we don’t want to violate? If we violate those? Do we get hit with a legal fee? And, you know, things that seem straightforward are often convoluted, which require having at least basic requirements.
And so if you’re listening to this podcast, instead of watching the video, as I was talking about software engineers who don’t want to do requirements, Chris was nodding along so Chris, please talk to your experience.
Christopher Penn 12:04
Oh, it wasn’t about that.
Specifically, I was looking at my my old Mr.
Boston, Deluxe official bartenders guide.
This is a whole bunch of one does, as one does.
For example, Pikes Peak cooler juice of half 11, one teaspoon of powdered sugar, one egg Shake well with cracked ice and strange a 12 ounce Tom Collins glass and fill the hard cider and stir and satisfy all of orange and dangle over Andrew glass.
If I want to what the heck does it have to do with requirements gathering?
Katie Robbert 12:31
I know exactly what it has to do with requirements gathering.
Christopher Penn 12:34
recipes of requirements gathering recipe is the process and the platform.
Part of the five P’s right the purpose is you probably want to have something to drink.
The people is who you are and who you’re making the drinks for.
Right? So if you’re making a drink for yourself, that’s kind of self explanatory.
But there are definitely when you’re when you’re making a drink for somebody, and like, this person doesn’t like whiskey will not go so well then.
And then the performance is since consuming the drink.
But if you think of if you’re thinking of requirements gathering is as big onerous thing.
So just recipes.
This is an easy way to explain it to people.
The other thing that a recipe does, and this is again, part of the making money, Katie, you said reproducibility, repeatability, right, so you can have the recipe open up and okay, I’m gonna make this thing again.
And again, it may get boring making it but I will consistently make it again and again again.
The other aspect is if it’s reproducible, to scalable, I can now hire 10 bartenders, I give them a tenant of the exact same recipe.
And nine out of 10, I’m going to make a great drink.
Now this was the point at one ad yet, like I can make this better like no follow the recipe.
That’s what we’re selling.
So the customer agrees to buy.
But that’s the other area, we can make us money.
And again, going back to the AI example, if you are creating great requirements, which is what props are, you can scale that you can have 100 API calls, 1000 API calls, all using that same set of requirements.
And you can dramatically scale the amount of stuff that you have AI making.
Katie Robbert 14:15
You said something that I want to highlight something very important, it’s what the customer agrees to buy.
And so understanding what the customer expectation is, is the key to write in your business requirements.
You start there and you work backwards.
So you know, in your example Chris, you’re making, you know, a certain kind of drink.
The customer likely is ordering it because they have an expectation of what it is what it contains what its gonna taste like.
And if you don’t give them not because you’re just kind of winging it, they’re not going to be happy.
And they’re going to make you make another one on you like you then have to pay for you’re going to lose the money.
And so it’s at the end of the day requirements are, how you meet the customer expectations, you can be the customer, you could be making the drink for you, but you specifically chose that drink because you want those things.
Or you have a ball for the people who are ordering the thing, it’s the same thing with an attribution analysis.
The customer expectation, the end user is that I will then be able to understand which things are helping convert which things are getting the credit for the action.
That’s the customer expectation.
And so if you are giving them a bow, gosh, a, you know, 101, you know, piece about SEO, but you didn’t give them an attribution analysis, you’re like, Well, I don’t know, this guy answers your question, but not really not at all, they’re gonna be very upset and Everyone’s tired is gonna be wasted.
Time is money in this rich in this context, because it’s resource time, it’s time that you could have been doing something else, it’s, you know, time that you can’t get back, focusing on the wrong thing.
Christopher Penn 16:09
Exactly, you can always get more money, you can never get more time, you can’t there’s no amount of money that will buy a second time.
So if the requirements gathering, they your business requirements, your technical requirements, if you do that, well, if you get a good recipe, you will save yourself a lot of time and that again.
And that means you can scale.
That also means you can invest more you can do more r&d, you can do more innovation, or you can just go get drunk on you know something from openness to Boston’s talks bartender’s guide.
No matter what happens, you’ve gotten that time back that you would have spent otherwise, on fumbling around.
And, to your point, Katie, it’s a partnership between you and the customer, right? The customer says I want a martini.
I mean, I can give you a vodka martini, which is not really a martini, but you know, people like to pretend to just Well, I can give you a gin Martini.
And if you just say you want a martini, I’m gonna give you a martini, right? It was gonna have chin and then all of this stuff bad.
But if that’s not what you had in mind, that’s your fault for not being specific in your requirements as the customer to say, I want a vodka martini with the raspberry, absolute and a cucumber and seven, all of that sounds
Katie Robbert 17:23
Oh, by the way.
But you know, we’re talking about requirements in terms of one single person performing the action building the thing.
Think about larger teams? How does everybody know what role they need to play without some set of requirements? So the front end designer needs to do this part, the back end designer needs to do this part, the database architect needs to do this part, what are the components of the thing? Because otherwise, you start to really get into like the six, seven figures of time wasting.
And, you know, the larger the team, the more important requirements become, because it is your sense of direction, it is the instruction manual.
For what role I play what role Chris plays where John plays, what role like, external consultants play, because otherwise, how the heck are we supposed to know? I could say, You know what, I think he’s just going to redesign the website.
Okay, Chris, you could do that, right? Yeah, sure, why not.
And then we find ourselves, you know, six months from now, having gotten nothing done, because the things that I had in mind, were not compatible with the skill sets that Chris might have in terms of his ability to redesign a website.
Now, this is just like a very basic example.
But the point being is that having some sense of requirements tells you, this is the team that I’m going to need this, these, this is part of my tech stack that I’m going to need access to, if I don’t have access to it, I better start now.
I better put in that request to it and tell them why I need it.
This is the process the repeatability of how I’m going to approach this thing.
And then this is the desired outcome.
And then this is what my end user expects the thing to be.
Did I do the thing and this is how I know it’s successful.
Christopher Penn 19:18
How suppose you have a carpenter, a plumber, an electrician, and you don’t have a blueprint, what kind of toolbar they do walk into a bar.
Katie Robbert 19:29
Okay, go sorry.
Christopher Penn 19:31
You have a carpenter plumber or an electrician.
I’m not gonna house you gotta get if you don’t have a blueprint.
Alright, assuming that even degree doesn’t work at all, because at one of the things that’s happening is we’re seeing obviously, it’s you know, talent is a major crunch right now and mid level talent, particularly managers we’re seeing, you know, leaving a field of marketing and business in droves, which is causing a lot of severe issues accompanies, which means that more and more agency partners are being brought in to help backfill jobs, positions and tasks within companies.
requirements gathering is important inside your company requirements gathering is mandatory.
If you’re working with agencies, particularly you’re working with one or more agencies, because again, like the carpenter, the plumber, and the electrician, if you don’t have a blueprint, nobody knows what they’re supposed to build, you’re gonna get people to doing all sorts of crazy things, and eventually going to be that one person who has somehow managed to get their main electrical wiring put through their bathtub, and it’s going to be a very, very short bath.
Katie Robbert 20:31
Your chair is.
What’s interesting is, as you’re giving that example, my first thought is, well, who’s telling them when to stop and how much money they’re allowed to spend? Because that’s going to be a very, because basically, you’re giving these people free rein to do whatever you like, I don’t know, just make me a house.
And they’re going to build you a house.
But you have not given them those parameters to say, and stop when you get to $30,000.
What can $30,000 get me? Not the house that I was thinking, you know, you’re definitely not going to have heated floors in your bathroom, you’re definitely not going to have central air, you’re definitely not going to have, you know, a greenhouse attached to your house like, oh, okay, well, I wanted those things.
Well, you don’t have to budget for them.
Or you know, or you say, just build me a house and you get all those things.
And then you get a million dollar bill, though, like,
Christopher Penn 21:32
resource constraints are a part of requirements gathering enough? How long do we have to do this? How much? How many people? How many man hours? What the tooling do we have? You know, one of the things for example, going back to the beginning of the show, with the the fan project that I’m working with, the budget is essentially it’s like $35,000 total, most of which that they’re using to buy a billboard in Los Angeles.
The effective operating budget is $0.
Right? So the question then becomes, what? You they have some ideas, but they don’t have budget to support those ideas in the traditional form that we would normally do them.
So how do you do that, given that budget constraint? And that’s part of requirements gathering that comes before setting pen to paper is okay, well, what can what resources do you have? There’s plenty of people that have talent, but they don’t necessarily have tools.
And there’s certainly no money for advertising or other traditional marketing techniques.
So what what can you bring to bear open source products, right? public datasets, all these things that are freely available, but you need to gather up and build yourself, it’d be very different than say, if Cisco Systems or Citrix Systems or VMware or somebody said, Hey, we got $44 million.
And you know, two months of time to build this thing, can you build it for us?
Katie Robbert 22:58
RESOURCE restrictions is a really interesting piece of this.
So if you’ve ever done software development, then you may be familiar with Sprint Planning with Agile methodology.
Sprint Planning is essentially requirements gathering for the upcoming sprint, which is roughly two weeks.
There are restrictions on time in that instance.
And so let’s say I have a long list of things on my backlog that I want to have done.
Well, I can’t get them all done, because there’s a restriction on time in terms of how many resources I have available over the next few weeks, you know, that’s essentially 80 hours, what can I do in 80 hours and get something that is, you know, that I can show as a demonstration, that’s a prototype of something or a finished product.
And that’s where requirements gathering really comes into play, because I can’t get everything I want, you know, we’re not even talking budget, yet, we’re still talking about the actual physical man hours, that somebody can, you know, create this thing.
So let’s say I have, you know, I want a house built.
And I have two weeks, and I’m giving them two weeks to do it, I’m not getting a whole house, I’m either gonna get a really shoddy house, that’s gonna fall down the storm, or I’m going to get maybe a foundation, maybe a wall at the end of two weeks, I have to start to make those choices of what is the most important thing that I want to see at the end of that time constraint, that resource constraint.
And that’s where having those requirements to set the expectation of here’s what I want to build, here’s sort of the, you know, pie in the sky idea of, you know, features and bells and whistles.
And then here’s the baseline of what I can absolutely tolerate in terms of the low level version of this thing.
And then you start to, you know, as you find, okay, so this came together faster than we thought it would we can start to add on to it, versus going into that, you know, like 1000 foot view level, you know, the greatest thing in the whole world and finding out you can’t execute it.
Christopher Penn 25:04
And tireless, immutable, you know, there’s There’s an old joke that says nine people can’t make a baby in a month, right? Because it takes a person to, to just a human child in the islands.
You know, though a more typical answer again, going back to our our friendly bartenders booked your party tomorrow night.
Yeah, for two people, you need to ice for your drinks, right? It doesn’t matter how expensive your freezer is, you are not making 40 pounds of ice between now and then in the freezer that you have, you either have to go by it, or you need to plan ahead like a week in advance in the making ice that whole time so that by the time that the party rolls run out, the morning of you physically up, there just isn’t time even if you had, you know, the best freezer in the world, just can’t make it make ice faster than ice will naturally freeze.
I mean, yes, there’s like all sorts of silly things you could do.
But in the context of most normal people in their homes, it just isn’t going to happen.
And so that time constraint is part of business requirements is one of those things where you can’t buy more time.
Katie Robbert 26:08
you can add more people, but to your example, Chris, it doesn’t necessarily change anything.
It’s funny that you bring that up, because that was always the, you know, quote, unquote, solution that my stakeholders give us.
What if we add more people this project? Can we get it done? Then? Can we get it done? I was like, nope.
Doesn’t it literally would make it take longer.
It’s definitely not a solution.
So I think the point being if you are looking to scale, if you are looking to save money, both things are important.
Then business requirements, the time it takes you right up even basic requirements of, you know, what’s the question I’m trying to answer? Who’s involved in this thing? How am I going to get it done? What tools and technology do I need? And then what is my measure of success? answer those five basic questions, and you have yourself a set of requirements, because then you at least go ha, you know, as I’m looking at this, I’ve realized that I’m probably going to need someone who understands machine learning.
Nobody on my team does that.
So I need to rethink this plan.
Or I need to invest in someone who understands machine learning, or you know, I really think I need three years worth of data.
We only have 18 months worth of data.
So what am I going to do I need to rethink this plan.
And it gives you the opportunity, if nothing else to just pause for a second and say, Is this a good idea? Is this a realistic idea? Is this an executable idea? Is this something that I can say when I’m done? Yes, I did the thing or No, I didn’t do the thing.
Christopher Penn 27:49
As the famous quote from Jurassic Park goes, scientists were so concerned about whether they could they never stopped to ask whether they should.
If you’ve got some stories you want to share about requirements gathering and things you’ve done to make business requirements more profitable.
pop on over to our free slack, go to trust insights.ai/analytics for marketers where you can over 3000 other marketers are asking and answering each other’s questions every single day.
And wherever it is you watch or listen to the show.
If there’s a channel you’d rather have it on instead, go to trust insights.ai/ti podcast we’re probably have it available for you.
Thanks for tuning in.
I will see you next time.
Need help with your marketing data and analytics?
You might also enjoy:
Get unique data, analysis, and perspectives on analytics, insights, machine learning, marketing, and AI in the weekly Trust Insights newsletter, INBOX INSIGHTS. Subscribe now for free; new issues every Wednesday!
Want to learn more about data, analytics, and insights? Subscribe to In-Ear Insights, the Trust Insights podcast, with new 10-minute or less episodes every week.