It Is a New Era for Requirements Management (Guest Post by Aha!)

Grace Lee Camoglu is a senior product manager who has worked with numerous software products in various aspects of a product lifecycle. As a product manager, she has worked with Intapp, a leading legal technology provider to law firms and other professional services, and LexisNexis Redwood Analytics (since acquired by Aderant), a business intelligence software provider to law firms. Grace has also spent two years on the "customer" side at Google in its legal department managing its outside counsel. At various points of her career, she has also overseen marketing strategy, partner operations, and technical documentation, all of which enabled her to better understand the various areas that a product manager needs to be aware of when managing a product. Grace has an MBA from the Ross School of Business at the University of Michigan and a BA from Northwestern University.

Author bio: Brian de Haaff seeks business and wilderness adventure. He has been the founder or early employee of six cloud-based software companies and is the CEO of Aha! — the world’s #1 product roadmap software. Sign up for a free trial of Aha! and see why 50,000 users at the world’s leading technology companies trust Aha! to build brilliant product strategy and visual roadmaps. Follow him on Twitter @bdehaaff

I need to admit upfront that the term ” requirements management” invokes a shudder. Every time I hear the phrase I recall horribly complex spreadsheets and tree-based systems with endless pages of stale information.

When I started working as a product manager in the late 1990s, the software we had access to was inordinately cumbersome. Many promises were made, but the reality was that it was more difficult to keep those tools up to date than to maintain my old Excel and Powerpoint files.

Every tool I tried was basically Excel on steroids. And just like steroid users, the end result was rage. So, I always returned to the devil that I knew — Excel and Powerpoint.

That is why we created Aha! in 2013. As the co-founder and CEO, I am humbled that more than 50,000 users at the world’s leading technology companies rely on Aha! for product management — from setting strategic direction to managing requirements at the feature level.

We focused Aha! around creating solutions for our own frustrations as former product managers. Requirements management of the past was based around documenting, reporting, and analyzing the minutiae of what was to be built. The new era of requirements management is about using an open and collaborative process to share what the roadmap plans are, why they matter, and how that work is being prioritized.

Here are three ways that forward-thinking product managers approach requirements:

Take an aerial view

When product managers think of requirements management today, they know that requirements need to be related to high-level business objectives. Twenty years ago, more often than not requirements referred to technical requirements (“the user will click a button and be taken to this page”) and old school PRDs. While intentions were good, these detailed documents added layers of complexity that often stalled progress and stifled unique solutions. Requirements management today means starting high and working low. (And if you can’t do that, you’re not doing it right.)

Make it a team sport

Part of this new era comes down to trusting your expert development team to know how to meet those business objectives and your user experience goals — with whatever technical means they choose. There is no such thing as capturing requirements only to throw them over the wall to your developers. Product managers need to take responsibility for communicating business requirements that are clear, tied to strategy, and actionable. And the good ones do so with conviction.

Stay engaged

Product managers today embrace a “trust, but verify” approach to details. Providing a goal-first context to your team is essential. But so is watching the detail breakdown — and intervening if it becomes clear that the team has gone off track. This means that product managers must stay engaged even after they have defined what they want the team to achieve. Keeping an eye out for hazards requires a seamless link between the product manager’s tool of choice and the development team’s tool of choice. That way, it is easy to keep up to date on how the entire product team is progressing.

Requirements management today is not just about the specifications of what should be built — it is about having a clear view of the “why” “when” and “what” (which are the requirements).

Product managers should be the happiest people in the world. But like anyone, we can quickly get bogged down by needless trivialities and unwieldy tools. The same is true now as it was when I first started building products.

When product managers can rid themselves of the baggage of old-school requirements management and embrace a new approach — starting high and working low, collaborating with others, and staying engaged — they will find a flexible and approachable discipline that adds value and meaning to their work.