I am responsible for two products that use the same underlying code, but I have to plan out the new features. Should I try to get a few upgrades to each product or release upgrades for each product separately?

Answer from Ivan Chalif of The Productologist: Unless the two products are tied together (they interoperate or one requires the other), it’s best to focus on them as separate entities.

The scenario you described is similar to how companies split product development into two discrete functions: platform and application. The platform is the base technology that does all of the heavy lifting and provides the core functions of the software. One or more applications can sit on top of the platform and utilize its capabilities, but are tailored to the specific needs of a particular user.

From your question, it’s not clear if you really have a platform/application setup or if you just have two applications that share some of the code base, but are sufficiently different to be considered separate products. For the sake of this discussion, I’ll go with the latter, since the platform/application model of development is pretty common in enterprise software. Here are a few places to learn more about it:

http://en.wikipedia.org/wiki/Platform_(computing)
http://blogs.msdn.com/mikemill/archive/2007/06/27/what-is-an-application-platform.aspx
http://gigaom.com/2008/06/30/10-of-the-biggest-platform-development-mistakes/

For distinct products that share some or most of the same code base, you should treat each product as discrete and create separate product roadmaps for them. This will provide the appropriate focus and attention that each one deserves. If you keep them on the same roadmap, there will be a tendency to combine or merge them which, if that is not your plan, could hamper the success of one or both of the products. Keeping them together also increases the risk that you will make compromises between the two versions which will dilute the benefit of having distinct products.

By keeping them separate, you can plan for features that address the needs of the specific users of that version. New features and defects can be evaluated on their merits as they relate to the individual product, rather than as a component of the shared software. Tradeoffs will still need to be made, but your focus should be on solving the problems of the users rather than compromising between products.

As for release schedules, a lot depends on your Engineering and QA teams and your release process. One option is to alternate releases so that every X weeks or months you have one release that is focused on a specific product. This allows you to put in new features on a regular basis and puts some defect fixes in that benefit both products. You can fix more defects this way, but the cycles to get them into releases is longer. Another option is to make changes to the common code in one release and then have separate releases for new features to each of the product-specific code bases. This is similar to the platform/application model, and gives you the opportunity to have more frequent releases.

Don’t kid yourself, though. This is not easy and will require some sophisticated tracking by you and the development team to keep things from getting messy. Depending on the size of your organization and product sophistication, it may make sense to move to the platform/application paradigm. That model provides a clear delineation between the underlying shared code base and the application-specific code base.

Additionally, you should also evaluate whether you really want to keep the products separate in the future. It may turn out that keeping the products separate causes more problems than combining them. Using a licensing mechanism, you can have a single version of the software act like two separate products by controlling what features and functions are available in each version of the product. This adds complexity to the software, but makes it much easier to maintain and provides a greater level of flexibility in creating variations of the software for different users/verticals/markets.

I have about 11 years of experience in the IT industry with last 5 as managing Custom built applications for different domains and different technologies. I though cannot claim to be a Technology expert. Can I or should I make a move into the Product Management Team of a large organization. Is there a way for me to assess if I will be a right fit in Product Management?

Answer from Ivan Chalif of The Productologist: Product Management is one of those professions where your background is not necessarily as important as whether you are good at and/or enjoy the daily tasks. Great Product Managers traditionally come from Engineering and Marketing backgrounds, but Product Management is a multi-disciplinary practice and having a diverse background, either educationally or through your experience can be an asset as a Product Manager. I personally have undergraduate and graduate degrees in Psychology, which you wouldn’t normally associate with Product Management, but which have served me immensely in my work.

Having a background in any kind of technology is usually a good thing, especially with software Product Management, so even though you don’t claim that you are a “technology expert,” your experience is likely to be an asset. Before you evaluate whether Product Management is the right move for you, figure out why you want to make a change. There are many factors that push folks to consider changing or shifting direction in a career and they aren’t all related to the actual job description. For example, consider which of these might be factors in why you want to make a change:

• Salary
• Daily tasks
• Peers or other staff
• Available projects
• Manager
• Career advancement
• Job availability
• Professional interests
• Business requirements
• Work environment

What you may have guessed is that many of these are factors about changing your current job, but not necessarily about changing your current TYPE of job. What you should really take a hard look at when you determine if Product Management is the right fit for you is first whether you want to change jobs or change careers.

Once you figure that out (and if the answer is “change careers”), the next thing to consider is how comfortable you are with the types of tasks that Product Managers do on a daily basis. A good place to start is to go to dice.com or craigslist or monster.com and do a search for “Product Manager” (make sure you use quotes to search for the string instead of the individual words). Look at a bunch of the job descriptions and see where they overlap. Chances are that there are a lot of requirements like these:

• work with Sales, Support and other stakeholders to understand market needs
• plan and coordinate release priorities with Engineering
• communicate effectively with executive team, customers, and prospects
• be the product evangelist
• write white papers, product literature, user guides, and other supporting documentation

In a nutshell, what this means is that you will spend a lot of time in meetings and you will need to be able to effectively communicate and manage folks who you don’t have any direct (or even in-direct) authority over. Adam Bullied over at Write That Down has an excellent post about how that’s easy and there’s a comment from me about why I disagree, but there’s truth on both sides; you have to be the one to figure out if that’s the kind of role that you can and want to be successful in.

Also, if you haven’t already, read some of the active Product Management blogs (or do a search on “product management blog”) and see if the issues and topics that are being discussed fit with what you want career-wise. It’s not perfect, but it’s a good proxy for the types of challenges you will run into as a Product Manager.

The other part of the question deals specifically with moving to Product Management in a LARGE organization. Large organization does not always equal large Product Management team. If the company you are with or want to be with has a large Product Management team then your role in it will likely be very specialized. It won’t be a role of “many hats,” it will be a role of “know-everything-about-this-piece.” That may be appealing to you…or not. In a large company, there is also a good deal more process and bureaucracy, which again can be a benefit or a liability.

Large organizations can be a great place to learn about Product Management because there are already people who know more about Product Management than you (hopefully) and the environment is relatively safe (mature product, sophisticated release process, etc), but it will take a while to gather all of the knowledge and experience necessary to be a stand-alone Product Manager. Additionally, large organizations typically have budget for training, which is not usually available at smaller companies. If you do end up in a PM role at a large company, I would do everything I could to get them to send you to some Product Management training classes (Pragmatic Marketing, 280 Group, and Sequent are just a few out there.

Big organization or small, there are no hard and fast rules about who can be a Product Manager, but it does require passion and patience and a willingness to stretch outside your comfort zone on a regular basis. You just have to figure out if that’s the kind of job you want.

Do you have suggestions for “best practice” product roadmap tools or literature for technology organizations attempting to develop product road maps with a business focus?

Answer from Ivan Chalif of The Productologist: Whether you are planning a business- or consumer-focused product, the product roadmap process is basically the same–plotting features and/or releases on a timeline. Product Management tools that help PM’s collect, analyze, and prioritize features (Accept, Accompa, FeaturePlan, FocalPoint, and others) can be very useful and they usually provide a way to produce a product roadmap document, either as an export or in a report view. While tools like these are designed specifically to make it easier to create/manage products, I have found that the tools which you already use on a daily basis, like Microsoft’s Office suite (or whatever word processing/spreadsheet/presentation software you use) work just fine for creating product roadmaps, too.

Product roadmaps typically serve two purposes. First, the roadmap is a tool for the Product Manager or Product Management team to use to map out the product strategy over the course of the next few months or years. The roadmap keeps everyone on the same page and provides a wide-angle view of both features/defect fixes and the release schedule.

The product roadmap can also be used as a mechanism for communicating the product strategy or release schedule (more on the difference between those two later) to other business functions or even customers and prospects. There are many opportunities to share the product roadmap with folks inside and outside of the company and providing a glimpse into the strategy and/or schedule can help guide discussions about hiring, resource planning, and strategic alliances.

Let’s look at the second use first. When communicating with other departments, the executive team, or external folks, it’s important to keep the message simple and accessible. That means high-level information in a format that everyone can read. For this type of communication, the information should be the focus. That’s why I prefer to create product roadmaps for communication purposes in PowerPoint. Most times, I am discussing the roadmap with folks who don’t care about the nitty-gritty details of enhancements or bug fixes. They want to know what to expect from the product within the next 1-3 years. What is the strategy? Where is the product headed? PowerPoint provides an easy way to create timelines that highlight where releases fall or what the theme of each release will be.

Using a tool like PowerPoint also provides a lot of flexibility in how the data is presented. I frequently have to modify the roadmap to accommodate the interests or knowledge level of the audience I am presenting to. PowerPoint lets me easily modify both the format and data presented (switching from release themes to release dates is a good example of how you can quickly create different views of the roadmap). At StrongMail, we use product roadmaps created in PowerPoint to share product strategy with customers, prospects, and internal team members.

A product roadmap doesn’t have to be graphical, though. You can just as easily make the roadmap text-based using either Word or Excel (or as I mentioned earlier, similar applications in other office suites). Using a text-based format makes the data even more transformable because it can so easily be moved between mediums and is just easier to work with by its simplistic nature.

Now, let’s revisit the first use of product roadmaps. At MediaPlex, I created a product roadmap in Excel because it made prioritization of upcoming features easier. The roadmap was much more of a scheduling tool for Engineering, so it made sense to have the specific enhancements and defect fixes listed out in detail. Once they were prioritized, I just cut/copy/pasted them into the MRD template, added some additional details and voila, release planned!

When I was working at Digital Impact (now Acxiom Digital), we used a combination of PowerPoint and Excel to manage the roadmap. PowerPoint was used to plan the long-term strategy and release calendar while the focus and details of each product release were tracked in Excel. While this method lets you track and communicate a wider range of data, I don’t recommend it. It requires that you keep two separate documents in sync and sometimes one shows up without the other, and because the data in one document relies on the data in the other document, it can be a bit cumbersome having to switch back and forth between them, both when editing and presenting.

Lastly, here’s a note about communicating product strategy versus the product release schedule. Roadmaps can be used to share information with internal teams, external constituents or as a planning tool for the Product Management team, but whichever you choose, you have to figure out whether you are going to make the focus of the roadmap strategy or release calendar. If it is strategy, your timeline can be vague — quarters or years. If it’s release calendar, the near-term has to be pretty specific: exact date or month, but the future can be more nebulous.

Having said all of that, the choice about how to manage your product roadmap and what tool(s) you use to do that depends a lot on your Product team and the audience for the roadmap. Is your audience going to respond better to high-level data, such as release versions and dates or are they looking for granular details, like which exact features and fixes will be in a particular release?

You also need to consider how frequently you plan to update the roadmap. The more detail and complexity you add to the roadmap, the more difficult and time-consuming it will be to update. This is fine if you are only planning to modify the roadmap a few times a year, but if you are at a start-up and/or your product is in a fluid state, you will want to keep it relatively simple so that making changes doesn’t take as long (or longer) as the actual implementation.

And as a final consideration, determine whether you plan to have the roadmap stand on its own or if it needs to be accompanied by additional details and voice-over. Several companies — splunk, Borland, and even Microsoft — have started displaying their product roadmaps to the public by making it available on their websites. This level of disclosure requires that your roadmap be able to be understood even when you aren’t there to explain it.

Figuring out how you are going to use the roadmap is the first step to identifying which format and tools will best suit your needs. There is no right or wrong way and what you choose now may not be what you need in the future, so don’t get hung up on it too much. Think about it like your product. Evaluate the market need(s) and then create a solution that addresses those needs.

For more on Product Roadmaps, check out my blog post from August 2007: Building a Working Roadmap.