I
tweeted about this yesterday and immediately got a bunch of mail asking what I meant by "what's unwritten is dangerous".
In any software development or marketing organization, there is certain information that gets written down. We write down requirements, we write down schedules. We have written evidence of market research (if you've accepted that your opinion, while interesting, is irrelevant) and written examples of personas. We have piles of collateral, press releases, sales prompters and call notes. Lots of words.
The first part of my tweet related to the importance of making "taking inventory" the first "real" thing you do on the job. What you're looking to do is document what has been written down in the organization with regards to the product management process. These "artifacts" point to evidence of processes you haven't experienced and whose existence you can't prove.
From an attitude perspective, it is essential you do this without judgment. Just ask where things are, find them, and move on. No "ohmygawdIcan'tbelieveyouguysdon'thavearoadmap" comments. Really. In the words of the immortal Patrick Swayze in Roadhouse, "I want you to be nice until it's time to not be nice".
In this day and age it seems counter-intuitive to print out copies of the stuff you find that is relevant to product management, but I recommend you do. Put it in a binder with appropriate labels. This becomes your definitive record of "knowns". For knowns that are huge, print out the summary page. For knowns that have lots of history, just document the depth of that history.
Note that I'm not asking you to identify "how things are done" - just "what is written down". This is an important distinction I'll explain in a bit. And don't worry about consistency among the documents - all you care about is whether they exist or not and where they exist.
An easy way to ask for the stuff you need is to run down a list of items. By means of an analogy, you've been in a shop that's taking inventory. Workers go shelf to shelf and count things, then write down those counts on slips of paper attached to the shelf. Your job is to go shelf by shelf - business process by business process - and make sure that you can see what's on that shelf.
Once you've got that binder put together, take a look and see where the holes are. For example, and in no specific order:
- Is there documented evidence of the vision, mission and values of the organization?
- Is there a strategy document for each product?
- Are there documented goals for the year? Previous years?
- Is there evidence of whether those goals were met?
- Is there a roadmap for every product?
- Do you see market sizing data?
- Do you have evidence of why a product was built?
- Do you see market share data? Sales history?
- Is there a record of development and launch history? (I'll eat my hat if you don't find this. It's the single-most common artifact in the software development world.)
- Can you find support metrics? Defect tracking?
- Can you find sales data: volumes, dollars and related funnel metrics with associated math?
- Is there documented competitive intelligence, including how they package and price?
- Are there documented requirements, whether that's in a RDD or as an agile backlog, with associated sources?
- Are there user and buyer persona definitions?
Give this process a week at most. You can do it while you're meeting people, learning about products and completing your healthcare enrollment forms. Keep track of who you talk to.
When you are complete, you've accomplished three things:
1. You have demonstrated respect for and an interest in the history of the product and the company
You are the new guy or gal on the block. Prior to your arrival, the organization built, released, marketed and sold products. There are most likely customers. The exercise of looking back demonstrates that you want to understand the world you are now living in through the lens of past. . .as documented by evidence. Plus you've got fresh eyes, and that's the ideal time to "look back"; allow too much time to elapse and you'll have consumed the KoolAid and believe whatever version of history is official (e.g., Oceania Has Always Been at War With Eurasia).
2. You have established a reputation for being thoughtful about process
The reason you are there as a product manager is build products people will want to buy, and to do so in a way that is consistent, efficient, and effective. By taking an inventory of specific product artifacts, you demonstrate your expertise in your craft because you know the importance of taking a whole-picture view of what it takes to build, release, market and sell software.
3. You have not explicitly threatened anyone
Your job is not to walk around and ask "why don't you have such and such", your job is simply to walk around and find out if they exist or not, and to take a look at them to confirm they do.
In the process you will get lots of stories about why such-and-such a document doesn't exist, or why it used to but doesn't anymore - please resist the urge to do anything other than nod and move on to the next item. By taking an evidence-based approach to this inventory, you will figure out which departments and people are playing things fast and loose when it comes to process, but that's not important now.
So you've got your inventory of process artifacts. What's next? And what does this have to do with what's not written down being dangerous?
What's not written down exerts pressure on what is written down and diminishes its value. Here's an example:
A competitor releases a new version of their website that highlights a range of functional capabilities that the company's product doesn't have and which the company didn't see coming. The klaxons go off up in the executive suite, the previous product manager falls through the trapdoor in the floor down the chute to the pit of alligators, development scrambles to build the three or four features sales says are "critical", and a new version goes to market.
Then you get hired.
If your inventory revealed a gap in requirements and persona definition documentation, you could conclude the incumbent PM was the weak link, but. . .
If your inventory revealed a gap in roadmap documentation, you could conclude that the product manager's manager was the weak link, but. . .
If your inventory revealed a gap in strategy documentation, accompanied by a lack of sales process metrics, then you could conclude that senior management was the weak link, but. . .
If your inventory revealed a gap in market intelligence (e.g., analyst data, research, customer surveys, sales loss reports, etc) then no matter how well the other pieces worked or didn't work, the organization was flying blind and building things they wanted to build, unless. . .
If your inventory revealed a gap in concept testing (perhaps due to the presence of an internal thought-leader/savant from whom brilliance and insight flowed like water and whose ideas directed development), then you could conclude that development management was the weak link. . .and so forth and so on.
None of this is to say that the organization didn't think they had requirements, roadmaps, market intelligence, validated concepts or a coherent strategy. Every company will claim to have these.
And now we get to the danger. Whatever is not written down can change without warning, can't survive a change in personnel, can't stand up to objective analysis, and can't be shared or integrated into other processes in a repeatable way.
If you find substantial holes in documentation, you may find that the trail leads back to an individual who just "knows" what the customer wants, or who the customer is, or how many customers there are, or who the competition is, or how best to communicate with the marketplace, or the right price point.
How that individual comes to know isn't documented - all you can tell is that one of the elements of the product management process is based on a subjective, unwritten "known". Efforts to obtain evidence that contributes to the known can be met with "why are you looking at that, we already know it to be true". You may find that you can't challenge this individual to document the knowns they own; there are many reasons for this, some good (they're a savant who makes product magic) and some bad (they are a C-player who feels threatened by you, or someone who believes control of information equals power).
When taking an inventory of the evidence an organization uses to manage processes and make decisions, the danger of undocumented elements is that they introduce wild-cards that introduce delays, at best, or can steer you in the wrong direction, at worst.
So by making one of your first tasks on the job a comprehensive inventory of process artifacts, you're gaining immediate insight into how the organization functions. . .and does not function. Armed with that, you can lay out a plan for how you will get things done in the context of what the organization is immediately capable of doing - and set your sights on which of the processes you will work on next.
It also makes for a killer presentation.
