If you’ve spent any significant time working on internal products you’re eventually going to get the opportunity to rebuild an existing product.
These types of initiatives have the advantage of having a great deal of information about the problem you’re trying to solve and a possible solution.
Sometimes you need to dig for that knowledge and be able to separate what people think the current product does and why from what the product actually does.
You also need to resist the urge to just rebuild exactly what you already have plus incorporating the odd user wishlist item here and there.
You want to think about how you would go about solving the problem you identify with the benefit of all you know about the problem from the years of using the existing system.
Here are the techniques I use when starting an effort to replace an existing system. They help you walk the delicate balance between understanding the current state and staying focused on solving a problem, not just recreating the same old system.
Use the problem statement to identify your desired outcome.
Let me clarify something right off the bat. You are not doing this initiative to rebuild the existing product. You are trying to solve one or more problems with the current situation. It could be the current system is no longer supportable. It could be that you the business process has changed so much that the existing product no longer supports it. It could be both those things and more.
In order to find out the real reason why you’re rebuilding an internal product, do the problem statement exercise with your team. It will ensure you have clarity on your desired outcomes, and it will help your team get a shared understanding of those desired outcomes.
Establish criteria to help you make decisions
As part of your discussion about outcomes, use the result of the problem statement exercise to determine a small number of decision filters. These are questions, usually expressed as “will this help us do x?” you use when you’re discussing possible options to decide which you will do, and which you won’t. If you ever find yourself in a discussion about whether to do something or not you can refer to these decision filters.
Explore the interfaces you currently have and would like to have
Any product that’s worth rebuilding most likely interfaces with at least a few other products, and at the very least is used by multiple people or departments in your organization. Use a context diagram to understand what those current interactions are and to identify potential future interactions. You can also use the context diagrams to identify interfaces that are manual today that you may want to automate in the future.
Explore the processes that the product supports
Every existing internal product that’s been in existence for a while supports one if not more business processes. When you go to explore those business processes, there’s the way it is supposed to happen, and the way it actually happens. You want to understand the latter because that’s going to clue you in on what the rebuilt product should actually operate. Using collaborative modeling to create a process model is the best way to get to that understanding.
Play the risk management game
Just because you are rebuilding an existing system does not mean your effort is without risk. In fact, one of the reasons the product you are rebuilding is so old is because of all the risks that exist in going about rebuilding it. Use the risk management game to identify, categorize, and determine how to address the key risks you face. And make sure you actually use the results of this exercise to guide your prioritization decisions. You’ll be glad you did.
Map out your crappy first draft
Regardless what some overzealous agile coach tells you, DO NOT jump immediately to brainstorming backlog items without first doing the activities mentioned above. Without the understanding those discussions bring, any effort at backlog creation is merely sticky note theater. When you do have the insights from those exercises, you’ll have a good overview of the problem and possible solution so you can start synthesizing what you have learned and think about how you may go about breaking the work up into backlog items. Story mapping can help you plot things out and think about how to group your backlog items in a meaningful way. It will at least help guide the conversation.
Thanks again for subscribing to Inside Product.
If you have any comments or questions about the newsletter, or there’s anything you’d like me to cover, just reply to this email.
Plus if you think someone else would get some value out of the newsletter, let them know they can sign up and get a free copy of Product Ownership in the Wild.
Talk to you next week,
Kent J. McDonald
Founder | KBP.Media