Skip to content. | Skip to navigation

Personal tools
Document Actions
Home / Resources / Ask an Expert / Re-Write of our Core Product
Document Actions

Re-Write of our Core Product

We are trying to tackle a re-write of our core product. The re-write is huge and will be the foundation for the next 5-10 years of our growth and development. The product is very complex and disorganized (because of years of implementing one-off requests). I have some general themes that come from my industry and customer research...but I am at a loss as to how to get all the players on the same page AND how to tackle the detailed requirements for the re-write. Any suggestions?

Make sure that you’ve done a Positioning Document for the re-write release.  How do you plan to market the re-write? Is there customer value, or is it purely to give you a more sound platform for growth? Assuming that the new release will have some real customer value, then be a thought-leader and write the Positioning doc before they start with the re-write. Get everyone to “understand the target before shooting any arrows.” If you are not going to be marketing it differently, then state that as well. Just get everyone in line – even if it’s a little bit ugly from a marketing perspective.

Take a shot at the Business Case for the re-write. It will probably never pay itself back in real dollars, but hopefully it will give you additional revenue from plug-ins, new markets, less support/defects, other? Go ahead and lay out the dollars and cents – make sure that everyone realizes what this is costing the company and what direct and indirect return is expected, and how long it may take to get the revenue – your guess is as good as anyone else’s – take a shot, document your assumptions, and debate assumptions – as President of the Product, you need to be able to project the profit expectations of this re-write.

Are you having trouble getting your hands around the Market Requirements Document? Don’t forget to group/theme around problems, markets, goals. We always suggest rolling out the big releases in “phases and stages”, if possible. In the Requirements that Work seminar we talk about the 4 categories of Requirements: Buying, Using, Vision and Competition – make sure that you have categorized all of the requirements in one of those buckets. As a refresher: is this something that is asked for in RFP’s or will it help sell more? (Buying); is this something that will directly impact the Usage of the product? (Using); is this a requirement that no one will ask for, no one will really use it, but it’s something that we believe that we need to do? (Vision); is this something that we are doing because our competition has it? (Competition) – only do Competition if it’s also Buying or Using – it may be stupid.

Who will be the first target of the re-write? I’ve seen a lot of re-writes where companies target their existing customers first. This is the WORST first target. The first 1-2 releases of the re-written architecture will unlikely have all of the features or capabilities of your old version. Go after new customers first until you have the kinks worked out and then go to your existing customers.

Finally, please don’t get sucked into the technical details of the re-write. It is a “BLACK HOLE” from which you’ll never escape. Your company needs someone in there who is always asking “who will care about that?” and “will someone pay for that?” and “is there any other way we can do that than to totally re-write it?” Be annoying. You are in the middle of probably one of the most fun projects of your career. Just don’t look back on it and remember how you got sucked in and lost the big picture.

Answered by John Milburn