I’ve noted previously that business analysis and product management are similar activities that exist in different contexts. Business analysis (as described by IIBA) tends to be used in internal product settings whereas product management tends to be used external product settings.
The two practices use different techniques. Business analysis makes much greater use of analysis models than product management, primarily because the context of internal products requires some way to work through the complicated nature of your organization.
You can use analysis models in an internal or external product setting to build and maintain shared understanding with your team. You may have to change when, how, and to what extent you use the models. I describe some ways to do that in the collaborative modeling technique brief I published this week.
Included in this week’s KBPUpdate are some resources that describe situations where collaborative modeling can be very helpful, as well as provide further descriptions of some collaborative modeling practices.
Kent J. McDonald
Understand your context
If you work in an external product setting and you think you should do some third party integrations, you may find that collaborative modeling – especially context diagrams to identify the interfaces and data dictionaries to describe the specifics, can be very useful. Context diagrams are helpful in internal product situations to work through the complications of your enterprise setting.
Define and Describe Backlog Items
Collaborative modeling is very helpful during product backlog refinement to get away from some common backlog refinement anti-patterns such as losing the big picture of the product in a sea of backlog items and not clearly understanding the details behind individual backlog items.
The OOPSI model for BDD Discovery created by Jenny Martin and Pete Buckney is a very good way to approach backlog refinement where you start with outcomes and get down to small chunks of value. Collaborative modeling is helpful when working with output, process, and input.
Collaboration requires more than one person.
In order for collaborative modeling to be, well, collaborative, it needs to include more than one person. The trick is that you have the right people involved in that discussion. The pattern I’ve found most helpful is the three amigos pattern to get the right perspectives in your modeling session.
You said wireframe. Did you mean prototype?
No newsletter on analysis models would be complete without at least a mention of the wireframe or prototype paradox. I’ll admit I sometimes confuse the two, so here’s a post that will hopefully provide some clarity. If I mix up the terms going forward, feel free to call me on it.
If you have questions or want to share your experiences of using analysis models, please share in the comments below.
If you know someone who may gain some value from a weekly rundown of resources for product people, let them know they can subscribe to the KBPUpdate.