I often use a list of product “Impact Areas” to assess the impact of a new feature on the rest of the product.
As I’m developing a requirement, I go through the list of impact areas and note down whether this feature requires a change in that area. If not, I mark it as “N/A.” If there is an impact, I note it down. When I was managing Accept360, some of the impact areas were:
Table views and filters. (We had user-definable filters for finding entities, so if there was a new property, you’d have to make sure the filters supported it and the result list could display it in a useful way)
The release or sprint backlog. The feature might need a new column, or a new business rule for calculating a column value
History log entries
Default values or settings
Notifications required for this feature
The terminology and lexicon for the feature
Are there best practices for using the new feature? What are they?
Import or export
Does this feature make other features obsolete?
In Accept360, I created a page in the requirement template with the Impact Area list. It was easy to go through the list and enter the notes. Today, using Confluence, I typically use a child page to capture the impact areas.
It’s sometimes difficult to make yourself go through this list, but particularly for bigger features, it’s a valuable exercise.
{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}
Buy My Book
If you like this content, you'll love my book!
It's great for new product managers. One reader said:
“I love your book. I have recommended it to all the PMs I mentor. In the past month probably 10. Not kidding. It is a gem. I wish I read it 15 years ago when I was getting into product.”
