When I got my first Business Analyst job, a lot of what I did was meet with users and potential users to understand their needs. Whether we were building a new product from the ground up, improving on something already existing, or replacing an outdated product, my job was to document requirements.
And while other BAs would ask users “what do you want” and then write that down as requirements, I couldn’t bring myself to do that. I was interested in what users wanted, of course, but I cared more about what they needed. And often they didn’t really know what was possible, so they would just ask for the solution they thought would work.
I found that having a richer discussion with them would get me to the “why” - what is the actual problem we’re trying to solve. And during these conversations, my mind was always churning on possible solutions. “They’re having this problem, what could we do to mitigate that?” or “They need this, what’s the best way to provide that?”
Before handing off a requirements document, I would do a lot of thinking on my own about potential solutions and the best way to meet the need. When needed, I’d consult with engineers or other technical leads to understand options.
My finished requirements documents would be, essentially, stories in numbered list form. Instead of “here’s a list of what the user said they want”, I wrote journeys. The user will log in, they will set up their preferred configurations (and here’s what the settings should start as), they will head over to this screen to do this work, then they will generate a report and send it to a coworker, then they will log out.
I wrote in this way partially because storytelling is the way my mind seems to organize this type of information. But it also ensured completeness: by documenting requirements as a journey, it becomes very easy to spot anything missing from that journey. And it helped delivery teams understand not just what to build, but why. Which pieces were most important, how features should fit together and flow, what the point of each element was.
I listened to and described problems, but what I delivered was a solution description.
I thought that was normal - isn’t that the job? - until I read the documents of other BAs. Which were… numbered lists of customer demands. In the days when we were supposed to hand off documents to a black box for delivery, this practice was a disaster. Developers were great at building exactly what was described, but anything not specified was guessed. And usually guessed wrong, because devs didn’t get to speak directly to the users. My products always came back pretty much right on point.
Reading this article from Marty Cagan, I’m seeing even more clearly why this was the case. Separating users from requirements from analysis from solution discovery from engineering is a great way to deliver a fractured product that doesn’t do all it can to meet users’ needs and solve their problems.
As a product manager, I’m definitely MUCH happier being intimately involved from end to end. Problem and solution are so closely connected, they need to be addressed and worked on together. It just makes sense.