Some time ago, as part of a former employer’s software product development team, Mark Naylor was handed a set of requirements by one of the firm’s product managers. It included all the basic information that Market Requirements Documents normally provide – objectives, requirements, timelines and so on – but it didn’t stop there. 

The manager, who had previous experience in developing user interface, went on to list the full design requirements, including encoded algorithms and a detailed user interface complete with buttons, boxes, pictures, and mockups. There was hardly anything left for Development to do. That wasn’t a good idea.

“Please don’t give me requirements where you’ve designed it and implemented it,” he urged the product strategists attending a February 25 Pittsburgh Product Strategy Network roundtable. “Give me a broad description. Give me an open-ended goal. I have the background. Let my team use their creativity and their product knowledge to architect the solution. But don’t design it, don’t give us algorithms. That really offends. That’s what we’re being paid for,” he reminded them. “Trust the developers. They know their tools. They know the space you’re in. They know the goal of the company. Give them an implementation-free description and let them find the solution.” 

The significance of building a strong, professional, and mutually trusting relationship between Product Management/Marketing and Development teams is a lesson that Naylor, now VP of Product Development for DigiBrix, acquired during his 24 years as a technology product manager with companies ranging from giants like IBM and DEC to startups such as FreeMarkets and Wisdom Technologies. At one time or another, he has worked on all sides of the technology product process – Marketing, Development, and Product Management. That has given him an appreciation for how those functions can communicate effectively with one another, as well as their importance to successfully introducing new technology products. 

Clear communications
Good communication with Development begins with clearly conveying the specific requirements for an upcoming product release – and providing it in the context of the customer’s business problem that product is supposed to address, Naylor pointed out. That includes setting priorities for each aspect of the solution, understanding how each requirement would help the customer succeed, visualizing exactly who its users would be and just how the product’s features were to be used in practice. 
Equally important, Development team members need to have a clear understanding of their own company’s strategy, its product roadmap, and how each new product release or feature fits into that roadmap. Without that foundation of understanding, conflicts can occur, as Naylor recalled in one case where the Development Team refused to implement a request from the company’s product managers. 

“We had a request to put in a feature for a business partner who was licensing our technology, and this developer just didn’t think this feature should be given. So he refused to implement. He said if you give them this feature, they’re going to take sales away from us. It was clear example of not understanding the Big Picture,” Naylor said. “There was a failure to communicate from the product manager to the Development team. They just didn’t understand it. So we sat down and worked through it, but it was not a fun day. It was an example of our being in the same boat but not rowing the same direction.

Other lapses and communication failures are also fairly common. Just as it can be a mistake to provide too much detail, it is equally misguided to provide too little. One common blunder is to refrain from saying anything until everything has been approved. “If there’s any way for you to stage the delivery of the MRD, do that,” he advised. “Don’t wait until you have a complete MRD that could be a 200-page tome that you walk over to Development and say ‘here it is.’ They can’t wait that long. There may be pages you are still working on, but 90 percent of it could be started early. Some things take longer to work on than others. If you give it to them in pieces and sections, there’s more chance for parallelism. So give it out in pieces and you’ll have more flexibility.” 

Don’t jerk Development around
By placing a premium on predictable scheduling, a Development team can do itself a great favor, even if Product Management is unhappy with the resulting schedule, Naylor said. “The flip side is that Product Management shall not yank the Development team around; you’ve got to give the Development team a list of requirements, a roadmap, and you’ve got to stick with it.” Sometimes a customer will change their requirements overnight, he acknowledged. “But in Product Management, you can’t do that to the Development team. You’ve got to do your homework, provide a roadmap, have your themes, pick a release, and go with it. Sure, things change. But if you do this every week, it’s not going to help the relationship between Development and Product Management. 

“It gets back to building a relationship based on trust. Trust that Development knows what they’re doing. Development should trust that Product Management knows what they’re doing – everybody’s doing their job working together and rowing in the same direction.”

One way to pull in the same direction involves bringing engineers onto customer sites. It is an approach that has proved to be an eye-opening experience for Product Management, Marketing and Development professionals alike. Solutions 21 strategist Jennifer Ireland, formerly of ServiceWare and Bachrach Instruments, shared one particularly serendipitous on-site discovery. 

“We would take some of the engineers out with us into the field and spend the day with our customers and prospects. And one of the things we found is that a lot of technicians were losing their instruments because the Bachrach instruments we put out were all gray, and the boiler room floors were gray, too. When we were there someone said ‘I lose this thing all the time because I can’t find it.’ So we came out with fluorescent green instruments. But we would never have picked up on it without being in the field with them,” she said. “We do focus groups upfront and put a couple of the lead engineers into it, so they actually hear from the customer; it wasn’t just coming from us. They get so excited when they hear it from the customer that they take ownership of it.” 

Back channels
Although negotiation between Product Management and Development teams are routine, it’s important to make sure that market requirements documents – which are called by different names in different organizations – follow established channels. That isn’t always easy. “As product manager, I learned that when Development was working on something, there were always backdoors,” Naylor recalled. “There’s an sales engineer who knows a developer; there’s a sales rep that knows a developer; information comes in through back channels.”

To help control the potential chaos, Naylor urged managers to set priorities. “When I was in product management and giving feature-level requirements to the development team, we assigned priorities to those features. The scheme I used was Priority Zero, which was a must-have – the minimum set of features we had to have to be successful with this release. Then there’s Priority One, which was desirable. The assumption was that they would be in the release when it shipped, but if there was a hiccup in the schedule, then Priority One features could be taken out of this release. Priority Two features were ‘if time permits,’ and it rarely did in my experience. 

“But there’s another priority, I called Priority Nine, which is a feature that came in through the back door. Priority Nine means ‘don’t even think about it,’ ” Naylor said. “If I find you’re working on that, you’re going to get called on the carpet; I don’t want to see any time logged against that feature.” 

Tips and Techniques
Roundtable participants from Black Box, Medrad, NOMOS, TimeSys, Akustica, Desantage, CoManage, Acusis, and Innovation Works offered these useful practices, too:

• Give the development team market requirements that are implementation-free; let them use their creativity to meet them and the goals
  

• Use a Standing Requirements document to convey requirements - such as performance and security - that apply to every product and product release
  

• Develop use scenarios, which are mini-vignettes of how the product is used, to help identify core issues and features that are common to many products and materials.
  

• When developing use cases, look at a Day-in-the-Life of the product itself and its environments, and prepare use cases for the non-human ‘users.’
  

• Include in the MRD the pricing model, demo requirements, and industry standards or regulations the product needs to meet.
  

• Have the technical writers review and edit the market requirements and work on creating the specifications.
  

• Have your lead developers prepare a 2-3 page functional abstract of what they’re going to build and the timeline for building it.
  

• Consider creating three sequential documents: Market Assessment (or Business Case), a Market Requirements Document, and a Product Requirements Specification.
  

• Prepare a concept product datasheet and ask your prospective customers “Is there anything on this datasheet that would prevent you from buying this product?”
  

• Be careful with outsourcing development because details formerly taken for granted now have to be spelled out precisely.

ABOUT THE AUTHOR:
Peter Longini is a contributing writer for the Pittsburgh Product Strategy Network. Peter is a former professor of communication research at the University of Pittsburgh and professor of TV-Radio at Brooklyn College, CUNY. During the 1980s, he was an executive speechwriter at PPG Industries in Pittsburgh. Since 1992, he has been the principal of Peter Longini Communications, an editorial services company in Wexford, PA whose clients include various publications, public sector agencies, nonprofit organizations and corporations. In January 2003, Dr. Longini became an adjunct faculty member of New York University and Director of Communications for Cranberry Township, Pennsylvania. He can be reached at This e-mail address is being protected from spam bots, you need JavaScript enabled to view it