Product managers tell me – and the people managing product managers tell me – that one of their biggest challenges is communicating with the development team. People complain about:
Product management has all the responsibility, and none of the authority. If communication problems are happening, it’s at least partly product management’s fault. At a minimum, you’re contributing to these problems. And no matter whose fault it is, product management has to fix the problems.
In this post I give you a powerful tool for doing that – fixing the problem. And be sure to check out the infographic that goes along with this post.
Our primary mechanism for communicating with development – aside from having conversations with them, which you’re doing, right? – is via some variety of “product requirements document” – the written-down “Why?” and “What?” of a new feature or new capability in your product. This might be a document, or a wiki page, or even a post-it note.
I’ll use the term “requirement” in this article for this concept. But you might call these “features” or “feature specifications.” Or “Epics” or “User Stories.” (All these terms have problems, but that’s a topic for a different article.) Let’s just call them requirements or “product requirements” for now. I hope we can all basically agree on what that means, and nod our heads.
Product requirements are our “stock in trade” as product managers. But chances are we are not doing as good a job of writing and communicating these as we should. Or as we think we are. Resulting in the problems I mentioned above.
Let’s think about developers as people for a minute. Like all people, developers are motivated by what Dan Pink, in his awesome book Drive, calls the components of Motivation 3.0 – mastery, autonomy, and purpose. (The handy acronym MAP will help you remember these.) Of course, we PMs are driven by the same things.
What do mastery, autonomy, and purpose mean for software developers?
Summing up, engineers, being humans, are motivated by solving important problems – using their mastery of problem solving, architecture, design, and programming – in new creative ways – using their autonomy – so that they can improve customers’ lives – achieving a meaningful purpose.
If your requirements are not meeting the standard that helps them do that, they will be less motivated.
Part of the answer is use a good template. Templates are cognitive aids. They make sure we address all the necessary topics.
I’ve written in the past about the value of templates for our cognitive resource management. You might remember the “Impact Areas” template for product requirements or product feature specifications I described in the past.
There are a handful of common templates for writing requirements and related things. The best known one is INVEST – which is an acronym for:
But I’ve never felt that the INVEST acronym spoke to me as a person who is trying to solve problems for customers with my products. INVEST loses focus on the market problem, and instead takes too many implementation considerations into account.
I want to make sure my requirements addressed these issues head on. For example, the customer’s problem, the thing we’re trying to solve, needs to have pride of place. We must make sure that the development organization and product management are on the same page – that’s a meta-requirement. And the requirement is a lot more valuable if it includes acceptance tests. Developers, QA, and product management can quickly understand if the feature really solves the problem.
To capture all these insights, and a few more, I created a new “requirements” template. This template will enable you to communicate more effectively with the development team. And it has a great acronym!
With VALUABLE, the market problem and the focus on the customer drive everything. And the implementation decisions are left to the developers and designers.
The “VALUABLE” acronym stands for:
The VALUABLE template addresses the goals of writing requirements from a vastly different place than INVEST.
While INVEST does have a V for valuable, it’s mixed in with other terms like Independent and Small and Testable. These are much more implementation-focused, and less appropriate for product requirements, per se.
VALUABLE is much more explicitly about customer value, about strategic alignment, and about coming to a common understanding with development. My template leaves out Independent and Negotiable, which are not necessary, and Small, which most interesting things are NOT. And it covers some things INVEST doesn’t – such as the “Expected use,” “Alignment with strategy,” and “Leveraging our competencies.”
No one template can contain everything, and some things are missing from this one. For example, it doesn’t explicitly mention that the market problem mentioned under V has been validated (although it is implied). And it doesn’t include my Impact Areas template – the I just didn’t fit in the acronym!
By design the template doesn’t mention anything related to a technical specification. I’ve explained why that can be demotivating for developers. If you think about the purpose of a requirement, to capture the Why? and What? of a feature, and not the How?, it makes sense. But there’s nothing limiting you from putting technical guidance into the requirement.
How would I use this in practice? There are a few ways to use it.
I’d like to hear your feedback on this approach to writing better requirements that result in better deliveries from your development team. Download the infographic that’s perfect for hanging on the wall of your cube. Let me know via the comments if you think this can help you and your organization to be more effective.
Image Credit: “Communication” by Joan M. Mas. Copyright (c) 2007 Joan M. Mas, Attribution-NonCommercial 2.0 Generic (CC BY-NC 2.0)
Your host and author, Nils Davis, is a long-time product manager, consultant, trainer, and coach. He is the author of The Secret Product Manager Handbook, many blog posts, a series of video trainings on product management, and the occasional grilled pizza.
Please log in again. The login page will open in a new tab. After logging in you can close it and return to this page.