by Mark Kromer

Just a quick post today about the value of product managers to get out of your chair. There is a limit to the value and analysis that you can expect to glean from reading analysts reviews, enhancement requests and writing BRDs.

Walk around to talk with your sales department, support team, consulting team and anyone else who interacts with your products and your customers. I find that conversations can lea dyou to new, undiscovered, or clarified requirements and enhancements that made it into the bug or ER system but were not classified properly due to a lack of proper analysis. Trust your own ability to anlayze, communicate and draw information out of stakeholders.

Walk around OUT of the office to meet your customers. Tag along to customer visits with parnters or internal sales. Customers, partners and sales will appreciate having someone from the strategy or product management team to provide gravitas to the virtual team. And you’ll learn a TON about how customers want to and will use your products. The use cases, scenarios and user profiles you’ll collect from this effort will more than provide payback from the cost of the travel.

by Mark Kromer

I am going to give you my take on some techniques in writing solid, true business requirements and how to keep functional requirements and design out of BRDs. In other words, how to answer the question “Why?” instead of “How?”

This is my approach: I look at requirements engineering and analysis from a top-down approach. Start with understanding the broad general landscape of the business problems you are trying to solve. This is more than just understanding your customers. You need to understand what is driving their business. Why are they successful and why are they experiencing failure. This analysis and research has proven to be critical in requirements analysis. Map this out in business process designs, validate it with customers, internally and with analysts.

I have found this helps me to not get too heads-down too early in the silo’d or minute problems. I’m a recovering software developer. I spent years coding too soon, too often and too rogue. The broad-view, understanding the business will help you to answer “Why?” Leave the “How?” for the analysts, developers and engineers.

Here is an example: I have seen a requirement in a BRD such as this: “The system shall have a link in the UI to an instant messenger”. This is a functional requirement. A suggestion would be to first step back and write an sssociated use case. Something like this:

The engineering group has trouble completing their configuration management on time and within the quality measures set forth by the quality control team. In a geographically dispersed team, the ability to communicate effectively is a major driver for these problems.

Now you can write requirements from that scenario that answer the “Why” question. A sample requirement would then be: “The system shall enable a geographically dispersed team to communicate quickly and easily”.

I have collected our TechProdo info on our Requirements forum and I talk about these approaches here and here. Also, for a bit more on diagramming and designing the customer business processes and modelling business systems, go to this webinar.

Now, for other takes on this very popular issue among product managers, I suggest visiting Pragmatic Marketing, 280 Group or Google solid requirements, business requirements, etc. There are many, many other takes on this topic.