We all live in a World with tradeoffs. When you write a requirements document, is every requirement non-negotiable in order to ship the product? If so, you’ve traded off completeness for time or resources. If you’re like me, time is your biggest enemy, so even if the requirements outline the ideal solution to a problem, there may be willing tradeoffs you’ll make to get a product in six months versus 18 months. Understanding how to drive tradeoff discussions and strike the right balance between conflict and consensus is a vital skill for a Product Manager.
I recently transitioned to a new Executive, and as we were discussing some of the difficulties we were having with Engineering responding in enough detail to requirements, we got to the topic of tradeoffs. As we drilled into the topic, I realized that for all the requirements writing and business cases we were producing in Product Management, Engineering had a planning bottleneck and was having trouble absorbing the requirements. The informal stimulus-response process of working with the Engineering executive to drive Engineering Response Documents (ERDs) to MRDs was no longer working. We needed something higher touch - a formal RACI.
RACI is a great tool, and the best part is that you’re already using it today, even if you don’t know it. RACI stands for Responsible, Accountable, Consult, and Inform. You use RACI to identify and bucket people by their function and level of responsibility to a product, project, or process. A RACI matrix might look like:
Product Foo
| R | A | C | I | |
| Product Requirements | Foo Product Manager | Foo Product Manager | Foo Core Team | Foo Development Team, Operations Mgr., Support Mgr. |
| Manufacturing Plan | Operations Mgr. | Foo Core Team, Design for Manufacturability Engineer | External Vendor, Compliance Testing | VP of Operations, VP of Sales |
| Marketing Plan | Foo Product Marketing Manager | Foo Product Manager, VP of Marketing, Marcomm | Marketing, Sales | Executive Team |
| Support Plan | Support Mgr. | Support | Foo Core Team, Foo Development Team | Company |
| Tradeoff Decisions | Foo Product Manager | Foo Core Team (PM, Architect, Operations Mgr) | Development Team, GUI Designer, Marketing Mgr | Executive Team, Support, Training |
The most important thing about RACI is there can be only one person assigned the role of Responsible. One person can live in multiple boxes. The “Responsible” person is your “one throat to choke” for the given task.
If you ask most companies where the root of their problems are, you’ll get a surprisingly consistent answer: communications. These communications breakdowns come from people either not knowing who they should communicate with, or over-communicating to everyone, which raises the noise level so high that people have trouble sorting the communications that should matter to them from the fluff. Often, different roles have conflicting ideas about who is responsible for a task - which makes it easy to understand why there are breakdowns if you have competing people or teams working on the same deliverables. A good RACI knocks that out and gives you clean delineation of roles - great for a Product Manager, and even better for a Manager or Director of Product Management.
Your RACI should grow in size from left to right. One person for R, several people for A, a group or groups for C, and many groups or the whole company for I. To leverage the power of your RACI to really drive fast/good decision making, you also need the Core Team concept. Every product should have a Core Team. Core Teams weigh tradeoffs in the design and development process and make decisions, looping in Consult resources as required. For example, in my company, we have an Executive who likes to be highly involved in the product’s aesthetics and look/feel (I know…), and we need to effectively engage him without letting his opinions drive the rest of the decision making process. The Core Team must engage this resource to both leverage his expertise and get his buy in so that the Executive Team doesn’t feel the need to dip into the product process and make decisions by fiat. Core Teams must own the tradeoffs - Consult and Inform people may not agree with the tradeoffs you’ve made, but they will understand them if you can defend them with good reason.
Much of what I’ve just described is predefined in many of the Agile processes (Responsible and Accountable at a minimum). There is a little overhead to document your RACI up front, but it will save you time cleaning up messes down the road from people who feel like their input wasn’t considered. Remember - you don’t have to take everyone’s input, but you do have an obligation to either listen to their input, or tell them that for this project they aren’t in the R, A, or C and their input will be welcomed on another project (or not).
{ 3 trackbacks }
{ 0 comments… add one now }