Product Development - Rolling out the patch

The previous post had thoughts on what are some of the conditions under which a software patch is typically required. Once the decision has been made to make a patch, there are a set of activities that are needed to be done. A patch typically is a miniature version of a complete product development cycle, not with all the activities, but certainly having many of the steps that one needs to carry out in the typical cycle. What are some of these steps that are needed to be done ?
- Decide on which of the fixes need to make it to the patch: When preparing a patch, there is always the temptation to fix all the issues that have been found after the release. However, beware of feature creep. You should only include fixes on the patch that are deemed critical. Putting other fixes means that the time period for the patch becomes longer, it means that QE needs to out more effort to test the patch, and so on.
- Make sure that all the teams are signed up for this patch. For a moderately sized software company, there will be multiple teams (with their specialized functions) that are needed to make the patch. These include the development team, quality testing team, configuration team that is responsible for the installer and release, localization team (if there are multiple languages involved - this is another decision point, whether the patch needs to be rolled out for all languages), marketing teams to ensure that patch publicity plans have been rolled out, web teams (if the company website is maintained by another team, they need to involved so that they can schedule the patch rollout date into their plans)
- Decide the schedule of the patch. Even though this is an abbreviated release, it will still take time, and the further this time pushes into the schedule for the next release, the more impact that this patch will have in terms of creating problems for the next release.
- Decide on branching strategies. Typically teams need to make sure that the source code repository has a proper branch created to handle the new branch for the patch. In most cases, the entire team will not be involved in making the patch, and so the work being done by the rest of the team for the new version will be on the main branch, and the work being done by the engineers working on the patch will be on the separate branch. A strategy also needs to ensure that the defects being fixed on the patch will be integrated with the main branch once the work on the patch is done.
- At the time the work on the patch is being carried out, if the patch is due to some major customer issues or some security issues, then the marketing and management of the team need to decide whether to release news of an upcoming patch. Typically, news of patches are not released earlier, but sometimes such news can help in calming down customers who would otherwise be worried.
- Development work for the fixes that go into the patch will need to be done. This typically involves a thorough engineering investigation into the issues that need to be fixed as well as working with outside partners if the issues needs such cooperation
- Once the fixes are made, they need to be thoroughly tested by the QE team on the different platforms on which the software is supported
- Now the patch is ready, and needs to be rolled out through the different media that can be used. The patch can be mentioned on the company web site, on the product page, in customer support forums, to product users directly if there is the ability to send software users a notification inside the product, via email to all the registered users, show as an update to users if the app has the ability to do an automatic check for updates.

The next post will talk about minor (dot) releases and the difference between a patch and a dot release.

Product Development - Doing a patcher or a minor release

When doing the planning for a new version of the product (not typically applicable when creating a new product), it sometimes becomes necessary to consider the case of doing a patcher or a minor release (also known as dot release).
Picture this scenario - your product development team has already started planning for the features that will be implemented in the new cycle. They are trying to get an initial SWAG (literally means a Wild Ass Guess, but is typically used to define when experienced development managers and engineers do a rough guess of the amount of resources it will take to develop a given feature), are working with Product Management and User Design to get some more details of the initial feature requirements such that a more accurate estimate (but still rough estimate) is available. In the middle of this, if they are suddenly confronted with the need to plan for doing a patch or a dot (minor) release, it can take away a fair number of resources and affect the schedule for the next version.
So why does a team end up doing a patch or a minor release (dot release) ? Let's talk about a patcher first.
Reasons for doing a patcher:
- Easiest reason. After releasing the product, you discover a bug (through internal testing or from customers) that is liable to affect a number of customers. So, suppose you are doing a printing application, and you find that printing of Excel documents does not happen properly in common cases, this is something that cause you to do a patch. There is a high priority that a number of customers will get affected by such a problem.
- Crashes. A slightly more difficult situation where a number of customers have reported problems where the application suddenly crashes. On diagnosis, you find the root cause of the problem and decide that the risk of customers getting the crash is not very low, or there is a high risk of important data loss when the crash does happen. This is very important for certain classes of applications such as financial and enterprise applications.
- Customer / Tech support issues. There are a variety of issues that are not important enough to warrant a patcher on their own, but together they are causing problems with a high frequency of customer support issues and tech forums posts. Because all of these have a cost (and a lowered reputation because of many customer posts on forums is not easy to recover from), it is sometimes important to admit that there were mistakes made and release a patch.
- Device dependencies. Support you are a maker of a photo software, and many new cameras are released (or you discover problems with some existing cameras), it is important to project an image that you are responsive to developments in your field and are providing updates to your customers.
- Adding some important new operational functionality. This is a slightly tricky area since the recommendation is not implement new functionality in a patch, but if you have some important new functionality that needs to be implemented in as many existing customer apps as possible, then this is something that seems permissible. For example, if you get a new component that allows you to provide customers with a new and easier update mechanism, it makes sense to provide such a functionality through a patch available for wide download and use
- Dependencies on other software. Nowadays most large software applications also internally use other software components. For example, video players will use external codecs, CD burning software will use device burning codecs from Nero or Sonic, and many other such examples. If you find that your dependency is going to cause problems unless you install a newer version of the external component, a simple way is to incorporate such changes in a patcher.
- Competition. Your competition is going to release a new version of their software that gives them a competitive advantage, and your development process means that you cannot release a new version quickly enough. A workaround is to make the changes in a patch and make that available to your customers.

This post is turning out to be longer than I thought, so the process for deploying patches as well as the development of minor releases will be covered in the next post ..

Product Development - Requirements Planning - Template

In the previous 2 posts, I have been talking about the process leading to a presentation, right at the beginning of the project, where product management presents their plan of feature implementation, revenue and pricing figures, competition analysis, and so on. The objective of such a meeting is to ensure that management / executive sponsors know the direction that the product will take, are able to satisfy their doubts, and then can either bless the direction taken by product management or send the team back to the drawing board for re-making the strategies OR do some slight tweaking.
For this information to be presented to management, it has to be packaged in a proper template where the information is arranged in logical order. I have tried to find templates that can meet these needs on the internet, and some of them are below. You may need to modify or tweak them slightly to suit them as per your needs.

1. Startup business plan at score.org (link): This is a template more for a business plan, but it contains some very relevant questions that you need to answer for the purpose of creating a new product; you can take the relevant questions from this template and adopt for your own need.

2. A sales forecast plan (link): This entire page is very useful for the purpose of building and forecasting a sales plan, and can help you build up the figures required for doing your revenue forecasting.

3. Product Development Schedule Template Syn1.0 ($ 59) (link): a detailed list of activities and tasks for planning and managing product concept, design, development, test, launch and release.

4. VSD Template (link): Has a lot of steps that you should be logically taking if you are defining a new product

5. SWOT analysis template (link): Strengths, Weaknesses, Opportunities, Threats - a useful analysis that you should carry out for your new product development

6. Marketing Plan Template (link): Very useful for preparing the marketing and product management plan that will help you to prepare for the presentation

7. Product development planning from Microsoft (link): This template outlines a strategic approach for product development. By working with your business position in the marketplace, establishing product infrastructure, and leveraging knowledge of your targets and competitors, this template establishes a framework to begin product development. This is a Microsoft Project 2007 template.

8. Individual templates for efficiency during the product planning process (link)

9. Alta Advisor product creation plan (link): Helps you collect the information you will need to prepare a proper plan, as well as provide you many points that you can use to present to management.

10. Product Manager's Toolkit (link): Many tools such as MRD, PRD, Business Case, etc, all that will help you prepare for a new product plan.

11. Product Definition and Launch Plan Template (link): A Word document that acts as an MRD

12. Six free templates (link): Product Management Life Cycle Model, Product Strategy Outline, Ten Step Marketing Plan Outline, Marketing Dictionary, Guideline for Managing Product Team Meetings, Strategic Marketing Planning Model

13. Sample Marketing Requirements Document (MRD) (link)

Product Development - some of the project planning related steps - Requirements gathering contd..

Typically, when a new project or new version is being conceptualized, the actual product development is not kicked off until senior management / executives have had a chance to review the requirements identified for the release and get a sense of assurance that the features planned for the release fulfil certain conditions. This typically is handled in a kickoff meeting where the set of requirements / features is presented to the management, and where management can quiz the product managers with a series of questions until they are satisfied. It happens many times that the product management team is sent back to the drawing board with some feature changes or tweaks to the existing feature. This meeting is typically called a Product Requirements Review, and is managed by the Product Management team. It goes without saying that the more important the product to the overall revenue and future of the company, the more involved is this meeting. The questions are harder, the research and data needs to be more thoroughly done, and the presentation needs to be reviewer before-hand so that the flow of the presentation can be maintained.
What are the items that are typically validated in such a meeting:
1. These additional features are such that customers must be ready to pay for the product version or the new product
2. Management also needs to see other features that were planned but not being executed in this cycle because of time constraints (the second tier of features)
3. Management needs to get a preview of existing competitor features as well as new proposed features
4. Data that is available from the field (including existing customer reports - enhancement needs and complaints) both help in this kind of presentation, and give a perspective of how current customer satisfaction levels are
5. Pricing for the products (including enhanced pricing, update pricing for customers wanting to upgrade from earlier versions, volume pricing) needs to be decided and validated. This will include strategies for trials (where users can try either a limited set of features without the software timing out, or try out the full feature set for a limited period of time)
6. Deals with partners are also presented in such a meeting. This includes the pricing if bundling is done with computer hardware OEM's, or packaged with installers of other products (example, when anti-virus trial downloads are available along with Yahoo / Google toolbar downloads, and Google toolbar is also downloaded with other products)
7. The timing of the release is also an important factor in this whole discussion; given that product release timing is extremely important - after all, if you have a consumer game product, it would need to be released so that it can catch the Christmas buying season.

Product Development - some of the project planning related steps - Requirements gathering

Most people in the software industry have heard of the Software Development Life Cycle (SDLC). In the full form that you read in most literature, it has a number of steps, and may seem a bit long-winded. However, the practical version of the SDLC is to the effect of:
Requirements -> Design -> Development -> Testing & Bug fixing -> Alpha / Beta Release -> Acceptance testing -> Release
There are more complications in this process, with many additional steps such as the resource estimation that happens during requirements and design, development of test cases that happens during the design and development phase, generation of the software documentation, etc.

Now, when you step into the world of product building (whether to build a new product, or to generate a new version of an existing product), there is a slightly modified version of the SDLC (typically called the Product Development Life Cycle, or PDLC). I am not going to be covering the PDLC in a complete form in this post, instead, in the next series of posts, will cover a practical experience of what happens during the Product Development Life Cycle. If you see things happening differently in your company, please share through the comments.
Suppose you are the project / program manager for a product that has been released before, and you are doing new version planning, here are some of the initial activities that you should be considering:
- User feedback collection: Never neglect that among the changes you need to make in the newer version will be modifications of existing features. Sometimes, the focus of the team is on building new features, but if existing features do not work well for customers, then the problems with these features need to be studied, and then the team needs to discuss as to which of the problems should be taken and corresponding features modified
- Once these modifications are identified, there needs to be some detailing of some of these changes along with further concretisation of what would be a new desired workflow (this can be done through usability testing with the desired audience)
- This was it for changes to existing features. In addition (or actually the main work) is to decide which are the main features that need to be taken. Sources for generating this list of features includes customer feedback from sales and marketing teams, bug reports / feature requests filed by customers on user forums, in product reviews and so on.
- Another great source for generating a list of new features is by looking at features that are available with customers, and deciding on the list of features that are must-haves
- Another source is the list of features generated by reviewers when you are showing your product for review. Typically, they will give you feedback for the features, and also ask you about features that are not present in your product. Many of these reviewers have a feel for the pulse of the customer base, and you would be wise to review the features that they are asking for
- Sometimes, the feature list needs to be generated internally. You need to create a new market, or present a feature that will make your competitors feel that they are way behind, and one good way is to get the marketing teams, as well as the product teams together in a brainstorming session and thrash out possible features that need to be incorporated.

Enough for this post, the next post in this series with continue with requirements generation and further analysis..

Function Point Analysis Resources / Tools

Function Point Analysis is one of the most important methods in use right now for estimating the 'size' of a project, the aim being to break down a project into smaller parts that can be used as the basis for estimation. However, it can be complex, and before somebody rushes into this area, it is advised that they read more on this area. So here are some resources and tools that should help (if you know more that should help, please add them in the comments):

International Function Point Users Group: The mission of IFPUG is to be a recognized leader in promoting and encouraging the effective management of application software development and maintenance activities through the use of Function Point Analysis and other software measurement techniques. IFPUG endorses FPA as its standard methodology for software sizing. In support of this, IFPUG maintains the Function Point Counting Practices Manual, the recognized industry standard for FPA.

Bulletin Board for discussions on the above site. There are a large number of discussions on this forum.

Newsgroup on FPA. Access via Google.

An older FAQ on royceedwards.com

Function Point Analysis on Wikipedia

Function Points Analysis on Total Metrics: More resources including such material - How to use FP Metrics in a Project, Which Functional Size Method to Use?, etc

Cosmic-ISO: The New Generation of Functional Size Measurement Methods

Metrics Documentation Toolkit on totalmetrics.com

Free function point manual (111 pages of goodness in a PDF file)

Online Function Point training on softwaremetrics.com

Article explaining levels of FP counting

Tools page at usc.edu

PQMPlus tool at Q/P Management Group

FP resources at devdaily.com

Tool: Metre v2.3

Tool: Function Point WORKBENCH. Available at this site.

Tool: Function Point Analysis GUI Tool: Read / Download.