If you know that building your product requirements document communication strategy is just as important as the contents of your document, then you my fine friend, are on your way to being the consummate product manager.
If you are little less wise, remember that although you think you only start sharing product requirements document when it is finished, you are missing an opportunity to leverage it to get buy-in as you build it out. Just like you need to know how to use your product roadmap as a communication tool, the same can be said for your product requirements document. You need to understand how to leverage the power of social conformity to get your job done, so this is what we are going to show you how to do.
And remember, just like the product roadmap, it needs to be owned by someone. And that someone is you!!!
Step 1: Start Private
You might think the time to start sharing your product requirements document is when the first draft is done, but that is amateur hour thinking.
Although I am all for transparency (sometimes too much so), I’ve learned the hard way that no one wants to see your rough work unless you are in a Grade 5 math class.
Write your first few product requirements document drafts in private and if you are using a product management tool or project management tool to do so, make sure you have shut off all automated updating functionality and the document is in draft format, otherwise you could be spamming your entire department with every updated period and spelling correction.
This first draft is to be based on all the work you did validating the product hypothesis and to a certain extent, represents that operationalization of the product roadmap. If you need some “inspiration” laying out the document, feel free to “borrow” our product requirements document sample.
Publicly, you should be engaging with your colleagues who are going to be involved in building this product, not because you actually care what they think, but rather you want them to “think” you care.
Tech workers have a habit of being
entitled stubborn (and I am not talking about protesting things like workplace diversity and sexual harassment) when it comes to what they work on, so this is your opportunity to co-op them into the mission. This will make life a lot easier when you present the finish document as you will have the time to engage personally with people whose input got left on the editing room floor.
Step 2: Share It With Those You Need
You’ve often heard that being a successful product manager requires having a skill for exercising soft power as the reality is that you technically do not control the resources needed to execute on your product requirements.
So this is where you have to get a bit Machiavellian, and I said a bit, not full scale Adam Neumann (well, who am I to really talk here)…
The first group of people you want to share the document with are people like other product managers and the technology leads, head designers and the relevant product marketing manager. People who are going to be in charge of getting the features from your requirements document into development and pushed live, so you need the to actively support your vision and build what you have laid out in such a way that it achieves your objectives. After the first draft is done, a lot of their feedback will end up in the “Outstanding Issues” portion of the document.
Remember that everything inside your organization is really a battle for resources.there are always going to be competing priorities, and you can be sure as hell there is always going to be someone who acts like a dictator (notice you can’t spell dictator without dic), and it shouldn’t be you. A good way to set people on edge is by trying to do their job. Make your life easier by doing less work. You will have fewer enemies and less stress.
Rather, you should be the person who capitalizes on your colleagues natural urges to undermine the dictator. Do this by positioning yourself as the thoughtful and considerate leader people want to work with by listening and addressing their feedback collaboratively. Ensure your teammates feel some ownership in the solution to the problems you found. Additionally this is the opportunity to:
- Firm up the key success metrics.
- Ensure the solution is feasible from both a technical and timeline point of view.
Step 3: Share It Broadly
Now is the time to whip up a frenzy of support for your product requirements document.
Start by sharing with the teams who will be working on it. Remember to actively listen to feedback as it will increase the chance of people buying in.
In the event you get asked to present at a company wide event, do not be a glory hound. At this stage your produce requirements document communication strategy should be a group affair.
Leverage the power of social conformity by letting members of your inner circle who have given you relevant input present relevant sections of the requirements document. This works because it:
- Increases the buy-in of those presenting as they have the opportunity to increase their profile within the company.
- Gives the impression to the wider masses that there is already a large amount of group buy-in, minimizing the chance they will stand in the way of its implementation.
Remember, the purpose of this presentation is to show the wider audience that everyone is on board with what you’re doing and why. Remember to respond to public questions in such a way that it puts people at ease, rather than a confrontational show down of opinion and ego.