Knowing the base functionality that currently exists for a product is the first step in gaining necessary context to grasp what gets added on next. For organizations with established and expansive product portfolios, current functionality can be an area of contention between product owners, requirements writers and consumers of requirements.
I don’t get home as much as I used to. It’s odd going from being about two hours and three right-hand turns away to nearly eight hours away from home. It had been over a year since my last visit. I woke up early — often being so relaxed when I’m in that environment that I feel well-rested without my head ever touching a pillow.
I scurried down to get something to eat, opening up the cabinets with surprise. Cups. There were cups in the cabinet where bowls used to be. Luckily, I knew the outline of the kitchen well. Because of my familiarity, I knew there were only so many options of where my coveted breakfast bowl could be.
This scenario plays out often when a new iteration or release spins up. Scattered around new requirements are requirements statements that are specially marked as being “Current Functionality.”
While adding references to current functionality in requirements to provide a frame of reference for that necessary context seems like a great idea, I’ve found it backfires:
- This angers many engineers. Makes sense, right? They just got dropped in my mother’s kitchen — a completely new environment that’s had some changes made over time. Seeing “Current Functionality” in requirements can come off as a way of saying “Figure it out yourself.” Or, “do it like we do it currently in that other product,” to readers. To be honest, most questions around current functionality are around how the requirement was implemented, which will never be found in those simple statements. If there isn’t a base understanding of the current environment, how do we ever expect understanding of how a new component can be created and co-exist with an environment that is unknown?
- Scope creep goes on high alert. By peppering in the current state of things, the door swings wide open for folks to discuss how they never liked the way it currently works today. This feedback is great, but it should be kept out of scope of the initiated project.
If it’s not working, why even try putting current functionality notations in with requirements?
Well, you don’t want to reinvent the wheel. Current functionality isn’t a new requirement; it was an old requirement. If you documented a requirement each time it came up as something associated to new needs, you’ll have a requirements management nightmare on your hands.
Shouldn’t teams know the current state of things? The notations are a nice gesture to remind teams. If teams really struggle with the baseline, it’s a huge red flag that people really don’t know the organization’s products and services. If you’ve identified this in your product teams, I assure you that mentality can spread through an organization leading to a lot of terrible things: peers communicating invalid information to customers, sales making promises that can’t be kept — little changes quietly being made beyond the intended scope of the requirements that create misalignment across the product portfolio that may or may not get discovered by quality assurance.
If that’s the case, whose job is it to raise the subject matter expertise on products?
Sometimes things should be shouted from the rooftops. Products are the lifeblood of the organization. I would hope to be a product manager that gets people excited about what’s happening and what’s next for our products. Being honest that if you really want to learn a product, it’s going to take more than attending a demo. It’s getting your hands dirty, and setting aside the time to bounce around in new environments.
Everyone is responsible for their knowledge of the product, because they each bring a quintessential part to making the product better. Each carries a skill-set that is different. If development doesn’t really deeply understand the belly of the beast, they can’t make the best recommendations for execution. If professional services doesn’t know how the products their accounts paid for are functioning, they won’t pick up on juicy insights that customers will provide — or they won’t recognize red flags in implementations until it’s too late. If quality assurance doesn’t understand how the new is intertwined with the old, then the whole scope of what could be impacted as changes are made won’t be fully tested.
As time has gone on, I’ve gained the impression that the requirements document isn’t really the best home to intermix current functionality. But then what? Do you expect teams to hunt down the old release documents or pull up an associated requirements number in a software program? What are ways that you work to keep all members of the organization actively involved and in the loops with all things product?
I’d love to hear your thoughts on this one.