Let’s Ditch “The Business”

There are certain phrases product teams use that reinforce bad habits. "The business" is one of those phrases. Here’s why you should get rid of "the business" and what to use instead.

If you work in the IT part of your organization and want to improve your relationship with stakeholders, there’s a phrase you should eliminate from your vocabulary.

No, it’s not referring to people as resources, although you shouldn’t do that either, unless you want them to act like unthinking automotons.

I’m talking about the business.

The Business - an example

Not sure what I’m talking about? Here’s a passage from an article intended to explain how to improve the relationship between people who build software and the people who use that software. The title gets things off to a fine start: The Business vs IT: Can’t we all just get along?

It is no surprise that IT is not always aligned with business goals. The conflicts arise because IT is often unaware of how the business uses the systems that IT is responsible for installing and supporting, and the business is often unaware of exactly what is involved in an IT project. There are several other reasons for the disconnect between IT and the business.

If you want to get the full effect of the over use of that phrase, try the business drinking game. Grab your favorite beverage of choice and then read the article, taking a drink every time the business shows up.

Why you should avoid The Business

Still with me?

Am I making this suggestion out of some form of pedantic political correctness? I may own up to pedantry, but not political correctness.

I’m suggesting you avoid using the phrase the business because it reinforces the idea of a huge gap between people who build internal products inside organizations and the people who use them.

It harkens back (or reinforces) the idea that IT is there to fulfill the orders of other parts of the organization. It’s back to IT as a cost center rather than a profit center and a strategic asset.

It also over generalizes the people who use what you build in much the same way using terms like “users” or “customers” over generalizes the people of you build products for. Rich Mironov stated the point well:

Creating real-world value is a multi-step process involving many players. And it’s exhausting prefacing every conversation by (re)defining terms: “for this user story, the customer is the sys admin who configures our CAD software, not the architect sketching out buildings. See personas 4 and 7.” Wasted energy. So let’s abandon the words ‘customer’ and ‘user’ entirely, and be more explicit about who/what we mean.

In an internal product setting, the people that the business refers to can be the ones who decide what you’re going to build.

Especially, in organizations without an explicit product management function for software the organization builds for itself, people in the business fill that gap, even though they don’t have the skill set to do that properly.

I mentioned this scenario in The roles product people play and gave the general term “Sponsor” (adopting from the project paradigm, sorry) to the person playing that role. These are often leaders of specific business units who make decisions, but don’t have experience with leading software product development, so they tend to follow all the behaviors that product management thought leaders say you shouldn’t do.

What should replace The Business?

So what do you say instead? As Rich suggested, choose specificity over some vague and nefarious sounding “them.”

If you’re talking about the people who use your product, you should know enough about them to refer to the role they fulfill when they use your product.

When I worked on a pricing system for a seed business (literal seed, as in stuff you plant in the ground) we had pricing analysts and growers.

When I worked on Agile Alliance’s submission system, we had speakers, reviewers, track chairs, and program chairs.

For the product I’m working on now we have vehicle owners and sales staff.

And if you’re not the one deciding what to build (hopefully that will change at some point), it’s not the business making those decisions, it’s the Sponsor. But you’d be better off referring to them with more specific terms such as Director of Finance, or even Tim.

Being specific about who makes the decisions clears a lot of things up and may even help the team more productive in the long run. After all, if you know who is explicitly making decisions, you’ll know who to try and influence when you need to make changes.

Thanks for reading

Thanks again for reading InsideProduct.

If you have any comments or questions about the newsletter, or there’s anything you’d like me to cover, let me know.

Talk to you next time,

Kent