A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

Deciding the big set of features when planning a new version of a software

When planning a new version of a software product, the initial timeframe is very critical for determining the future of that version. It is a time which requires a great product manager, and I have seen cases where a weak or a so-so Product Manager can screw up the entire release of the software product. In the initial period, there is a lot of pressure on the feature set required for the product, with inputs coming in from a number of different sources accompanied by different levels of pressure. So, the team members may come in with suggestions of what is required in the product, based on what they would have seen in the previous version and their version may seem a version that is very logical and justified. Similarly, senior management for the product may have their pet set of features, and they can exert a great deal of pressure on what can be put in the feature. The pressure to take a set of features from senior management can cause a number of product managers to buckle down and change their set and make adjustments.
On the other hand, I have seen Product Managers who are organized and methodical about how they get their set of features. They look at what their users have been saying, they look at industry trends (and not just competitor analysis), they look at what the application is weak in; and they have an idea as to how much the team can build in a single cycle. Further, they have an idea of what is required in an application version to get users, and not try to build every new feature into that specific release. Once, all this is factored in, a great Product Manager then comes out with a list of big features that will attract users and give a great selling factor. These by themselves don’t comprise everything new in the feature set for the application, but these do put together a significant portion of what the team will be building in the release. And not all of these will be customer facing features, these can also include architectural changes. For example, if an application needs to support 64 or High-DPI, these are also features that need time to build and test, and are a trade-off from the other features that are needed in the application.
Once the Product Manager has such a list, these are then shared with the managers of the application, and then the discussion happens. At this point, there will be a number of people who will have opinions on some of these features, but a good Product Manager can be trusted to make the right decisions for the product. With some more iterations, the list then goes for an evaluation of the effort required, and some initial estimates help determine which of the feature set can make it into the application (although this effort continues for the duration of development of the application – it is possible to re-scope features even when development is ongoing if there is a realization that the feature cannot make it in the given timeframe).

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>