“Communication” by Joan M. Mas. See below for image credit.
Effective Communication is Challenging
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:
- Developers being poorly motivated, or having a bad attitude about what you want them to build
- Getting the “wrong thing” from the developers – the feature they deliver is not what you had in mind
- And other forms of miscommunication between PM and dev
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 Requirements Are Letting The Developers Down
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.
Requirements and Mastery, autonomy, and purpose
What do mastery, autonomy, and purpose mean for software developers?
- Mastery should be clear – it means that they are in control of their tools, and expert at using them. These tools are programming languages, of course, but also the engineering disciplines of technical design, architecture, problem-solving, and so on.
- Autonomy is a little less clear. What does it mean for a developer – part of an engineering team, amongst other engineering teams, in a big company – to be autonomous? It means that they get to apply their mastery to solve problems in their own way, using their own expert skills. This explains why engineers are often so frustrated when product managers go beyond the “Why?” and “What?” in their requirements and start specifying designs.
- Purpose is often the big problem for developers. We product managers have a good sense of our purpose. We want to help our customers have better, more successful lives and to achieve their business and personal goals. But if we’re not careful, it’s easy to lose the connection to this ultimate goal by the time a requirement gets to an engineer. Often the engineer is given a document that describes something the PM wants, but with no connection to the way it makes the customer’s life better. This significantly dilutes any sense of purpose that the engineer has, and consequently reduces their motivation to do it.
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.
What can we do?
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:
- Independent
- Negotiable
- Valuable
- Estimatable
- Small
- Testable
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!
The VALUABLE template
My VALUABLE template – yes, “VALUABLE” is the name of the template! – is focused on helping developers understand the value they are creating with their solution. Developers are humans and are motivated by solving real problems for real customers, so the VALUABLE template makes this explicit.
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:
- V is for Valuable (yes, it’s a recursive acronym)
- The feature solves an urgent, pervasive problem for a real market who will pay for the solution
- A is for Aligned
- The feature is Aligned with company strategy and priorities
- L is for Loved
- The feature will be Loved by customers because it will do what they need and not cause them more problems
- U is for Understood
- The requirement is Understood the same way by engineering and product management
- A is for Acceptance tests
- The requirement has clear acceptance criteria so it’s easy to tell if the implementation delivers the desired value.
- B is for Bounded
- The development team and the product management organization both agree that this feature is “realistically achievable” by the current team. Note this doesn’t mean that we know exactly how long it will take or when it will be delivered. Just that we are confident we can deliver it soon enough for it to make a difference.
- L is for Leverages
- The feature Leverages our competencies and unique abilities, both technical and business
- And the final E is for Expected usage
- The requirement includes explicit and testable usage Expectations. These can be used to instrument the feature, and to monitor its usage by customers once deployed
Contrast with INVEST
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.”
What’s missing from VALUABLE?
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.
Using the template
How would I use this in practice? There are a few ways to use it.
- You can use the template as the table of contents for your requirements.
- You can check your requirements against the template as an acceptance test. For example, the Understood component reminds you that product management and development need to be on the same page. When both parties are communicating clearly, it reduces issues with the handoff of requirements.
Closing
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)
