Resources > Articles

7 Tips for Highly Successful Requirements Management

Post Author
  • John Milburn is CEO of Practical Growth Strategies LLC, where he and his team help companies to apply and implement market-driven principles. Prior to this, he was an instructor at Pragmatic Institute and has held executive and individual contributor roles in development, sales, and product management from startups to Fortune 100 companies.

7 Tips for Highly Successful Requirements Management

Over the years, I’ve had the privilege of working with product and development professionals from around the globe. All have been highly motivated to succeed—and to have their company be successful and profitable. However, there is a critical juncture in every product-development process where many stumble: the handoff of the requirements to the development team. Here are seven tips to help make your next project more successful.

1. Build a Business Plan and Keep It Up to Date

As companies move to new development methods, they often feel that a detailed business plan is no longer necessary or as important. But “we’ll be done when we’re done” will not usually pass muster with leadership or get the funding your project requires. Yes, you should encourage flexibility to roll out products without constraining creativity. But you need to articulate the business goals of every project based on some initial expectations (date, cost, revenue, etc.).

Be mindful that priorities and market conditions will change mid-project, budgets will get cut, key people may leave the project and development may over- or under-commit. The initial business plan will justify the investment at the start of the project. However, you should also keep it updated throughout the project, including the latest internal and external changes, and communicate the business impacts to management.

There are cases where the project no longer makes business sense to complete. For example, if you missed the market window or the competition just made the entire project irrelevant. If you don’t have an up-to-date business plan, how do you make that call?

2. Give Designers What They Need: Context About the Market

To do their jobs and apply their innovative talents, designers need context around the description of the problem. When shifting from a traditional requirements approach (“The product shall …”) to a market- or user-based approach, many think that requirements are supposed to be written at a very high level. “The network operator has a problem if the network is overloaded.” But how does he get notified or want to be notified? How quickly does he need to be notified? Why does he need to be notified? What does it mean that the “network is overloaded”? Why does he care? How often does this occur? It’s not about writing requirements at a higher level; it’s about providing more context about the problem. Then the designer can own defining high-performing, well-architected solutions that provide a pleasing customer experience.

3. Remember that Development Is the Customer for Requirements

I once worked with a company that was debating whether their market requirements document (MRD) was to be written in Word or PowerPoint. I asked them, “How does development want to receive it?” Their answer: “We haven’t asked.” A requirement, or a group of them delivered in a backlog or MRD, is intended to build a bridge for communicating with your development team. They are the customer for the artifact. How do they want to receive them? In what syntax? What tools will they use? The product team owns the overall success of the product in the market, but the development team provides the technology solution to make that happen. Provide context, problems to solve and the acceptance criteria in the way that they can best receive and use them.

4. Deliver Requirements in an Iterative fashion; Don’t just Throw Over the Wall

Continually communicate the requirements with the team that will be defining and delivering the product. Don’t assume that the development team will read and understand all the requirements. Though this takes time, it will save huge effort in the long run. There are so many variables involved that product management must provide a forum for all to discuss them. What about this? And that? Who? How often? Why is this higher priority? What if we don’t do this one? Do you really mean that? What about all of our technical debt? These discussions need to be had at the beginning and throughout the project. Having the right people hashing through the detailed requirements, posing and discussing questions and getting a common understanding of the problems will not only encourage better teaming, but also allow you to deliver more innovative products in a shorter amount of time.

5. Write as Content, Not Syntax

A regular syntax today for requirements is the user story format. This has become very popular with the movement to iterative (Agile, Scrum, Lean, etc.) development techniques. Generally, user stories come in the following form: “As a role, I want to do something, so that I can accomplish a goal or objective.” In many cases, the user story syntax may be used to express a market-based requirement. But just because the requirement is written using the syntax doesn’t mean it’s a well-written requirement. “As a lab technician, I want to have a red ‘trouble’ button on my screen, so that I can do my job” is a poorly written requirement—yet it conforms to the user story syntax.

6. Focus on What, Not How

Requirements are “market requirements” not “product requirements.” The product team’s primary responsibility with development is to provide problems to be solved in the market—not product specifications. Too often, either out of ignorance or the desire to impose one’s technical opinion, requirements are written that prescribe how to build the product and not what the market problem is. For every requirement, ask yourself: Have I stepped over the line and given development a how instead of a what?

7. Have Some Fun and Make It a Team Sport

Lastly, defining and delivering products is what technology companies do. It should not be drudgery or viewed as a battle between the product team and development. Encourage some creativity in the process and have a little fun.

Just because companies have done away with sponsored beer blasts doesn’t mean we can’t go to a park or bar and have a weekly group happy hour. Give out awards for the most creative solutions to gnarly problems. Celebrate a release with music and cake.

Incorporate these seven tips in your next and all future projects, and you will find that your projects will run much more smoothly and deliver better outcomes overall.

Author

  • John Milburn is CEO of Practical Growth Strategies LLC, where he and his team help companies to apply and implement market-driven principles. Prior to this, he was an instructor at Pragmatic Institute and has held executive and individual contributor roles in development, sales, and product management from startups to Fortune 100 companies.

Author:

Other Resources in this Series

Most Recent

Article

[Comprehensive Guide] Product Owner vs Product Manager

Learn how to separate the roles of product owner and product manager on Agile teams and uncover some common challenges with confusing these roles. Including a short primer on the Agile revolution.
Article

Use Scenarios are Stories That Provide Context

The problem with today’s user stories is that they aren’t interesting. And they aren’t stories. The solution is use scenarios. It’s a narrative. It explains the problem in the form of a real-life story.
Article

Benefits of Bundle Pricing

Bundle pricing is simply a strategy where services or products are packaged together for one (often reduced) price rather than priced separately. This article covers some benefits of bundle pricing followed by a system for getting started.
Article

A Quick Guide to Value-Based Pricing

Value-based pricing begins with knowing the customer’s willingness to pay based on the perceived value of your product. You can charge less than a customer’s willingness to pay, and they feel like they’ve received an
Article

What Is Captive Product Pricing 

If you’re looking for a simple answer, it’s this: captive product pricing is when consumers make a one-time purchase (usually a lower-priced core product) but are required to purchase accessories for the main product to

OTHER ArticleS

Article

[Comprehensive Guide] Product Owner vs Product Manager

Learn how to separate the roles of product owner and product manager on Agile teams and uncover some common challenges with confusing these roles. Including a short primer on the Agile revolution.
Article

Use Scenarios are Stories That Provide Context

The problem with today’s user stories is that they aren’t interesting. And they aren’t stories. The solution is use scenarios. It’s a narrative. It explains the problem in the form of a real-life story.

Sign up to stay up to date on the latest industry best practices.

Sign up to received invites to upcoming webinars, updates on our recent podcast episodes and the latest on industry best practices.

Subscribe

Subscribe

Training on Your Schedule

Fill out the form today and our sales team will help you schedule your private Pragmatic training today.

First Name*
Last Name*
Email Address*
Phone
Company
Job Title
Location
How can we help you?
Preferred method of contact
Privacy Policy*
Map Your Message to Its Audience with the Communication Compass
Map Your Message to Its Audience with the Communication Compass
Ensure your message hits the mark. This eBook helps you visually map communication styles so you can tailor your design story to a stakeholder or business partner.

Download Ebook

Demystifying Data Projects: A Guide for Business Leaders
While data science is a competitive advantage, data isn’t magic. Learn how to make magic happen by partnering more effectively with data professionals. This eBook delves into types of data projects, sample questions, tools and methods, key points and cautions—so stakeholders like you can initiate data projects with real business impact.

Download Ebook

Define Ebook Thumbnail
What’s the difference between a successful data analysis project and one that falls flat? 

Before you begin working with the data, you need to understand what you’re solving for. Gathering context and aligning around goals with your stakeholders from the outset will help you avoid disconnects and deliver actionable insights. Discover the most vital questions to ask before embarking on a data analysis project in our in-depth guide, “Define: Laying the Foundation for Successful Data Analysis.”

Download Ebook

Download Now