Great ideas are meaningless unless they are executed almost perfectly. The Product Managers‘s best shot at success is to deliver their product (or service) the way they see it on their first release. Using a great product management software tool can be a make or break factor for the success of your product launch by optimizing your chance in delivering the product the way you visioned it.
This blog posting should help guide you, the product manager, to select the best software for this job. There are many software services on the market today and most will position themsleves as a great product management software tool, so if you follow these suggestions, you can make sure you select the best tool. Remember, what’s great for the project manager isn’t necessarily great for the product manager.
So here we go with my top 10 suggestions for selecting the best product management software for the job.
1. Support your project management style. (Agile / Waterfall)
Whether you use Agile or Waterfall for your project management style, you need to make sure your product requirements software supports this. For example, if you are an Agile (or Sprint) shop, you may be working in two sprints/iterations and must be able to pull product requirements from your product backlog, and drop them into an iteration.
If you are a pure waterfall shop, than your project and iteration maybe wrapped up into one monolithic iteration, but you should still be able to define this within the project so that if you need to punt features to a later phase, your software provides the ability to do this.
2. Ability to communicate and socialize your requirements to the cross functional team.
Being “Social” isn’t just a buzzword, it’s an important aspect in the success of your project. It simply means that your cross-functional team will have the ability to easily provide feedback on requirements which then evolve into the correct requirements. Whatever product software you choose, must be able to allow developers or project managers to comment or question a requirement, and have the product manager revise back into the definition.
For those of you (the majority) who use Facebook, you know that when someone comments, you can see a large thread of the comments and can continually track the thread until it eventually dies out. This is the social aspect of requirements management which simulates a discussion.
3. Collaboration is important for soliciting feedback.
As part of #2 above, the collaboration aspect will mean that the product management software should allow users to receive notifications on a change , comment or question, and drive them back into the software to encourage feedback. If it’s too difficult or not seamless for a user to comment or question a requirement, you have just undercut your ability as the product manager to get the best possible requirements in the first pass.
4. Presentation of your reports.
At the end of the day, your deliverables are going to be your requirement reports like your Product Requirements Document, and perhaps traceability reports. The value of your system will be based on how easy it is for your customer or management to consume the report. So if they appear sloppy or unreadable, your system is basically useless. When you are evaluating different Product Requirements systems, don’t be shy about asking the vendor to send you some sample reports. If you find them difficult to read or generate, you found your answer.
5. Stakeholder approvals of requirements.
The customer who is paying you to build your system may only need to view reports, or just be the approver of requirements. For this reason, good product management software will provide an Approval only capability where the stakeholders can log in and approve requirements. Performing this task should be very simple, and done without or minimal training.
6. Less is more (simplicity)
For those of you who have read any of my material or blog posts, you are probably so bored of me talking about the 80/20 rule. Too bad! ..because it’s such an awesome rule that can be applied to making so many aspects of our lives more efficient and simple. In this context, we have seen so many of these Product Requirements Management tools get so bloated and complex. This happens when the management of these vendors want to please everybody. The best product management software can be used without a training manual, and will appear to be simple to use even with strong offerings. You want to choose a tool that accomplishes 80% of what you’re looking for. Go for a simple tool and you will be amazed at what you can accomplish with it.
7. Integration with Word/Excel
While Product Management Software vendors attempt to push their customers into using a web (or desktop) interface to manage their requirements, the truth is that most product managers and business analysts prefer to use Word or Excel as their database to manage their requirements. The enormous bulk of these customers will never move to a tool. So the best thing you can do when selecting such a tool, is to find one that allows an integration between Word and the tool. A product manager could then still use Word to publish and manage their requirements, and push the data into the datbase with one fell swoop.
8. Working in the Cloud
Some of the best tools on the market are Cloud based (SaaS) tools, and that’s where our market is heading so given the climate of global resources and disparate teams, it wouldn’t make sense to not use a cloud solution to manage your requirements. As a critical criteria for selecting a Cloud based tool is to make sure they have world-class data security. That means securing the privacy, and security of your data. I could probably provide a separate blog post on selecting the best Cloud based tool, but the security and privacy of your data is critical.
9. True Open System (integration with jira, etc.)
Whether you are using a Cloud based or desktop tool, this system must be able to open it’s doors to receiving or sending data. At some point you will be needing to integrate into a bug database, or a task management system, or something that needs to interface with your product requirements. Having a “closed” product management system (one that can’t interface) will cost you down the road. At the minimum, the tool should be able to provide a simple import and export mechanism. The better ones on the market will provide you hooks or customer API’s for publishing or receiving data.
10. Offline Capabilities
I hate the thought of a product manager hobbled from writing up requirements, just because they’re not connected to the internet. Sounds pretty lame, doesn’t it? That leads me to #10 — a product manager tool should be able to allow the product owner or analyst to write up requirements when offline. This is more of a tall order for SaaS tools, but not impossible. There are many ways for vendors to provide an integration from MS-Word so that you can queue up your requirements while offline, and have them imported once you’re get connected.
While there are other things I could have put on this list, these suggestions should be a really good start for your evaluation process.
Latest posts by Jacob Leigh (see all)
- Requirements Management Survey, Can you spare us 60 seconds? - December 30, 2014
- Value of heatmaps influencing requirements and decisions - September 23, 2013
- Gatherspace in search of bus-dev Partner (co-founder) - August 20, 2013