With product requirements, one temptation a Product Manager has to fight is the desire to jump into the details. You already know what you want, lord knows you’ve heard what people want often enough, someone’s got to actually put them on paper, and that someone is you, so you might as well get started.
But there’s an important step to requirements that you as the Product Manager must facilitate with the executive or management team. This takes place before getting into detailed suggestions from the market, sales reps, consultants, etc.
I haven’t really heard anyone give a name to this. It’s like a Requirements Executive Meeting. Perhaps “Envisioning Meeting” would be the best term. Its purpose is to have a panoramic discussion of the product, one that takes into account all the different departments and functions the product touches.
The Envisioning Meeting is not about developing a product vision, nor is it the creation of a product road map. It’s about having a thorough discussion between all members of the management team about what is needed – or what might be needed – by each department.
The goal of holding an Envisioning Meeting is to have a product that is designed to be good for the company, not just one that sells well. What I mean by that is that it’s vital to make sure that the product does not neglect a critical function of the company in a way that costs the organization.
Say the product has great new capabilities with each release, but the installation process isn’t automated. It’s a time consuming and money-losing activity draining the profitability of the company.
This is where the Envisioning Meeting serves as the place where Professional Services can address this with the entire team. Read on for some ideas on holding an Envisioning Meeting.
[private]
Envisioning the Product
Keep these things in mind when holding an Envisioning Meeting:
First Comes Love, Then Comes Marriage
The Envisioning Meeting is a forum for free discussion of ideas about what’s needing in the product, what’s coming down the pike in the market, or where a given department is experiencing pain when dealing with the product. It’s not the place to make a commitment to new capabilities.
It may take time before ideas coming from different perspectives and different departments are accepted by others. The Envisioning Meeting is an opportunity to develop the understanding of the entire management team and get them on the same page. Only after everyone’s in agreement – and the team may not be there until a while after the meeting, when they’ve had a chance to absorb what was discussed – are you ready to move forward with defining a requirement.
Clash of the Titans
The Envisioning Meeting is not designed to bring together all possible input from every level in the company. It aims to bring the top management team together, plus the people who will be critical to completing the Requirements, such as Product Managers.
The meeting is the occasion for those who head up the major departments – Engineering, Marketing, Sales, Professional Services, etc. – to meet and hash things out at the top level so that you, as the Product Manager, can move forward with the confidence that the team will back your requirements.
Look to The Horizon
The Envisioning Meeting looks forward not just to the next release, but to the coming year. It takes a slightly longer perspective. Now is the time to mention some of the things you see coming down the pike, even though the consensus may be that they are not required for the very next release.
Bring Everybody In
Make sure that every major area of the company that is directly affected by the product – probably not Investor Relations or Accounting, for example – is represented by the appropriate VP or director.
While you are not looking for input from all levels of the company at this point, you are looking at input across a full spectrum of departments.
It’s Not Just the Software
The scope of the Envisioning Meeting goes beyond only software. It encompasses the product, which includes not just development but delivery, implementation, and service. All of these components need to be brought into the definition of the product, at least when it comes to determining requirements and capabilities.
It’s important to look for improvements to the product that are not so much new functionality as time-savers for selling, implementing and servicing the product.
Trickle Down Requirements
The outcome of the Envisioning Meeting will be very high level decisions about what’s needed and what the top priorities are. From there the information trickles down into detailed Requirements to be submitted to Engineering.
Marketing and Sales
What might be needed for Marketing and Sales? Does the company need the ability to install a standard demo on multiple PCs and laptops for sales reps and sales engineers? Do you need a standard set of data for this demo? Do you need the ability to restore the demo to a clean state after lots of junk records have been entered in the course of discussions with prospects?
Professional Services
Do consultants need a way to take documents they develop with the customer’s implementation team, such as lists of users, roles, categories, or portals, and automatically enter them into the software?
Do trainers need a standard training database – it could be the same as the demo database, or maybe it needs more detail – and a utility to wipe the database clean for the start of each new class?
Installation
Do installers need a more automated yet configurable installation process? Do they need an architecture that allows for remote installations from your Professional Services Center?
Customer Service
Do customer care reps need an easy way to review commonly consulted configuration variables and other information that will permit them to diagnose the cause of a problem? What about the ability to capture error messages and transmit them to Engineering for review?
Partners
Do partners need such things as automated, configurable and customizable installation routines, or the ability to automatically switch between your standard product and their own branded versions of it?
Do you have partners who provide the management and business process consulting, and need an automated way to have the software reflect their specifications for standard processes and reports?
Now, For the Details
Once the Envisioning Meeting, or meetings, achieve a level of agreement, once everyone’s on the same page, you as the Product Manager are ready to put pen to paper and prepare the Requirements.
By getting agreement up front at the management team level, you save yourself a whole lot of work later on by avoiding reversals of decisions, back-and-forth arguments, and requirements that somebody wants to slip in after the product plan has been signed off on.
— Jacques Murphy, Product Management Challenges
ProductManagementChallenges.com
[/private]