Skip to main content

Pragmatic Business Analysis: Let's Start Calling Ourselves Product Managers. Seriously.

If you are a current or recovering Business Analyst, you may remember Scott Ambler's assertion in his essay "Rethinking the Role of Business Analyst:"
A business analyst (BA) is a poor substitute for developers who have both ready access to actual stakeholders and agile modeling skills.  Remember, BA is also the abbreviation for band-aid.
Image courtesy of target.com
I have friends who switched to Curad for their fabric bandage needs, they were so annoyed by Ambler's witticism, even though Curad never had the mysterious tiny round bandages that don't do anything, but you feel incomplete without them.

In the past, business analysts were always first to go, when a company decided to institute an "agile" policy where everyone on all teams would get called a "developer," supposedly because everyone on the team could do everything needed, but generally because everyone on the team was, in fact, a developer.

Often times, the next step would be that real world businesses would discover that they couldn't afford to colocate their stakeholders in a single room with the developers, because the stakeholders had other things to do.  Meanwhile, the teams of T-shaped equals would discover that none of them had the skill set, time, and especially not the inclination:
  • to map one or more corporate "value streams" to help executives make decisions about what to build
  • to prioritize the work within the context of the company's strategic goals
  • to navigate the political stresses within the overall business environment in a way that would allow a single software stream of work to emerge, all going in one direction
  • to advocate for the team to business owners, and for the business owners with the team
  • to facilitate meetings with users to collect and test requirements against the real world
  • to characterize potential business returns on investment from specific technical efforts
and so on.  This is not an exhaustive list, which will become important in a moment.

In the old days, a person or two might eventually be added to the all-developer team to handle these types of work, often on an "experimental" basis to see if the individual "added value." Many times, it turns out, the person would add value.  Many times, that person was called a business analyst.

Most of us have come to terms with this dance.  The Pragmatic BA has the confidence to wait until a team realizes they need help to allow everyone else on the team to perform their roles optimally.
A country dance, by Hogarth, posted on https://philadancehistoryjournal.wordpress.com/category/%E2%80%A2-18th-century/

FRIENDS, SOMETHING REALLY BAD HAS HAPPENED TO THE BA BRAND.

And I don't mean Band Aid versus Curad.

It probably won't come as news to you, if you're a BA waiting to be called into action by an agile team. It turns out that the cool business-interfacing people on agile teams are not called business analysts any more.  They are called "product managers."  They are also called "experience designers," "data modelers," and a host of other names, but more often than not, the person who helps keep the team focused on doing the right thing for a business is called a "product manager."  And sadly for you, the product manager totally outranks you, if you are a mere business analyst.

Mark Silver explains in SpecTECHular:
...the two roles overlap at some points, and do require many of the same skills. However, I feel it’s still important to acknowledge the distinction along with the resemblance.
Brian de Haaff, of the Aha Blog, explains that a business analyst will be "inward facing" towards the team, whereas a product manager will be "outward facing" towards the market.  Additionally, the business analyst writes technical specifications for the developers, where the product manager owns the overall strategy and roadmap.

The pragmatic BA wants to howl at Mark and Brian that this is a distinction without a difference.  Surely you are simply describing work which is done by an entry level person as different from the work done by a more experienced one.  An entry level product manager is more likely to write specifications, where a senior business analyst is likely to set strategy.  On the ground, we do not have serious definitional differences between BAs and PMs.  The two groups do the same type of work and share the same skill sets.

But before the howling begins, allow me to observe that the distinction has currency, and a whiff of ageism.  It appears that what we have is a glamour gap.  Jeff Gothelf observes in his blog that the usage of one title versus the other has everything to do with the age of the hiring company and perhaps even the age of the desireable PM/BA hiree.
In the younger companies (say, 20 years old or younger) the role of the Business Analyst is often non-existent or, at best, a relic of the “early days.” In these...companies, product managers lead the charge with product vision, ownership, customer development, competitive analysis and product strategy. In older companies (20+ years) product management is a relatively new profession being added mainly as a response to what these companies are seeing these younger companies do as well as a recruiting tool to gain the attention of younger applicants.
Gothelf goes on to lay out a Venn diagram showing the overlap of Business Analyst with Product Manager in a manner similar to what Mark Silver describes:  BA is more inward-facing and tactical, where PM is more outward-facing and strategic.
Diagram by Mark Silver, published in https://www.jeffgothelf.com/blog/whats-the-difference-between-a-business-analyst-and-product-manager/

I embarked on the research for this blog post with a bit of a chip on my shoulder about how annoying it is that, categorically, BAs are now being considered the junior helpers to PMs, in a manner that disregards experience level.  And indeed it is annoying, but one cannot control the progress of the language.  This is why I would almost - almost - conclude that senior business analysts in agile environments should simply call themselves product managers, since there is clearly not a talent gap, and PM is a better brand.

My only hesitation?  Well, I suppose it was predictable, but maybe you shared my interest in John Cutler's recent Hackernoon article entitled "We Need Fewer Product Managers."  The article appears, despite its disclaimer, to be an attack on anyone who hires people with the Product Manager title, on the grounds that people with other titles can cover the disparate things a product manager does.  We need fewer product managers, he says:
We need MORE internal startup co-founders, UX, customer advocates, domain experts, service designers, complexity untanglers, researchers, and reliable ways to interact directly with users/customers. We need more product thinking, and less product managing. [emphasis Cutler]
Eventually, Cutler gets to the real nub of it--"mature" teams don't need a single person to keep them aligned with business sponsors of the work. "What would it take," he asks, "for a team to share ownership?  Do you really need a single wringable neck?"

Sigh.


Popular posts from this blog

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else.

Here's what you should think about:

1.Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that:
a.You need your user experience people (if applicable) and your analysts at the beginning of the project, as always, b…

Requirements Traceability in Agile Software Development

One of the grim proving grounds for the would-be agile business analyst (henceforth "WBABA")  is the "traceability conversation."  Eventually, you will have to have one.  You may have seen one already.  If you haven't, you may want to half-avert your eyes as you read further.  It gets a little brutal.  But if you close them all the way, you can't read.
Dialogue:
WBABA:   ...so in summary, we complete analysis on each story card, and then we support the developers as they build it that same iteration!Corporate Standards Guy:  but how do you do traceability in agile?  You have to have traceability.  It's broadly recognized as an important factor in building rigorous software systems. These software systems permeate our society and we must entrust them with lives of everyday people on a daily basis. [The last two sentences are an actual quotation from the Center of Excellence for Software Traceability website!] WBABA: [cowed silence]Corporate Standards …

The Agile Business Case

Many agile teams have never seen a business case, ever, and they may even be proud of it.

Our mantra is that we deliver "business value," not just "software," quicker, better, and faster, but if so, we certainly don't spend a lot of time reporting on value delivery, and in fact we may be scornful about "analysis paralysis."  As software developers, we consider ourselves to be doing quite well if we can deliver the software every two weeks (or continuously).  And this is particularly if we've enabled this frequent high-quality delivery through automated testing and automated build-and-release techniques.  We've reduced business risk by making results visible more often, and allowing the business to change direction more frequently.  We assert that along the way of course we're also delivering value.  But how would we prove it?

I've recently posited that we shouldn't even think of doing agile projects without capturing and recording s…