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.”
>