Writing a White Paper

Writing a White Paper

I think that most of us have seen white papers before - I know the first time I was exposed to one it was in relation to what amounted to a sales promotion. Basically the company was defending its marketing position through the use of a white paper (I believe it was Forrester or perhaps Gartner, who both seem to write quite a few of them and in general are both fairly well respected in the industry). I believe the original concept behind a white paper was to produce an authoritative research document with the end goal of creating correlations or interpretations of raw data. Historically most of these were used by government (and in particular US government) to identify trends and produce some type of synthesis of the information that would then be used to form recommendations; and often the task would involve the use of university researchers - basically experts in fields that could make sense of the data and then produce a report that could be easier to consume, presumably by governmental branches (note that a lot of this type of research has been given to data scientists who have even more training in looking at trends and anti-trends). I'm not sure about why they are "white" but my conjecture is that it's supposed to mean that the opinions are external and objective; as opposed to regular reports which tend to be subjectively sourced for internal use only.

As I've already indicated, most of the white papers I've seen up until the last 10 years or so were put together by companies that specialize in producing them. Conceptually, government and most companies tend to make some assumptions that support a position or action and it's easier to defend those assumptions when an independent resource has produced a data-based opinion. If you read my last article on Inductive communication you'll see a trend. Academia tends to take a lot of raw data and while scientifically examining trends and anti-trends, tries to make sense of what is being observed and provide some reasoning or hypothesis regarding what is happening. The next step is to narrow the data set or look for additional data points to support the hypotheses - you start wide then narrow things down to proof your ideas. With the most current trend and approach, you first make some guesses then find data to support those assumptions - it takes out the appetizer which tends to be less rewarding and very time consuming, and goes directly for the entree, so to speak. Think of this as more of a marketing document and less of an objective research paper.

I'm not here to explore the validity of the approach - as with anything it can be flawed and if you're one of those companies that professionally writes white papers as an output, especially to get paid, you'll tend to find data and correlations that match assumptions. Sometimes this can lead companies into making strategic mistakes, but more often than not the initial assumptions are sound and the white papers help to get projects funded and off-the-ground. And the whole point is often to start with something instead of a back-of-the-napkin idea. I've been describing the development of the white paper concept and how I've seen it change over time:

1. White papers as independent data analysis, correlation and theory using deductive reasoning and making sense of it all.
2. White papers as proof using inductive reasoning to defend a hypothesis
3. The latest trend, doing internal research to find information defending projects.

My focus will be on that third trend as I find it very interesting and I've experienced it first hand very recently. How did something which is supposed to be from independent AKA 3rd Party resources become an internal construct?

Most recently I've been asked to develop a series of white papers - these were asked for by our executive committee to be presented to help defend our division's current product roadmap and how ti relates to the overall company vision. I had witnessed a different group go through this exercise and frankly wasn't very thrilled to be caught up in a bunch of documentation and research. From my observations of this other group I noticed, very superficially, a consistent trend that involved: intent, due diligence (research), craft in writing, submission, review and rejection for edits, repeat ad nauseam. I could tell by the reactions, day-to-day from some of my product management coworkers (other teams, not my own) that what they worked upon was a bit of an exercise in futility. Most of the papers had gone through a revision history in excess of 30 versions, some exceeded 50 and many of the edits were really what I would call nitpicky - e.g. moving text two pixels to the right, changing the object color by a shade or recreating tables for consistent font size and usage. Stuff that for most of us who work in the agile world would find excruciating and yes, the outcry was robust, at least within our small sub-community within the company. This was all piled on top of a huge list of requested white papers - in fact there was so much research going on that there was a Senior Product Manager in charge of the project - sort of a PdM of White Papers (a paper crown would be appropriate, no?). Not to say that there isn't any value in consistency, presentation and messaging, but when you think about what's being asked for as content, you would also think that it would be more important to deliver good information rather than perfect, meticulous formatting? But I digress...

So with a bit of hesitation and a list of white papers being asked for from my group, I began tackling the task at hand. Originally I had three to do, but with a new hire to our team that went down to two. Fortunately, as with most projects there were already several artifacts available to me in the form of analysis by various business units and in some cases earlier attempts at white papers (at least they were labeled thus).

So how did these white papers turn out? Well, as you may infer, I started writing the papers with a bit of a negative mindset - no one wants to do "make work" for the sake of doing work. What was the most interesting was that in preparing my work and doing research, I actually found out a lot of useful information that began to change my perception of the entire task. It started to transform from boring documentation into something else, something much more useful. As with any research I first start with a diagram. It's my opinion that if I can't explain a process using a basic flow diagram, then what business do I have trying to explain it in detailed requirements? As with anything, one diagram suggests another and another and then you find yourself editing the diagram as you discover new ways of representing what's happening. You also start to see exception cases and allow for those. You also have a better view of what's important and what isn't so your MVP is much better.

Acting as a Product Owner for agile software teams causes you to become very focused on the task at hand. You end up often in a state where you can't see the forest for all the trees - this process of producing a white paper helped me to put things into perspective from a macro level. Rather than taking the least path to implementation, you begin to see where you might miss something that's part of the overall picture. Wow, I was suddenly propelled into the best aspect of Product Management - taking information and creating a strategic treatise on the "ideal product" and figuring out what baby steps need to be in place to get the whole product into production. That's the first real benefit of white papers - it's not the document your produce, it's the underlying research and thinking about the project that's important. It provides both better context and better overall product vision, that in turn produces a better product roadmap.

So what's next? One of the problems with working in a very tight team of product managers is that we all trust each other quite a bit. When we present to one another we accept much of what is presented and instead focus questions on the implementation rather than questioning some of the basic premises. As a result, when we distributed out white papers to each other there wasn't a lot of useful feedback. It wasn't until we shared papers in review meetings with a much larger group (that included both the BU head and also heads of engineering) that the really hard questions began. It was at this point that the next really useful benefit of the white papers became apparent - that the vision at the top began to be aligned with the thinking at the product level. The feedback and comments had us grumbling at first, however it did more to align our overall efforts, our product roadmap, and our thinking with the head of our division than during any other presentation or meeting. To me this was much more than a happy accident, this was a clinical example of how to align everyone for success! In turn, the message was passed to our corporate executives and now the unified message is passed in everything we say, do or release. This more than made the effort worthwhile and in effect transcended the dull work of writing white papers into something much more.

So White Papers... a waste of time? To answer this question, it really depends on what you are doing, the reason you are doing it, and what you ultimately do with the information. I started with the idea that these white papers were a waste of time, but in doing them found something more. The key to making these something other than words on paper is having the discussions that make them useful. In my case, the experiences became something much better than the sum of their parts. If everything worked this way, we would all be successful and every product would compete for greatness - we would make mediocrity history and raise the bar on all products. I think these papers had that level of impact on us and can only hope you too experience the same.

-- John

(also published to LinkedIn)

The Fallacy of Converting Requirements into User Stories

Borrowed from www.itworld.com

The Fallacy of Converting Requirements into User Stories

I don't know how many of my Product Management peers (or those others of my friends who work with scrum teams) have experienced a transmogrification/migration of a waterfall/RUP team to agile, but one common element seems to be the initial attempt of moving existing requirements into User Story format. Invariably a list of requirements is simply moved into an agile project with little or no editing - and it's amazing how many shops think that this completes the transfer. I also had a very interesting experience while working with a fledgling team in a new jira implementation which I'd like to relate.

The story of Excess

I had come into a new team that was trying to adopt to a scrum framework. While the product manager had some agile experience, it turned out to be rather sub-optimal to what would be considered a good, best-practices based agile approach (that PdM wasn't me, by the way). The requirements that he had inherited when hired defined a fairly large online application with multiple components include most of those you usually find: user creation, onboarding and maintenance; order lifecycle management; business process management; reporting and analytics, etc. Those requirements had been collected via existing business analysts and put into a traditional requirements document by an outsourced company via a product management requirements application (I don't recall which one, but basically each topic, section, sub-section, use casee, etc cascaded in an orderly fashion using numbering: 1.1.1.1 - you've probably encountered this before).

In a rush to get these into user story format, this PdM had all the data exported from this tool into a flat file (spreadsheet) and then imported into the adopted agile management software (in this case, jira). Since very little manipulation of the data was done before the import, this resulted in line items defining topic headers turning into User Stories with little to no content. I'm talking thousands of user stories with hundreds of summaries and no descriptions. Trying to sort this out, this PdM then had the company license a plug-in called "structure" (or something similar) that would then straighten out all the stories into some type of readable hierarchy. The whole process ended up taking several months. At some point I was asked my opinion about the whole thing (or perhaps I saw the result in conversation and just opened my big mouth, I don't recall which) I asked "Why don't you just start with the first component and decompose it into useful stories, describing an MVP to get the project going?" - actually my question wasn't that elegantly phrased, but I want to get this story going). The argument against doing this method was that so much time had already been spent with the current export/import mess. Of course this went on for several months - and the development team wasn't very happy with these stories or the way things were being prioritized. I eventually convinced the PdM to try my way and junked all those existing stories into an unused project.

So what went wrong, exactly? 

1. The product manager was pushed into doing something with the existing requirements so the project could get moving. For the sake of speed and being able to claim "There's 2000 user stories in the backlog" the export/import wasn't thought out very well. At minimum, when you use this type of approach, you should consider how the data is formatted (perhaps by doing a few sample records and seeing how things go?) and making adjustments on either side of the ETL or via a manual clean-up of the data file. To me pulling in requirements like this is probably a good way to have starting, stubbed-in topics but lack just about everything else necessary for a good agile backlog of user stories.
2. Trying to fix this kind of mess causes it's own time-suck - months were used in trying to first interpret the lack of canonical structure, then by selecting software that made an agile tool more like a traditional waterfall requirements tool, the stories themselves gained very little (it ended up just making things easier to read for the PdM, otherwise there was little to gain). Months ended up being used to fit all the user stories into the hierarchy that the structured tool provided. That time would have been better spent establishing a method of establishing MVP for each project phase and working with the scrum team to determine the best approach (this last bit was made difficult as the team was still being hired - the product manager did the best he could with what he had).
3. The third factor had more to do with time pressure and the need to derive some value from the work that had already been done. I'll focus on that a bit in the next section as a potential process solution.

So what is a better way?

It's always easier to look back and figure out what went wrong and fortunately we all survive to learn from mistakes. I'm going to cheat a bit and limit the solution to converting existing documentation rather than go all high-and-mighty about how the requirements were derived. We who have been practicing agile and scrum for a long time realize that there are many approaches to translating requirements into user stories and much depends on the expectations of the team, company and established principles. Some methods are good, some not so good, and sometimes we have little choice in the matter. For me, I like to have conversations with the people using the software (the business, consumer or end-user) and work backwards towards the solution, focusing on the desired outcome rather than on the tactical implementation - that latter part I think ideally should be determined by the entire team. Unfortunately in shops that are adopting agile, there's a lot of baggage that we all have to contend with and sometimes it's just not worth the effort to overhaul the entire process - better to make small improvements that lead to big changes over time. So how would I approach a similar scenario as my story above?

1. First I would carefully read and try to understand the existing documentation. Presumably it's been done well and is worth circulating to engineering and executive leadership - after all someone had to go to the effort of putting it together. I would also do some spot checking against any critical requirements to ensure that enough due diligence was done while putting the document together, by validating those assumptions with end-users.
2. Next, I would circulate the overall effort with engineering leadership to help define the near and future goals of the software. This is to establish some design principles and at least create a contextual framework focused on data, objects, interfaces and general principles, especially around the moving, calling and updating of data. Your engineers usually already have some coding standards - now is the time to get buy-in from the group so there's a bit of consistency in implementation against the overall project scope. The outcome of this should be some good architectural diagrams of the various components necessary to get to the endgame. This can then suggest the best method of execution and the start of user story creation.
3. Using the existing document, I would then see if the topic headers fit the suggested method of execution - the higher-level topics become epics that are further decomposed into user stories. Sometimes the sub-topics fit well, and other times they don't so they may not be very helpful (generally they are).
4. The guts of the requirements are then used to write the user stories, which should be abstracted. Typical requirements are too specific - they tell the user what to do. Instead the approach should be one that tells the developer what the end-user want's to accomplish as a foundation of a collaborative user story. The baseline requirements could still be useful in determining the number of field values that may be required due to some external dependencies, etc but in general the perspective of the story itself should focus on who has a need rather than what needs to be done.
5. At this point the high-level topics for the near-term should be fairly well defined, with less definition for the other parts of the project. As each component part is elevated in priority in the backlog, each story is evaluated by the entire scrum team with a focus on context and what the feature is trying to solve. The story is edited to make sure that we're all on the same page and there's a clearly defined acceptance criteria so we all know whether the story has been successfully completed.

So easy, right? Like I wrote earlier, its much easier to determine what went wrong and suggest something better in retrospect, rather than while things are happening. The fallacy that I refer to in the title is the assumption that a Requirement from traditional waterfall or RUP development means the same thing as a User Story in Agile/scrum. They simply don't, and because the intent of each is different, relabeling doesn't work.

Borrowed from http://agile4freshmen.blogspot.com/

I remember my first experience with agile - we did exactly the wrong thing. I basically took a traditional requirements document and did a search-and-replace of "Requirement" to "User Story" - see, since we were also doing scrums, we're doing agile! It actually took quite a bit of time and experience to realize that what we were doing was adopting some of the ceremonies and artifacts without really understanding how things fit together. The problem is that often even adopting small parts of the agile framework can produce a positive result where a development team sees improvement. It's my opinion that there are as many teams that think they have successfully adopted agile as there are those where agile adoption has failed, each for the same lack of understanding.

-- John

(also published on LinkedIn)

Using Inductive Thinking to Communicate Strategically

The Problem Statement

You're making a presentation before your company executives and two slides into the deck the CEO says "Can you just tell me how we're going to fix it?" The first time you encounter this you may be surprised and full of anxiety (nothing like being challenged). I'm here to tell you that if you don't prepare your presentations to cater to your audience, you've failed as a product manager. When we all start our careers in product management we are rarely afforded the opportunity to interact directly with executives (I know there are exceptions, particularly in start-ups where teams are small, but this is an exception rather than the rule). As our careers progress, we have more and more of these encounters and I'd like to introduce a concept that may be unfamiliar to many of you - or in many cases you've already figured this out but I'll formalize the concept a bit. In general the topic is about inductive thinking and applying the technique to communication, especially in presentation.

The Pyramid Principle

The interaction we have as product managers with technology teams, customers and executive management can be both a blessing and a curse. On the one hand, we are placed right in the middle of where all the action occurs, where we can have the most influence on the outcome and great visibility towards progress, sort of a 50 yard sideline view (for those of you familiar with American Football). For most who have product management roles, that provides great incentive to "get out of bed in the morning." So if you're like me and have been doing this for a while, you've already come up with some of these techniques - in particular I relate these ideas to some journalistic training I was exposed to in school called the Pyramid Principle to communicating (specifically in how to write an article for the traditional print media newspaper - I may be dating myself here). The Pyramid Principle is fairly simple and many of you may already be using it, whether you realize you are or not. Basically, you begin your writing with a very short summary of what your article is about. This is usually just a few sentences or a short paragraph. The second section expands on what you have summarized with additional, second level details - basically the "meat" of what you are trying to communicate, providing enough details that the reader can understand your opening statement (the tip of the pyramid). Finally, you provide all the details that underlie your assumptions, providing the foundation or base of the pyramid. In journalism this technique provides two functions. The first is to provide a summary for those that are just reading headlines so the largest amount of topics can be included on the front page or first few pages. If the reader is interested he'll continue reading and if it's of great interest look towards the back sections of the paper to find all the details. The second function it provides is to fulfill this mantra: "Tell the reader what you're going to tell them; tell them; then tell them what you told them." While in general that last idea is a bit different (it's very effective to reinforce teaching, but in regards to the Pyramid Principle it's not exactly the same concept) fro pyramiding, it does have a similar effect, just a different impact. Inductive thinking and communication takes the Pyramid Principle and applies it a bit differently by placing the solution first.

The Difference Between Deductive and Inductive Thinking

So how does Inductive thinking apply? Let's first go over the what most of you are already familiar with, deductive reasoning - made most famous by Sir Arthur Conan Doyle's detective character Sherlock Holmes. In The Sign of the Four, Homes says "...when you have eliminated the impossible, whatever remains, however improbable, must be the truth (sic)" In deductive reasoning, you use top down logic based on premises assumed to be true to reach a logical conclusion. Doyle's detective takes this concept and uses a series of elimination steps to remove possibilities until a single conclusion emerges - the issue with this type of analysis is that sometimes you're asked to "boil the ocean" to get to an answer. With inductive reasoning just the opposite occurs. You select examples to supply evidence for your conclusion and use logic to support the answer. Deductive reasoning works best when the problem has a limited number of factors and the process of elimination leads to a definitive conclusion. Inductive reasoning works best when time is of the essence against a large number of data or factors; and you have a good understanding of a solution based on what you know to be true, using cases to support your conclusion. Sound familiar? I think deductive reasoning works very well for troubleshooting and fixing bugs, as in software development we often know the context of existing systems. Inductive reasoning resonates well when making decisions on new features, especially those that have little or no existing context (think new opportunities or "green field" development).

Applying What You've Read

So how does this apply as a strategy for communication, especially when communicating upward? You need to understand what's happening in the minds of those vaulted executives. In general, executive management is bombarded with information, often on subjects where there is little context, experience or time to invest, making it very difficult to come to a quick, reasoned decision. There's usually also a huge backlog of information and decisions needing to be made from multiple sources, vying for time and attention. Using inductive principles, you can best apply your thoughts to appeal the most efficiently to people who make decisions that are saddled with too much information. You open your communication with both a summary of the problem or opportunity, and a definitive solution. The rest of your article or messaging provides supporting arguments derived from the artifacts and any details are either pushed to the back or made available as appendices. I use the term solution with article and presentation for a reason - in general your format is as important as your message. It's my opinion that to fully illustrate a problem and solution, using diagrams or graphs of information are easier to both communicate effectively and for the reader to absorb. If you can get all this into a few PowerPoint slides, all the better, as that software has great utilities for diagramming and representing information graphically.

This technique is also sometimes called "Answer First" - instead of building to a conclusion you state the problem and solution first, then use the rest of the information to build your case(s). This all starts with a hypothesis as "the answer" and to support your decision, you should focus on two questions: What is it? (Hypothesis) and Why should you do it? (Controlling Idea/Answer) To make sense of this you start with a controlling ideal like "The hiring of FTEs should be increased in 2015 to execute the new service level strategy worth $300M in cost savings." You then apply a controlling structure in everything you communicate to reinforce your supporting ideas, justify your decisions and get buy-in to what you are asking to be done. An effective structure involves two aspects and two key benefits:

1. Arranges ideas into distinct, logical groups so it's easier for the reader/viewer to absorb and remember the information
2. Putts emphasis on the supporting logic so the reader/viewer arrives at the conclusion you intend.
3. Serves as a roadmap for analysis to help you drive toward a finished product
4. Enables syndication of the story prior to analysis to allow you to get that coveted "buy-in" so you can make changes easily - the fail early and often scenario.

You'll notice that you can apply this structure to everything you do, from analysis, to presentations, to business cases to messaging.

So what are the pitfalls of this approach?

1. It's still very possible for the problem and solution to be confused and/or challenged if it's over-simplified.
2. Sometimes it's better to develop a more deductive approach rather than an inductive one, depending on the audience.
3. Inductive reasoning itself can be flawed - by myopically selecting only those cases that support the argument it's easy to disregard competing cases which can lead to a poor outcome.
4. PowerPoint (slide) format is great for communicating small amounts of information but you don't want to fall into the habit of 100+ slide decks - you're basically ensuring that most of the information won't be read. A general rule-of-thumb is that if the information is to be presented live, try to keep the ideas within the first 20 slides or so. If there's special emphasis on the data and means to a conclusion, it's probably more appropriate to use a different format.
5. Decks are no substitution for actual conversation. Think if your presentation first as a means of conveying ideas (diagrams and charts), second as a pre-presentation resource (it's great when those you're presenting to have good, relevant questions) and finally as a leave-behind (your executives will want to cross reference your information in the future).

In any case, I hope that I've provided something for you to think about.

And now for some disclaimers. This article merges some of my experiences with some ideas garnered from training I was exposed to several years ago. I tried to keep most of the terms used fairly generic and broad of scope as I don't want to infringe on anyone's IP. I'm also not sure who derived the training so if there is an attribute please let me know - the diagrams and images used are my own.

Product Management Soft Skills

You old softy...

As a preface to this, I was asked recently about how I had come up with a solution to a problem and I started explaining my thought process and the rationale behind my recommendations. Much of my explanation was around the use of insight and experience to dissuade or direct the conversation to a mutually beneficial conclusion, somehow getting my way (which I considered the best solution) rather than what the client was specifically asking to be done. I was asked "How do I learn how to do that?" This led me into thinking about soft skills and how they can impact a project and the success of the product manager. It seems a lot of hiring managers put great emphasis into experience and degrees and yes, these can go a long way towards your career goals, as does training (for instance, I'd recommend to any aspiring product manager to take the CSPO course). The more environments, the more applications, the more businesses you've had the fortune of working with and within, the better you'll be able to use those experiences and apply them to product management. However that is only part of the story. I think the traits best explored for improvement have to do with soft skills that really amount to a single concept - that's how well you develop relationships. In general I'm referring to the tool kit everyone carries around and uses whether you are aware of it or not, that enables you to be effective to and with those around you. I'll break these down into several categories: communication, empathy, context, data, shared ideas and goals, passion, and trust.

In nearly all product management job listings there's a common element that's generally wrapped up in a couple of lines that have to do with effective communication. As a product management professional, our job is really to delight the customer or consumer with what we are building - this applies to software, hardware or just about anything else. The first soft skill that is essential to being good at our job, is having the ability to translate what we hear, develop an understanding, and be able to retell what you have heard in your own words. This, combined with thoughtful conversation that includes back-and-forth questioning, leads to a shared understanding and allows you to further relate your understanding effectively to those on your team responsible for executing the objective, in my case, great and usable application software. From a high level, we call these requirements and some of the artifacts may turn into SOWs, functional requirements, epics and user stories - whatever works for your group. Everything begins with conversation and some type of validation process to develop a shared understanding, which you will do multiple times through the life of a project, whether small or large. In regards to communication, I believe it's more important to develop the skill of listening rather than speaking - it's difficult to understand what's being said if you spend all your time talking. The follow-up skill is to ask good questions. I like the adage, "There are no stupid questions" - you should take this to heart and make no assumptions. If you are constantly fielding questions from development and having to pass them along to a business contact for clarification, then you have probably not asked enough questions at project inception, nor do you fully understand the project. It's OK for this to happen if you have little context (like in the very beginning or if you are new to product management), however it's part of your job to have this context beforehand so you can anticipate those questions. More on this later.

The next soft skill to develop is empathy. A fairly generic description is to place yourself in the shoes of those asking for the feature or those experiencing the problem. Until you fully understand what is being experienced, it's really difficult to create a good solution. I think in general we in software development spend too much time coming up with the next new, cool feature and not enough time understanding what is useful or needed. We tend to take for granted those that are using the software we create on a day-to-day basis - the proof is all around us - how many times have you heard of some application releasing something that's held in so little regard it seriously impacts the company negatively? Sometimes we try to make things too complicated and this kills adoption. Other times we just plain miss the mark by providing something that no one really cares about. We need to use empathy to understand how our products are used and to access how important features are to our users. This will help us in developing good behavior-driven design in our products and we need to be able to provide this as context to our teams. Empathy also is very important when interacting with our team members. You need to understand what they are doing to some extent, or more importantly you need to be able to detect when someone is frustrated, either with a task or in trying to execute against their understanding of a user story or requirement. Have you ever had a story fail over to the next sprint over-and-over, greatly exceeding the original point estimate? Have you tried to empathize with those executing the story to attempt an understanding of why the story isn't done, or do you start complaining? It's through empathy that we become better understanding, and consequently, better at delivery.

I'll go on to context next, as I've already mentioned it in the two preceding soft skills on my list. Understanding how to use context is important as it provides the environment from which you will become the most successful. So how is this a soft skill? I think we take for granted when writing requirements how important context is to your team members. Often when I get a question like "why do they need this?" or "what are they trying to accomplish" it identifies a contextual problem - your team should already understand where a user story or requirement is going prior to the start of coding. To become skillful with context, a product manager needs to fully understand why the requirement exists. To understand why it exists, one needs to comprehend what problem or opportunity is being solved. Just as a good book needs a setting to establish the framework of a story, a good requirement needs context to fill in the gaps so there is a common understanding of what underlies the requirement. As a soft skill, to be effective the product manager needs to both understand the context and relate it meaningly to the team. It's this latter bit that identifies the execution of context as a skill and it's something that's often missing when working with a team. To me, being able to use affinity to something that's already been built, or using common analogies to illustrate concepts is very important. These may be supplemented with process diagrams but for me, white boards are essential to both describe the action, provide context and to answer questions - they're also a great way to identify gaps or issues.

How is data a soft skill? It's not in itself, rather it's a reference that needs to be recognized as important for many reasons. For those of you who have read my blog or other posts, you'll know I harp on data all the time, and for a reason. As a soft skill, you must recognize the importance of data, develop methods of acquiring it; and engender skills to interpret, refine, filter and express that data into a useful outcome. What I like the best about data is that if you know and understand it, you will be able to influence everything. As a tool, data is more of a crowbar that allows you to intersect with existing efforts, interject new thinking when needed and break heads as a last resort. Noting wins an argument faster and more completely than having the data on hand to support your position. If you're ever done any debating, you'll know that having quotable references provides huge advantages and can deter long and heated arguments - the same goes with having data on hand and some analysis on how it impacts your projects. If you live by the need to have data for your decisions prior to pitching them, this tool can take you a long way in executing your product vision successfully.

Which brings us to the next soft skill, being able to foster an environment of shared ideas and goals. You might think of this as teamwork, but I don't consider teamwork a soft skill so much as how a good product manager provides insight to contribute to the ideal team. So from my perspective, teamwork itself isn't a soft skill, but rather having an ability to instill a common goal in the team so everyone is working towards the same outcome. Many of the artifacts around scrum are there to get the team working together within a sprint - what the product manager can bring to the table is an alignment from overall corporate goals, to business unit goals, to team goals and finally to sprint and release goals. The good product manager constantly reinforces those goals throughout the process and helps to redirect the team's thinking to achieving those goals throughout the development process. If you've ever worked in a very efficient team, you'll know what I'm referring to here - it's often displayed when someone on the team asks the question "How does this fit into the overall effort?" or "This seams contrary to the drive for revenue" or something similar. The question itself isn't as important to what it implies - that someone is thinking about how everything fits together instead of blindly coding specifically what is being asked to be built. Once again, there are no stupid questions...

It seems we all want passion in our lives - I think as a soft skill it's more about how that passion is expressed and how it communicates to others on the team and to your customers. At the deepest level, as a product manager you should be passionate about what you are doing - if you're not, then why are you doing it? I think many would disqualify passion as a soft skill, and I'm sure all of us have encountered people who were so passionate that they were actually detrimental to a project. The quality or soft skill we want to develop is to make use of that passion to reinforce the team, the project, and in general use it to focus and influence all participants into aligning into a common goal - success and enthusiasm in creating great products! Just as we use the other soft skills as parts of the product management tool kit, passion can be used to either bludgeon or enhance a team. As such it's both a sledgehammer and a micro-screwdriver (but typically it's the former and not the latter). The difficult part is learning when to let the passion out-of-the-bag and when to save it for later - for instance, using it at the wrong time can lead to confusion and accusations of "emotional problems" (nothing like being accused of bipolar disorder!) - instead I think we should use that passion as a general enthusiasm of the project and team; and save real outburst for when they can be the most effective. We also must be very careful not to get carried away and allow it to have the opposite effect (what happens when it's used inappropriately).

The final soft skill and perhaps it's more an outcome of all the rest than a skill itself, is trust. Everything that we do as product management professionals leads to building relationships. To have good relationships, each party needs to trust the other. I often hear about transparency, communication, face-to-face meetings, etc to improve the design and build process, but really all of these are vehicles for the same thing - building trust. It's much easier to empathize with team members on a project when you have met them personally. When you have the trust of your business, your customers and your team, there's very little you can't accomplish. It's even possible to come in on time and under budget! So how do you get this trust and how can it be leveraged? if you think back to how I began with the idea of relationships, it's something that's difficult to quantify, but we all tend to have some idea about how well things are going. When things are going extremely well, the trust level tends to be very high. The opposite it true when things are going poorly. When you are questioned regarding a product decision, it's usually because there is no trust or that trust is in question. This becomes a culmination of all the other soft skills - when you use all other tools effectively trust is enhanced. And also the opposite is true - if you fall short on one or more of these soft skills, if you have already developed a high degree of trust, then much of that lack is forgiven.

That's about it for me - understand I'm not saying that these are the only qualities or soft tools that we need to be successful, I'm sure there are many more. These are just those that I've thought about during the last 30 minutes or so.

-- John

Revolution vs Evolution

I've recently been in a few discussions with colleagues about software innovation and how it relates to product management so I thought I would share a few thoughts. We always talk about opportunity, and frankly, we usually use it in a context to defend or soften a product decision to an end user (aka client). In this way we use words like "opportunity" to define a problem that needs fixing - since many of us bill for the work, the term "opportunity" equates to making more money, at least to a consulting company; and the use of the term "opportunity" is much more palatable than "problem." Instead we should identify problems as problems and spend our time working through solutions and really, isn't "solution" a better term than "opportunity"? In any case, I digress, as the topic I want to explore is one of innovation.


What got me thinking about this is an encounter I had earlier this year with a process improvement group. This is the scenario - I'm working within a project to rewrite existing software using new technology and better design principles. Most of the requirements were derived from interviews with the management teams using the existing software (they in turn presumably worked with their teams to come up with innovations and improvements). Fairly straight-forward, right? We then took those requirements and began exploring implementation converting the requirements into epics and user stories, to get the conversation going with our team, derive executable bits and present them back to the business users as we move from bits, to MVP, to production release and consumption. We take a very agile approach to software development so the first hurdle was to get our business users to adapt to this practice - not an easy task. Our BUs tend to throw everything into the requirements and their initial expectation was that everything listed would get done - which made it very difficult to get things through UAT, even when we constantly explained that it was a planned cycle of development moving from simple to complex. In their minds, "working software" meant that everything they wanted on the requirements was done, to be able to define the software as working. Once again I digress, but this time to help provide some context.

In actuality, there's an inherent problem with this requirements gathering method. First, the innovations asked for by the business user usually relate to the existing software platform and amount for the most part to tweaks or small process improvements. Second, when those requirements come through the management filter they tend to be broad-stroke in some regards, and myopic in others (depending on what the manager perceives as important). Third, the methods that the business user is defining in requirements are usually the same as the original software without thinking about how the entire application could be improved by changing the underlying software method - what I mean by that, is when you have staff trained to use software and they are used to that software, it's hard for them to think about an entirely new methodology that's outside of that experience and context. So to continue my story, some of the things we introduced in the rewrite had to do with using an off-the-shelf BPM engine. Our thinking was "why reinvent the wheel when there are already so many companies out there who have figured it out?" So this became the first point of contention - even through a BPM package may satisfy the baseline requirements, there are usually some fairly rigid rules within a fixed methodology that are required by the software itself. It's a tradeoff - you get better accuracy and many of the bells-and-whistles you're looking for, but to take advantage of them you need to conform to the methodology designed within the software. Once implemented, the next challenge was to get our business users to understand that the methods have changed - the outcomes are the same, but by using something more standardized, it will be easier and better to use the same software to do similar tasks. This change is rather disruptive, produces a lot of user angst and confuses people, who are still used to using the original, legacy software.

So around the time we first got our users used to the changes with the introduction of the BPM technology, we were introduced to a new process improvement group. Seeing this as an "opportunity" - the group was brought in to look at the existing methods and suggest improvements that could be incorporated into the newly designed software. This included analysts actually sitting down with the business users and observing how they use the software. We welcomed the additional resources and hoped that a few "magic bullets" would be identified to really make our newly rewritten software fantastic, hopefully saving money and time by identifying process improvements through the application of technology. So now, we're getting to the crux of my article.

The report that was delivered was interesting, not in all the suggested changes and aggregate analysis defending changes to the overall workflow, but in that it copied almost requirement-by-requirement what we had already defined and planned in the rewrite. It basically validated what we already knew and made the same improvement suggestions that we had already planned. What we received was evolution, rather than the hoped for revolution. And please don't think that I'm diminishing the importance of what the process improvement group did - it's nice to have validation in what we are doing and have planned and there's certainly value in that. I think that as a group we had much greater hopes and that our expectations were unrealistic. I also think that in our world of software development we spend a lot of time trying to improve things rather than searching for new solutions - that outside-of-the-box solution that's so new it can redefine what we are doing and how we are doing it. Not to say there's no value in evolution. One of the easiest things to defend are improvements that cut the bottom line - even small process improvements can do this and the accumulated savings can be quite significant.

So what is better? In my opinion, revolution is thinking about a problem and coming up with a solution that is so novel it doesn't fit within the original problem statement. The downside is that it can be very risky. And no, the ideas don't often happen overnight. Evolution on the other hand, involves small, incremental changes and has less risk, but when that's what you rely upon, you could get trumped by a new market contender with revolutionary ideas. I really think we should use both methods but in general try to think in revolutionary terms - more of a mindset than a strict method. We should embrace the good ideas backed by real data, and defer on ideas that offer little to the bottom line that have no data to support them.

How I long for a time when I receive information that is filtered for relevancy (important to me and customized for my needs), from several sources, all in one place using a single sortable and filterable delivery mechanism. There's been a metamorphosis of thinking when it comes to communication that started with emails, went to the use of distribution lists, forums, communities, wikis and now messaging aggregation with software like Slack. This last example is something transformative that's been happening for several years and is only now beginning to get some attention outside of software developers. You would think that this is an example of evolution, but when it moves outside of the development word it becomes revolution.

Quantified and Qualifed Data

I'm back on the Data bandwagon and please excuse me for being persistent - if you read my last post, I made some statements about the importance of data. I then listed some ways we, as product management, should assemble data to support our product actions. I'm continuing with some thoughts that have bearing that I was remiss in pointing out the last time. If you read that last post, I made some assumptions that you can infer regarding the data itself, but wasn't very explicit so this is a bit of a clarification. What I called Data that last time should have been called "Quantified and Qualified Data" - I'll explain.

Monday night (2014.11.17) I attended the Atlanta Mobile Developer's Group meeting in Buckhead (this was at Alliance One and hosted by eHire). The presentation was called "The Tau of Mau: How to turn meaningless app downloads into engaged users" provided by Jeff Steinke. The presentation was one of the better I've attended this year - in this case "MAU" is Monthly Acquired Users and refers to a trend in the mobile industry to measure success by registrations. He used a graph bearing from 0 to 700K that hockey-sticks over a period of several months and began with little explanation to see if, based on that little bit of information and making the assumption that the room was full of potential investors, would we be willing to invest.

Without giving too much more of his presentation away and to get to the point of today's post, several slides in Jeff talked about how data should be both Quantified AND Qualified and how that first exercise put all the reliance on the quantity, and not on how qualified the data was. For mobile app users (and really for most B2C web users), downloads mean very little without engagement. For one of Jeff's company's (Less Meeting), he listed three things that allowed them to know a better picture of success: download (registration); completion of a short tutorial; and finally the use of the app to schedule a meeting. The talk itself boiled down to engagement and the definition of engagement (for most it's convergence - if the user isn't using your product, then a free download has little meaning). Jeff had done enough analysis to determine that if their new user accomplishes the three things on his list, there was a high degree of certainty that the newbie would become a real, paying customer. Back to the initial example used by Jeff to illustrate unqualified data, the company had a lot of MAU but very little actually ongoing engagement. Hard to monetize users if your application is a "one trick pony."

From my own personal experience, I've worked on several applications where the project decision was made for me and ultimately that decision was flawed. The problem is in looking at the raw data and not applying some sound reasoning to filter the data into something that's qualified. In the earlier days of the web there was a lot of emphasis on getting application registrations - this was based on an old-school thought that when people buy software they have skin-in-the-game and as a result they become users. The issue with that assumption is that the web changed the paradigm - all those early companies (most now defunct) based their logic on sheer numbers, and it was relatively easy to get funding (everyone wanted to invest in the next new start up and become an internet-millionaire!). Saying you had millions of "users" (meaning registrations) sounds awesome to investors who would hand-over-money just for an opportunity, without any sound reasoning behind what would power the monetization of those users. When the Dot-bomb dropped and there was a rush to convert all those free registrants to paying customers, the companies fell like dominoes. The analysis was flawed.

The other metric that often used to sell-a-company is number of site visits. The argument is that if you have a lot of visitors, you can always build a revenue model of page views and click-throughs. As someone who has also worked in this type of environment, this can also become a flawed statistic. When you look at the actual number of views you need to make any appreciable money from this model, you're not making much until you get into the 100s of millions. The corresponding likelihood of a click-through is likewise a flawed statistic. If the keywords driving those ads aren't relevant to the user (meaning things have to align just-right - user type, application type, paid-for-words and the gods!) the actual revenue gains are significant as single-instances, but flawed as a sum. Also, these types of campaigns are cyclical in nature so they can rarely be relied upon (one exception is to create a "key accounts" model where you have broad-spectrum advertisers who already have established brands). A technique to help you qualify these numbers is to tag pages to ensure that the user stays on the long enough to actually see the ads placed. Another is to use SEM to aid in placing inbound, specialty pages, which tends to have a synergistic affect on organic search.

So what else can you do? I think that using experts to help you decide can go a long way towards qualifying the data (I'm a fan of Data Science). I also think it's very important to use both the experience of your team and the information you garner from existing customers, to determine how that data rolls-up into something that can be used. If you look at something and don't understand it, re-examine the data to see if it fits some patterns or anti-patterns that make sense. Another idea is to leverage your network of technical experts - I'm sure we all know and have worked with professionals who have "the eye" in regards to gaining insight into the data. Ask lots of questions, gather your data and make sense of it.  Put monetary figures against what's happening and compare it to what you know and possibly don't know. Strive for understanding, and make the data work for you.

More information regarding the Atlanta Mobile Developer's Group: http://www.meetup.com/Atlanta-Mobile-Developers-Group/

Jeff Steinke's blog: http://www.jeffsteinke.com/

(also published on LinkedIn)

Good Product Management is Based on Good Data

I harp on this all the time and I'm sure my colleagues are tired of me saying it - but I'm of the firm opinion that we should DO NOTHING in regards to product management or product development, without the data to support our decisions. The foundation of any change is underpinned by data to support that change - whimsical changes or even changes supported by some perceived need, mean very little without supported analytics. Foregoing the due diligence, even for small changes can not only be detrimental to the application but can also ultimately impact your company's bottom-line. You do not want to be in the position of defending your actions, even if they seem innocuous, against a product backlog that has real calculated ROI.

Even Dev Prospecting (the idea that sometimes we need to push a change that could garner new business or customers with some nebulous "maybe" result through innovation) should have a minimal data construct projecting what may come from doing so. For this I look at data models in parallel or similar affinity vertical markets.

If you aren't paying attention to the data, making some effort to understand the trends, and have the ability to filter the noise and make some decent projections based on what you see, you're doing more harm than good. So as a Product Manager, what can you do to get this data?

Research: Public Searches. The first avenue for any good product manager is to start doing some searches online using probably keywords. I think most product managers already have some ability at finding public information - it's a skill one develops over the years and is a good starting point for just about any knowledge gathering. Google is your friend, but this is only a starting point. I'd suggest you start brainstorming and as you broaden your searches, additional keywords will suggest themselves in the results you find. Make sure you note what you find but stay relatively focused using the additional words as possibilities as they can get you really distracted (ask me how I know?).

Research: Examine Your Internal Data. The second tool in every product managers tool-kit is internal data. Most of us have applications that have been running for several years and the data is sitting there for the grabbing. Look at the data points you have and see if there's information there that can be used for modeling or to suggest avenues that support your case. Just be careful, especially if you're forecasting to take this data with a grain-of-salt. Using existing data works great to support cost savings; it's much more dangerous to use it to support revenue opportunities.

Research: Use Your Existing Customer Pool. It's always blown-my-mind when I've come to a company and realized that there is almost no interaction with the existing customers, beyond simple support and account management. If you have enough data to identify problem areas in your application via support calls and emails, what's more useful than to reach out to your customers and start a conversation. Begin with what they like, move to what they don't like, then start suggesting things you'd like to do. The information you receive can be quite compelling and leading you to paths making good application decisions.

Research: Use Your Existing Sales and Support Pool. As above, we often receive feedback for what's wrong or bad with what we are doing from an application level. What's harder is to get a sense of what really needs to be changed or fixed. Use data as the foundation, then interviews with your coworkers to gauge what will have the most impact - you'll often be surprised at what you find out and once again, these are leads that can direct you towards real innovation. I love getting sales figures and using the information to defend a case for doing something, or even better, against doing something being driven by someone with influence but no clear understanding of what's needed.

Big Data and DataScience. The last and this is something that I'm a big fan of - hopefully your company has embraced DataScience and hired a good python developer to parse through your tables. It's amazing what can be discovered by trending data and looking for graph-outliers or anti-trends. As product managers, we need to better understand how this last tool can be used effectively, to support our case when making product decisions.
I think most product managers understand all of this, if at a very subconscious level. At minimum, keep your mind open and don't simply disqualify ideas being promoted by your coworkers - I know that we're all busy and that this is easy to do, but your do yourself an injustice and really exhibit a lack of respect for those you depend upon the most.

"I get it...I get it"...

-- John