I wrote yesterday about the “Impact Areas” list, or as one of my Twitter followers put it much better than I did:
How to assess the impact to the rest of the product before committing to a feature.
Today I want to use the Impact Areas concept as an example of how a PM tool might automate the type of thing that’s not being automated today.
There are several ways I could approach this, in terms of tone:
- As a crie de couer – “please automate this useful function!”
- As an observation – “here’s a useful function that every PM does that isn’t automated and could be”
- As a gauntlet thrown down – “here’s an example of how you automate a useful function in a way that no tool does today”
I’ll go with the third approach, of course.
How to Automate The Impact Areas List
I’m against having to remember to do things. I don’t want to keep them in my head, as I like to use my head for other things. Like inventing.
As I’ve said before, there are lots of activities we do as product managers that are orthogonal to the traditional approach of simply giving me a handy way to work with lists. Often this is because the product management process is highly iterative, and the types of changes that occur over time are quite drastic.
However, the Impact List is tricky for another reason, which is that as you developing a requirement, you may know the answers to some of the questions, but not all. To ensure all the impact areas are considered, you have to revisit the requirement multiple times. With most tools – even if they supported something like the impact area list – you’d have to remember to do that yourself.
I’m against having to remember to do things. I don’t want to keep them in my head, as I like to use my head for other things. Like inventing.
Instead, let’s use the computer to remember that I have to do things. It’s far better at it than I am. The job of a PM tool, in addition to keeping useful lists, is to be my off-board memory, so I don’t have to make the same decision twice, and if I do need to revisit a decision, I can easily remember what led to the original decision. It’s also to help me find the things that I’ve already done some thinking about and enabling me to reuse that thinking in either the same context, or in a new context.
Obviously, there has to be a list of impact areas – I shared some yesterday, like:
- Default values or settings
- Notifications required for this feature
- The terminology and lexicon for the feature
You would come up with a set of impact areas specific to your product (and if it’s smart the tool has some defined by default that help the customer get a leg up on this list). These are entered into the system.
From then on, the tool runs the show, at least as far as the impact areas are concerned. At different points in the lifecycle of the requirement, the system asks you, via a dialog box, about these impact areas. You could answer that an impact area was unaffected (N/A), or note down the change, or ask the system to remind you later.
The system would then be able to do some useful things with this information. Of course, it could remind you later that there are unanswered questions about impact areas.
More interestingly, it could compare your answers to the answers for other features. If it found many similarities with another feature, it could ask you about the similarities, such as “Did we learn anything during the development of the other feature that would help us do a better job of implementing this one?” Or “That feature was originally estimated at 20 story points, but ended up taking 35 story points. This feature’s estimate is 20 story points – should it be flagged for additional estimation attention based on this comparison?”
I’ll continue down this path in my next post – how to get a PM tool to take a load off my brain.