Interpretations – Product manager’s achilles heel

One of the most important skills to have as a product manager is great communication. Most people understand this skill as being a “People Person”, someone with great interpersonal skills. Although this is true, the real bread and butter of product management lies in sending clear definitions and specs to the developers. Sure, they can like you and you can like them but that will not create a better product, it will just make communicating easier.

The way to make sure the product is focused on the business goals and features that affect the bottom line is to ensure that the business requirements meet the technological solution. How do you do this? Deliver a spec with limited place for interpretation.

In theory, product managers meet the “demand”- sometimes we even create it. In a way, everything is in our heads, but our job is put everything in writing, writing that is clear. This means that everything starts in our imagination. We can use creative tools (mockups, wireframes, and other user stories) to help realize our imaginations. Let’s simplify this process: we meet the customer. We understand his needs. We convert his needs into technology.

Now, Imagination by definition is “the ability to form new images and sensations in the mind that are not perceived through senses such as sight, hearing, or other senses.”  I think its more fitting to imagine a better definition of “Imagination”, one that helps to better define our process as product managers. Perhaps there are stages to this imagination, and if there are, then the stage right before imagination becomes defined requires special attention. In order to meet the business goals, specifications need to be clear enough for developers and only when this is met do we create real value.

Now – What is the “KPI” for “clear enough” to developers – In my experience it is to minimize room for interpretation. When a developer/TL gets a feature you want to make sure that the dish will taste exactly how the chef described it, not a second over or undercooked. In product development, we create the recipes, developers, as “chefs” then take our recipes and make delicious dishes out of them. Can you tell I am hungry while writing this?

So, How do we minimise interpretations? Share. Yup, it’s that simple. Share your thoughts and be open to comments (basic product management). Once you share – the backfire will help you perfect your product – the questions you will be asked will represent the”unclear” areas – open to interpretation – things that need to be perfected.

Who should you talk to? All of the stakeholders that would care about this feature. If they are happy, you are happy. Share it with the developers, they might see things that you didn’t think about. Share it with your clients – if in house, go over the process until you are confident in the solution. Share it with the QA – they will stamp the product, in their heads (at least the good ones) are all the edge cases that you did not think about, QA needs to know your acceptance criteria and what are core values is in the feature.

To make the process efficient and not to waste too much time, set up a review meeting and come prepared – show your work and hear comments. Make sure all the stakeholders are on board and when the meeting is over – all of them are on the same page.

Remember the cold rule of design flaws – the sooner you find the flaw, the less time it will take to fix it. We are responsible to find it as soon as we can and we do so by limiting the interpretation. So now I ask you, did this post leave room for interpretation?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s