tag:blogger.com,1999:blog-57476864058917599832024-03-05T08:39:24.071-08:00Atlanta Product ManagerMy views on software product management and related topicsJohn Eatonhttp://www.blogger.com/profile/00040215463441470962noreply@blogger.comBlogger22125tag:blogger.com,1999:blog-5747686405891759983.post-50886681412844228002023-05-04T06:56:00.002-07:002023-05-04T07:17:18.309-07:00They Took our Jerbs<p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjyKT6F8ndSf_MLumWXzqcCwg9ZDyjQN115LIKAJLA1-Gmv8VBMywQmY0lhmVqFOdQCBWQKsmu_g3LmeeziVhw_-CRL3e2qWY5Ajj0gf2oZnPg4bSapeROBLjM40RdFIov05C_qH6NJRzo0MTkeL05y3RkjlAzytMO1gL3qvMugrIaCS4yRYv9eOUKu4Q/s1600/AI.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="893" data-original-width="1600" height="179" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjyKT6F8ndSf_MLumWXzqcCwg9ZDyjQN115LIKAJLA1-Gmv8VBMywQmY0lhmVqFOdQCBWQKsmu_g3LmeeziVhw_-CRL3e2qWY5Ajj0gf2oZnPg4bSapeROBLjM40RdFIov05C_qH6NJRzo0MTkeL05y3RkjlAzytMO1gL3qvMugrIaCS4yRYv9eOUKu4Q/s320/AI.jpg" width="320" /></a></div><p></p><p>I had an interesting conversation over a few beers with a fellow Product Manager recently at a ProductCampATL/ProductCoffee event. To set the stage, I had already informed those present that I was currently looking for employment (and several others at the table were in the same boat). We got around what each was looking for in a new job and I asked the person sitting across from me about what he did (he was still employed). His reply was "Oh I've been teaching AI how to replace me as a Product Manager." - seems he's been setting up routine parameters for the writing of user stories at his current job and it was his opinion that he was becoming obsolete. We discussed this for a bit - while I had played around with AI like ChatGPT, I was under the misconception that it was closer to earlier ML constructs - he informed me that the Large Language Model (LLM) had come so far that it was pretty amazing and far superior to what I had sampled in the past.<br /></p><p>This got me thinking about what he said so I did a bit of testing/research. The result is a natural progression (I'm using ChatGPT as an example but it can be any similar like GoogleBard):</p><ol style="text-align: left;"><li>You ask ChatGPT to define a list of User Stories - asking progressive questions and defining routines until the data sources, parameters, etc fit what you're looking for. ChatGPT produces those stories. Note that you can build up your routines through interaction and get a refined result set. <br /></li><li>You then ask ChatGPT to take those stories and write the code to produce the desired results - tell it the code base and it searched public git repos to program. <br /></li><li>You then ask ChatGPT to look for exploits in the code, which are applied to the revised code</li><li>The code is put into a test environment for you to view and use. <br /></li><li>You can then produce any revised graphics for your program with parameters for style, voice, ease-of-use, etc using ChatGPT or another AI image generator.</li><li>Once you like the results and you've made tweaks, you've launched something new, with relatively little human interaction.</li></ol><p>So basically, you've not only replaced the Product Owner, but also UI, Engineering, Quality Control, potentially PIN testing and at some point, probably the entire DevOps process (I left that out as I'm not sure if that's currently covered). This scenario may seem far fetched, but consider that we're only in nascent times when it comes to Large Language Model AIs - this is only the beginning.</p><p><b>So does that mean we're all out of a job and what can we do? That's the $1M question.</b></p><p>Putting aside all the other tech and ops roles, the first thing that came to mind, is that we as Product Managers have a rather complex role of in-between-ness - We help to corral the needs of various stakeholders and help to prioritize how they are injected into the development process. This starts at the portfolio initiative level with strategic planning and cascades down towards tactical execution, which has it's own segmentation: negotiating with stakeholders what gets built, when and in what order. During this process there's fulfilling the needs of sales and marketing to understand what's being delivered and to help define stakeholder benefit. Now one can argue that an AI can replace the prioritization, negotiation and launch tasks and I believe that's true for something really small scale (like if you're a team of 5 in a startup wow), but in any really complex environment there are lots of humans that would need to be convinced of AI's infallibility. Also, while it would seem that AI would be better at complexity, I think at least initially the more complex the construct, the harder AI will have to determine a best course of action (this will change over time, especially with the use of multiple, more specialized AI).<br /></p><p><b>The next thing I thought about is Evolution. </b></p><p>As scenarios are built in AI, doesn't the AI learn what's being asked? Doesn't that mean that any IP you own is shared as examples with everyone else that's also using the same AI? First, does it matter and second, what are the consequences?</p><p><b>To answer this I asked ChatGPT a a few pretty basic questions: </b></p><p><i>I.<b> </b>"How can the information generated by AI like ChatGPT negatively influence future queries?"</i></p><p>While AI-generated information like ChatGPT can have many benefits,
there are also potential negative impacts on future queries. Here are a
few examples:</p><ol style="text-align: left;"><li><p>Biases: AI systems
are only as good as the data they are trained on, and if the training
data is biased or incomplete, the resulting answers may also be biased
or incomplete. This can lead to inaccurate or incomplete information
being presented to users, which can have negative consequences.</p></li><li><p>Misinformation:
Like any source of information, AI-generated information can be subject
to misinformation and fake news. If an AI system is trained on
incorrect or misleading data, it may generate answers that perpetuate
that misinformation.</p></li><li><p>Lack of context: AI-generated
information may lack the context that humans are able to provide. This
can lead to misunderstandings or misinterpretations of the information
being presented.</p></li><li><p>Over-reliance on AI: If users become too
reliant on AI-generated information, they may be less likely to
critically evaluate the information they are presented with. This can
lead to a lack of critical thinking skills and an inability to make
informed decisions based on the information at hand.</p></li><li><p>Dependence
on technology: If AI systems become the primary source of information
for users, there is a risk that users may become overly dependent on
technology and lose the ability to think for themselves or access
information from other sources.</p></li></ol><p></p><p><i>II. Can the information generated by AI like ChatGPT negatively influence
any IP holders of information due to the sharing and learning aspects?</i></p><p><b> </b></p><div class="flex flex-grow flex-col gap-3"><div class="min-h-[20px] flex flex-col items-start gap-4 whitespace-pre-wrap break-words"><div class="markdown prose w-full break-words dark:prose-invert light"><div class="flex flex-grow flex-col gap-3" style="margin-left: 40px;"><div class="min-h-[20px] flex flex-col items-start gap-4 whitespace-pre-wrap break-words"><div class="markdown prose w-full break-words dark:prose-invert light" style="text-align: left;"><p>The information generated by AI like ChatGPT can potentially negatively influence IP holders of information if the AI system is trained on copyrighted or proprietary information without permission from the IP holders. This can lead to the unauthorized use and dissemination of protected information, which can result in legal action against the AI system and its creators.</p><p>In addition, the learning and sharing aspects of AI systems can also pose a risk to IP holders. If an AI system is trained on a large dataset that includes copyrighted or proprietary information, there is a risk that the system will learn and replicate that information without permission. This can lead to the unauthorized use and dissemination of protected information, which can have negative consequences for the IP holder.</p><p>To address these issues, it is important for AI developers and users to be aware of copyright and IP laws, and to obtain proper permissions before using or training an AI system on protected information. This can help to ensure that the rights of IP holders are respected, while also allowing for the development and use of innovative AI technologies.</p></div></div></div><div class="flex flex-grow flex-col gap-3"><div class="min-h-[20px] flex flex-col items-start gap-4 whitespace-pre-wrap break-words"><div class="markdown prose w-full break-words dark:prose-invert light" style="text-align: left;"><p style="text-align: left;">So at this point it sounds like there's some risk to completely using AI for the creation of working software, but why would you think otherwise? After all, we're only in the very beginning to this technology. So what does this all mean and how will it impact us, as Product Managers when it comes to our career?</p><p style="text-align: left;"><b>So now, my opinions (in somewhat logical order):</b></p><ol style="text-align: left;"><li><b>So I've played around a bit with ChatGPT and while much of the response is good, it seems I sometimes get some crazy answers? </b>This is one of the downsides of using an LLM AI - for it to work with any degree of real success the data pool has to be extremely large - there's also a lot of costs involved in maintaining what's needed to support all the computational infrastructure. That means that small companies wanting to develop their own AI have a huge cliff to climb as a barrier to entry. Fortunately most of the current projects are funded by large corporate entities and/or public funding, with deep pockets - what we're left with is a somewhat "black box" input query that you can use to type in routine questions in parameters, mostly for free. Sounds cool right? Most of these same LLM AIs are pulling from the same publicly available web data stores - that means that while much of the data is good, there's also a lot of crap there that can influence what is produced as an answer. <b><br /></b></li><li><b>Can AI replace all the people involved in software delivery? </b>The answer is yes. It may not be perfect right now but give it a few iterations and it can completely replace all of us. Of course the 80/20 rule applies - in this case it has more to do with complexity and especially business complexity (few businesses can very simply define all the nuances involved in running system applications and when they do, there's often human decision making involved that may be difficult to replace with an AI). For very simple problem products, anyone with some technical experience can produce working software using AI. Heck, even someone without the experience, provided they us AI effectively, can simple ask AI to come up with the best method and apply it as an execution roadmap (I think success would be dependent on the individual(s) critical thinking skills). Where the 80/20 rule comes in comes back to complexity. Few problems are very simple and the order of complexity can cause clashes within what it created by AI - those conflicts are much harder to resolve as they often need a lot of human input (of course this could change - in the future we may use AI as the arbiter of any conflicts and this may become part of the process - but for now the scenario stands).</li><li><b>I don't understand AI at all - it seems like a toy?</b> Sounds like you haven't been paying attention - that's okay - we're all busy folk trying to do our jobs. You may not see the outcome of AI revolution until you need to look for your next job. If you haven't yet, go to <a href="https://chat.openai.com/auth/login" target="_blank">chat.OpenAi.com</a> and create a free account for ChatGPT. Throw in some prompts and see what happens. While it may seem a bit silly now, the next time you're tasked to come up with some basic software design input the parameters and see what comes out. Continue to refine your questioning until rhe responses are reasonable. I think you'll be amazed. There's a productivity benefit that's immediate that will translate into faster, cheaper and better releases. You need to be on the wagon if not driving it.<br /></li><li><b>Should you fear AI, especially when it comes to your job?</b> Well, we all handling things differently and "fear" is an rather subjective term. At minimum you should be prepared and using AI to increase your productivity and really, how competitive will you be when stacked up against someone who's has been using AI competently since the beginning? You need to be incorporating AI into your regular processes so you are familiar with its uses - it should become second nature. This is part of your growth requirements as a Product Manager or any other person involved in software production and delivery. Those tech people without these skills will be passed over more-and-more as time goes by. Those that are really good at using AI will excel.<br /></li><li><b>So who will be impacted the most?</b> Well, as the use of technology has expanded, there's been a trend in business for middle-management to shrink due to the need for technical people. Basically, the more technical you are, but better you fit into today's technology-driven business world. You'll see the elimination of middle-management roles as an end-game the longer you're involved. Of course there are always exceptions - there will come a point where middle-managers who are good at using AI will no longer need to be techie - but we aren't there yet. Oh, and to be clear, I consider Product Management to be square in middle management. <br /></li></ol><h2 style="text-align: left;">Next Steps</h2><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhxOB7QA53lxXUbOVX3L6UBbbAuNFUReOm4pPza8P4cAVSnMK1661EP-y6gzuWomkIzJ5rDqK-C6ULMIEkvBrzBHT5vpB6c0MSkcQiNRHCdXLSChK0obgasI7Ib0p7-Ht9bR4dx1GkjRWX1fcFPyVSwa9haOsmz44z_shOLOsXqPkUUXiCu4bswxOuaOA/s891/skynet.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="687" data-original-width="891" height="247" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhxOB7QA53lxXUbOVX3L6UBbbAuNFUReOm4pPza8P4cAVSnMK1661EP-y6gzuWomkIzJ5rDqK-C6ULMIEkvBrzBHT5vpB6c0MSkcQiNRHCdXLSChK0obgasI7Ib0p7-Ht9bR4dx1GkjRWX1fcFPyVSwa9haOsmz44z_shOLOsXqPkUUXiCu4bswxOuaOA/s320/skynet.jpg" width="320" /></a></div><p style="text-align: left;"><b>Okay, so we know that Skynet is coming and that my current Product Manager role is at risk. What can I do to remain relevant? </b></p><p style="text-align: left;">I've talked about steps to stay abreast of AI but now let's get
into why and how you become valuable to a company. Putting aside your
current role as a Product Manager as it's currently defined, you'll need to make changes in your thinking and skill-set stay in a reformatted Product Management job - what I'm getting at is that the role
will change and you need to change with it. Those changes are still a
bit up-in-the-air but, I can think of a few things you should
do to prepare:</p><ol style="text-align: left;"><li style="text-align: left;">Figure out a list of the most useful AI that can be used RIGHT NOW to make your life as a Product Manager better - you'll need to understand what's out there and how it's currently being used - assume that those competing for your role are already using them.</li><li style="text-align: left;">Stay abreast of what others are using. This may sound easy but we tend to live in an echo chamber when it comes to product management and tech in general. If you're working with React/Python teams, are you keeping up with other tech stacks or are you focused just on those that apply to your job? You need to understand not only what's being used but how it's being used.</li><li style="text-align: left;">Adjust your thinking to become use your critical thinking capabilities more than usual. I think that most successful Product Managers excel in critical thinking, but at the same time we tend to coast on the systems and processes that we've built to take care of our engineering team and to handle stakeholder demands. It's extremely important to break out of this complacency and start questioning the steps in your process with the idea of using AI utilities. For example, have you looked at Google Sheets in conjunction with a ChatGPT-powered extension?</li><li style="text-align: left;">Explore bias and how you can better form your routines to eliminate as much as possible by specifying your source datasets. Right now everything is wide-open as the data pool is very large - find ways of refining your datasets so they have less bias, rather than having a bunch of bad data influence your results.<br /></li><li style="text-align: left;">Be as specific as you can about context. Really context is everything and your ability to understand and define the context will be critical in producing good results. If you haven't been thinking about this, go through the exercise of writing a book or novel and develop a "setting" for what you're trying to do. I usually start by using a stream-of-consciousness model to produce a list, reorganize my list into some type of logical order the write as a narrative.<br /></li><li style="text-align: left;">Ensure that you are allowing for copyright and patent laws in your queries and routines. I typically do this in iterative passes as a check, then make adjustments. You don't want to run into an established business patent if you can help it. If it's critical to what you're doing then being forewarned is better than finding out through a lawsuit.</li></ol> </div><div class="markdown prose w-full break-words dark:prose-invert light" style="text-align: left;">I think that wraps up my current thinking on this but stay tuned. As the nature of AI continues to evolve much of what I've written above is subject to change, as are my opinions.</div><div class="markdown prose w-full break-words dark:prose-invert light" style="text-align: left;"> </div><div class="markdown prose w-full break-words dark:prose-invert light" style="text-align: left;">-- John Eaton <br /></div></div></div></div></div></div>John Eatonhttp://www.blogger.com/profile/00040215463441470962noreply@blogger.com0tag:blogger.com,1999:blog-5747686405891759983.post-74054433542781644092023-04-28T19:07:00.001-07:002023-05-04T07:19:20.978-07:00What's Important to a Career Product Manager<p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiWLCv-AcnQ4Dz8P6_Y_MH-3U4DiNRVWFueXqrsw2iVCS38CH3BwXFdC7LbScyYBkzqzrgt6_qVkVpTZzc9L7Bjq81mjn1uyhR0wC3nhyADwJofZTuFrl9qOFzYUH_Rb_ero7I6XWkIQGVS5wpCBQ2VeLatMhiblOK96VozF3tM3-fgQ7zD-WUYivN6fA/s422/promotion.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="372" data-original-width="422" height="282" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiWLCv-AcnQ4Dz8P6_Y_MH-3U4DiNRVWFueXqrsw2iVCS38CH3BwXFdC7LbScyYBkzqzrgt6_qVkVpTZzc9L7Bjq81mjn1uyhR0wC3nhyADwJofZTuFrl9qOFzYUH_Rb_ero7I6XWkIQGVS5wpCBQ2VeLatMhiblOK96VozF3tM3-fgQ7zD-WUYivN6fA/s320/promotion.png" width="320" /></a></div><p></p><p>My apologies for not posting more often, I realized recently that it's been a few years. It seems like I never have the time to develop my various ideas to a blog article - it's a bit of a Catch 22 - when we're very busy we think of a lot of things that would make great topics of conversation or ideal blog posts, but because we're busy, we never have time to form up those ideas and get them "on paper" so to speak.</p><p>I'm currently between jobs so I've had some time to reflect. I thought initially about relating my most recent experiences in role-seeking - however it seems like there's so many of my colleagues also looking that I didn't want to compound any anxiety they may be experiencing. It did get me thinking about Product Management as a career path and, as part of the job search, really thinking about what's important to me at this point in my life. This was a result of some soul searching about what I'm really looking for in a senior product role.<br /></p><p>I think that most of us, and for me at least, can segment a Product Management career into three general phases:</p><ol style="text-align: left;"><li>Learning Product Management as a Craft</li><li>Excelling to Maximize Salary</li><li>Relevancy as a goal</li></ol><p>Let's break this down a bit so you can understand where I'm coming from. </p><h2 style="text-align: left;">1. Learning Product Management as a Craft<br /></h2><p>I've been doing Product Management in some form as a professional for more than 20 years. When I first committed to this path, the term Product Management for most established companies had a fairly distinct definition - this was to garner information from stakeholders and write things up in a product specification, which would then be turned over to designers and engineers, expanded upon and executed. Everyone was pretty much doing this in a traditional waterfall pattern where the specifications were written for the next initiative concurrent in staggered timelines with the actual execution steps. Eventually I think most software-producing industries took the principles of Lean manufacturing and applied them into agile frameworks such as scrum or kanban, but much of the basic role of a product manager could still be defined as a "needs interpreter" that acts as a translator between the front-of-the-house stakeholders and engineering.<br /></p><p>I backed into product management somewhat accidentally - I had taught myself how to code ASP back in the 90's and began producing websites under Web 2.0, mostly as a side-gig (I had been a graphic designer and illustrator which let to actively marketing a comic book concept online for Bob Burden's Mystery Men, coinciding with the movie premier). I had met many people, now friends, through online user groups especially for collectibles (if you can't tell, I'm a proud geek), and it was one contact that developed into a friendship that has lasted to this day. In any case, my friend was working for an online auction site that competed with eBay (which had only been in existence for a couple of years at that point) and he pitched an idea to me - the problem he saw in the field was that companies with goods to sell had a hard time committing to online auctions because of the difficulty in getting product information into the auctions (there's still a somewhat complex form that has to be filled out every time an auction is created). This spawned the idea of Auctionworks, that eventually became the ecommerce provider Marketworks. He asked me to come in as I was pretty much the only person he knew that had web experience AND knew auctions like eBay - that's how I ended up being a co-founder.</p><p>Understand that at that point I had no idea what a Product Manager did, or even that it might be the role for me. Rather, as a co-founder I found myself doing any number of tasks just to get the company going (and once started, maintaining/improving). One of those tasks was to look across the interwebs and determine if there ere any other companies trying to do what we wanted to do - there were a couple of websites that provided copy-paste templates that could be used for auctions, but they were very nascent - what interested me more were sites that allowed for the inventory management of goods. We stumbled upon one site in particular that did an interesting job of aggregating live auction data across multiple platforms (so if you had auctions in eBay, Overstock, uBid and Yahoo, you could view our auctions from one consolidated portal) - we met with the IP holder and talked him into being the CTO of our new company and that's how we were able to rebrand his IP and get to market quickly. What followed were adjustments to this idea that grew into the Marketworks platform.<br /></p><p>Once the company started to grow it became really successful and we were able to make an important hire of a VP of Product Management that had a lot of experience. He's the one that suggested that I might like being a Product Manager - providing many materials to me and formalizing what I was doing with our development teams - this made the process much better and more consistent and really kicked off my career.</p><p>As years have gone by I've done gigs for start-ups, fortune 100 companies and everything in between. I've learned a few things.</p><ol style="text-align: left;"><li>You can be relatively successful based on crummy technology if you have a great marketing and sales approach. Of course you may have little or no growth, but for some achieving some baseline that pays the bills is enough. This premise has it's pitfalls but you'd be surprised at how many companies out there are running on some pretty crappy tech and still manages to pay its bills. <br /></li><li>The underlying tech has little to do with initial success, as long as it does something that's needed and it gets on the market fairly quickly. I've become very software agnostic - I don't care if it's php, .Net, Python, Java or anything else, as long as it can be built relatively quickly in small iterative steps, can be built with little effort bug free, and is easy to maintain.</li><li>People are more important than technology. You can have a few very competent, easy going people and produce a lot if they get along and have the ability to ask questions, listen and contribute towards accomplishing goals. Conversely, if the people involved are self-centered they're usually quite dysfunctional and you accomplish little.<br /></li><li>The underlying tech CAN have a lot to do with ongoing success. There are always trade-offs to any approach, both in the software used or developed; and in the hardware/cloud infrastructure. I've seen time and again, companies trying to limp along a business using tired old tech. Often it's much better to transition to a new tech platform rather than try to Band-Aid an existing (if you're fixing your software more than you're developing new software, you're probably experiencing this right now).</li><li>Learn as much as you can as fast as you can as a Product Manager - you need to be domain expert, psychoanalyst, evangelist and oracle (no, not the software giant).</li></ol><p>In any case, the first third or so of your career will be spent learning the craft. If you're lucky you'll get some training through Pragmatic Marketing or similar early in the process - this will help you a lot early on, but don't discount those courses later - I've found myself reinvigorated when taking additional courses, whether I thought to know the subject material or not.</p><h2 style="text-align: left;">2. Excelling to Maximize Salary</h2><p>At some point in your Product Management career you'll begin to either start realizing some decent roles with elevated pay, or wonder why you haven't and what you should do about it. I think most PdMs (Product Managers) fall into one of two categories - they either are 1.) very impatient about money, which tends to direct them into more managerial roles quickly, often making lateral moves outside of Product (it's difficult to get into senior product roles without the actual experience) OR 2.) they are more patient, preferring to truly sample what can be done with Product, savoring each experience for the fulfillment of producing something new. I tend to fall into that second category (and don't get me wrong, you can sort of do both to a certain extent). For me, I have a desire to become really good tactically as a Product Owner working directly with teams. I then worked with a team of product owners as their senior as a cohesive unit to deliver multiple components within the same product. Finally working more across initiatives that bridge across multiple products and components to deliver specific strategic product outcomes. Each of these are growth steps and helps to make you both competent and confident in your abilities.</p><p>I've seen many ups and downs trying to get to the point where I'm "comfortable" in my salary. You've probably heard of the Peter Principle:</p><p>The <b>Peter principle</b> is a concept in management developed by Laurence J. Peter, which observes that people in a hierarchy
tend to rise to "a level of respective incompetence": employees are
promoted based on their success in previous jobs until they reach a
level at which they are no longer competent, as skills in one job do not necessarily translate to another.</p><p>Another way of describing it is that you'll always get promoted to your highest level of incompetence. Your ability to learn quickly, or your ability to BS everyone around you (which can have consequences), or the amount of time your colleagues allow you to learn your role, will determine whether you succeed when you hit that level. Years ago, I was hired by a printer to be a graphic designer, purely on my portfolio which was made up of traditional illustration (like airbrush on board). I lasted 3 weeks when it was obvious I didn't have the experience to support my role. For my next job, I used the same portfolio and the short stint I did at my previous job for a similar position at another company. Fortunately, I was provided enough time to learn my role which was fairly technical, and eventually excelled - I was promoted to Art Director (department head in this case) but my boss admitted that when he first hired me, he almost fired me a few weeks in because I didn't have the experience to do the job. I was able to leverage some of my traditional illustration skills to get jobs out and fill in gaps in my technical know-how and that's ultimately what saved me.</p><p>So to me there's this tricky balance between being overly competent at your current job, enough to be promoted, but basically an initial failure at your newly promoted role, hopefully with enough support from your associates to learn and become competent. Of course there's a way to excel - that's by going over-and-above in your current role, learning as much as you can so you're more ready for the promotion. In the military that's called training - you do repetitive tasks until they can be accomplished with little thought - it becomes automatic. This, above all other reasons, is why you need to be inquisitive and get involved in things outside the workplace. What was the last product group meeting (like ProductCamp or a MeetUp) you attended locally? Did you explore the goings-on in the local REACTjs, Data Science or Engineering groups? If you did attend, where you there just for the free pizza or did you ask questions, take notes and really explore what was going on? You'll find yourself learning by osmosis, and even better, you'll pick up nuances from those groups that you might never encounter at your own company.</p><p>At some point you'll either be stymied because there isn't any level you can be promoted to, or become complacent. When this happens you're ready either to jump ship or to think about the third phase.</p><h1 style="text-align: left;">3. Relevancy as a Goal</h1><p>To be clear, this phase will happen to everyone - it's the point in your career where the money (and power if you're more that type) isn't the primary driver. Instead you want to proceed in a direction that has impact. Sometimes this is fairly selfish, for instance, to do something so your name is remembered in infamy or for personal goals besides wealth. For me, it's about doing something both relevant and that significantly improves the lives of others. To bring this back to the start of my post (regarding soul searching and determining what is REALLY important), it's become the driver for my transition into Health Tech. Most of the roles I've had in the past were all about making money/profits - often my role was tied in some way to the P&L through OKRs, bonuses, etc. Because of this my career growth was often bound to improving some entity's bottom line. Of course I've also been learning and doing interesting work so there's a two-way-street in benefit to both me and my employer. And don't get me wrong, I'm not condemning the for-profit practice, I'm just saying that I think there's more out there to be considered.</p><p>The ideal situation for me is to do something 1.) interesting so I'm learning, 2.) something that increases the value of a company or entity, and 3.) improves the lives of others. Recently I've both worked in Health Tech AND experienced an injury that involved surgery - really the first major health issue I've ever personally experienced. I knew the healthcare system in the US was bad, but really had no idea how bad. So my current job search is to find a role where I can do everything in the first sentence of this paragraph, applied to Healthcare as a goal. </p><p>In my last role, one of the primary drivers for me ended up being the results of the efficacy data - we supplied therapeutic treatments for chronic pain, and based on the observations of our providers AND the questionnaires completed by patients, we could prove that the therapies not only significantly reduced chronic pain in our patients, but also allowed them to be weaned off of pain medications like opiates - that empirical data, plus the testimonies and interviews of our patients and network of providers, really went a long way to making me feel good about the job I was doing and the services I spent a lot of time developing. There are many problems in healthcare in the US, but at least I wasn't contributing to them. This is relevant and impacts lives.</p><p>I'm not suggesting that Health Tech is for everyone, there are many other verticals where you could find something similar, relevancy in improving lives; for instance in building trades to make housing more affordable, in providing services that reduce hunger in children, producing software that produces a reduction in homelessness and poverty, the list goes on. Find something that makes you feel good about the work you're doing, help to build a good functioning team and you'll find great career satisfaction.</p><p>Last point, <b>"A journey of a thousand miles begins with a single step"</b> is a common saying that originated from a Chinese proverb. The quotation is from Chapter 64 of the Dao De Jing ascribed to Laozi. That's to say that even if you're still in the first or second career phase, it's never too early to start thinking about what you can do to nudge your career towards relevancy. In fact, the earlier you make it a goal, the more informed you'll be in prioritizing it and making it achievable. Here's to hoping everyone can do something relevant and significant that improves people's lives, this is something we can and should do.</p><p>-- John Eaton 2023.04.28<br /></p>John Eatonhttp://www.blogger.com/profile/00040215463441470962noreply@blogger.com0tag:blogger.com,1999:blog-5747686405891759983.post-12916502053757246222016-08-20T10:52:00.000-07:002016-08-20T10:52:34.997-07:00Quantifying Beauty in Your Product<div dir="ltr" style="text-align: left;" trbidi="on">
I presented at last years ProductCamp Atlanta in an ad hoc manner, using a recent, really fantastic article I had read regarding the <b><a href="https://medium.com/the-happy-startup-school/beyond-mvp-10-steps-to-make-your-product-minimum-loveable-51800164ae0c#.d2t1cb960" target="_blank">Minimum Lovable Product (MLP)</a></b>. If you haven't read this article I'd recommend that you do and specifically, how you can adopt the ideas into your own products. This article is my first attempt to expand on my thinking around the MLP idea - specifically, the idea of quantifying beauty and good design to achieve that MLP.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjpCP-sCyz9gDs53YKrjsVckTOdZ0xtSFPDyBbC81jwTbj71Ixc1OQW7rCd-B9Gis0PNSc_8DAzowzICc810NuIfvadxLNEgkHPnMlqsmYxzJVgJIu4iShsSwSIRGSnqB0FiY10DLH572ps/s1600/MLP.jpeg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="104" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjpCP-sCyz9gDs53YKrjsVckTOdZ0xtSFPDyBbC81jwTbj71Ixc1OQW7rCd-B9Gis0PNSc_8DAzowzICc810NuIfvadxLNEgkHPnMlqsmYxzJVgJIu4iShsSwSIRGSnqB0FiY10DLH572ps/s320/MLP.jpeg" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><a href="https://medium.com/the-happy-startup-school/beyond-mvp-10-steps-to-make-your-product-minimum-loveable-51800164ae0c#.e4bm2znne" target="_blank">From Lawrence McCahill "How to Build a Minimum Lovable Product"</a></td></tr>
</tbody></table>
<br />
First a short summary - the basic idea around <b>MLP</b> is to provide at least one feature that a user will really like as part of every release. Specifically the article linked above is for the start-up and and how by using a "Wow" feature you can garner fans of the application, thus creating users-as-evangilists who will spread-the-word for obvious results - putting that aside I think it's a great concept to put into everyday product planning. But to do this I think it's important to take into consideration good design and what quantifies a Lovable feature. That got me thinking about how we, as both users and providers of products, qualify or quantify a feature as useful, significant, well-designed or even beautiful. What gets us thinking "Wow! This is an awesome product!"<br />
<br />
I think there are ways of measuring the concepts of usefulness, significance and good-design - however that last which includes the definition of beauty, is the tough nut to crack. How does one quantify beauty? Isn't that in the eye of the beholder? How do some product Management professionals consistently create beautiful products while others don't? Is it a knack, simple luck or something more? To answer these questions I'm turning to one of the great product designers of the 20th century, design icon Alessi and designer Alberto Alessi.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiBewnrIHVR4aD1vd5UvM3U-K6EXwSZvBHPlPT312Nk8x36XiIE4FN4XOQZemKN7uiiGS4sSfK3_7j5Vz-56F-DVH6x7CugD2maEx__CsH9ogwfs9TDJtlsmcXuHfiuiZtK0KVH9xfK30s3/s1600/Alberto.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="289" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiBewnrIHVR4aD1vd5UvM3U-K6EXwSZvBHPlPT312Nk8x36XiIE4FN4XOQZemKN7uiiGS4sSfK3_7j5Vz-56F-DVH6x7CugD2maEx__CsH9ogwfs9TDJtlsmcXuHfiuiZtK0KVH9xfK30s3/s320/Alberto.png" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><a href="http://www.designcurial.com/news/alberto-alessi-interview-4297582/" target="_blank">From DesignCuriel interview 2014</a></td></tr>
</tbody></table>
<br />
<b><a href="http://www.fastcompany.com/3024313/masters-of-design-2009/biography-alberto-alessi" target="_blank">Alberto Alessi</a></b> is the eldest son of Carlo Alessi, who joined the Alessi design firm in the 70's. If you don't know anything about Alessi as a company then you haven't been paying attention - this venerable Italian design company hired some of the most prominent architects and designers of the 20's century and infused their designs into useful, yet beautiful objects and gadgets for the home and kitchen. They have been extremely successful in marrying useful objects with beautiful design. I focus on Alberto as he was recently interviewed by the <i>Wall Street Journal</i> and I found something in there that relates to this discussion - the formula he uses to determine if a product will be a best seller - and I thought this might be useful to help us quantify that MLP!<br />
<br />
<a href="http://www.wsj.com/articles/housewares-honcho-alberto-alessi-on-corkscrews-and-cars-1463675936" target="_blank"><i>From the WSJ article (May 19, 2016):</i></a><br />
<b>"I know a product will be a best seller when:</b> it receives a good score in my formula that rates prototypes on four parameters. First SMI - sensation, memory, imagination. This is what people mean when they say something is beautiful. Second is CL, communication language, which is the ability to communicate status or values. And the last two parameters are function and price."<br />
<br />
<br />
Taking this statement at face value and converting it to <b>"Knowing a Product will be Successful"</b>, lets make the assumption that the four components are equally weighted. If so, then function and price are only fifty percent of the equation and unfortunately, those tend to be the two factors that we as product managers seem to focus our efforts upon - providing function that customers will be willing to buy, at a price point that makes the company money and converts the user into a customer. This might explain why some products just fail to be adopted or capture much usage, even when the feature is good and the price is reasonable - I'm sure all of us have experienced this or if you haven't, at some point you will. Also, these are purely my own observations and interpretations of these component topics - basically the way I think about them and how they apply to the product management process and role in software development so please take them as opinions and observations.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhlxYDnT4M1OEAbY2I6yn1npr8LJGPa62Sb7OnXSUPWl02JHGDcJ5V5XOPBz_iBqIDncAAoSM0Rlm00jlO9Cg8TP2r95AAnxr_b0Kfu8ZbqYpv9Wgts0z3SZ3gTfmc4ItzaN7ScYbSVS5OA/s1600/KnowingSuccess.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="241" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhlxYDnT4M1OEAbY2I6yn1npr8LJGPa62Sb7OnXSUPWl02JHGDcJ5V5XOPBz_iBqIDncAAoSM0Rlm00jlO9Cg8TP2r95AAnxr_b0Kfu8ZbqYpv9Wgts0z3SZ3gTfmc4ItzaN7ScYbSVS5OA/s400/KnowingSuccess.jpg" width="400" /></a></div>
<h2 style="text-align: left;">
Knowing a Product will be Successful</h2>
<br />
<br />
<br />
<b>SMI - sensation, memory, imagination or the notion of beauty</b><br />
I like this breakdown because I think it helps to visualize they why of beauty. It may not encapsulate the entire notion and perhaps nothing does, but as product management professionals we tend to work better and become more successful using things that are measurable. At this point I'm going to take some guesses at what Alessi means by these three components, or at least project how I think these three bits are used to define beauty or fine design.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiCmz7MHr6Y1oDkUWnX4NGidGc7zk3R07ZfLeSjsZXq1IoMyb4XOeUEeSMBDOWmEnih22dxy9mleDRVemUvWiwVbEuFqou9QyTvdmsDpfJkQCBC4Q9rOp5J8vRS1qsz_ej0UKsPm5ZaA1Ur/s1600/SMI.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="242" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiCmz7MHr6Y1oDkUWnX4NGidGc7zk3R07ZfLeSjsZXq1IoMyb4XOeUEeSMBDOWmEnih22dxy9mleDRVemUvWiwVbEuFqou9QyTvdmsDpfJkQCBC4Q9rOp5J8vRS1qsz_ej0UKsPm5ZaA1Ur/s400/SMI.png" width="400" /></a></div>
<br />
<ul style="text-align: left;">
<li><b>Sensation </b>- In hard goods this could be tactile "feel" of an object, the weight or heft, the smell, the proportions, color - any of those elements that are picked up by the senses. For software, I think this applies more to usability, use of color, and proportion. This is that area where we always want to assign part of the budget (usually just called design), but becomes one of the first things that's deferred or eliminated when the budget gets tight. Instead of ending up with something that's easy-on-the-eyes and easy to use, we end up making it "passable" - I blame the MVP (Minimum Viable Product) for most of the poor design you see out there. Instead, successful companies are starting with the concepts of good design and usability and developing outwardly from there. If usability and design are not part of your process then you probably fall into that category where you don't understand why the feature you just released is failing in the adoption phase.</li>
<li><b>Memory</b> - this has to do with repetition and the familiar use of objects in hard goods. It also plays into design in the way our brains are wired and the way we're trained to do mechanical things (why important mechanical motions are on the right - because most of us are right handed). In software this is often associated with heuristics - the way we learn to use something and how patterns make things easier to learn. In the western world most writing starts upper left and moves left to right and then down a page. Therefore, if you put the most important or most frequently used actions in the upper left corner it becomes more intuitive for the user. We think of this as usability that goes to the heart of how people learn - for most software development shops heuristics have an implied use in design but isn't called out as a distinct software design necessity - if you're doing this consider yourself ahead of the curve.</li>
<li><b>Imagination</b> - I love hearing the phrase "Wow this is different and very cool!" - and I think this is where Imagination comes into play. There's a thought that there are only about 100 story plots - several books on this topic and how everything is repeated. When was the last time you saw a movie and thought "Wow! That was different (in a good way)"? I think that this is the toughest of these three criteria to crack, especially in software, as it seems a bit contrary to the other two and to me is very risky. An example would be to introduce some new widget that doesn't fall into the Sensation or Memory paradigm. I think when Flash first started to be used in web design it had this type of impact - lot's of "Wow!" but, due to the vagaries of licensing and getting it to work in all browsers, has fallen a bit to the wayside - like I said, very risky. I also think this is the most blue-sky of the three topics and it has the most room for us to come up with something. Even small uses of Imagination could provide big, big wins.</li>
</ul>
<br />
<div class="separator" style="clear: both; text-align: center;">
<b><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgkzChFmWEcZ3lD0yoalgzuzGKB9hi4wFQRw549TCtlYTfaM7dWFgedtdeXZMWapQlkgOECcyZyq-TWHhjvIksuu5h2QqL14ZaA5aY3BmqUPYLUl6Ed5Q0_TS6G41p5otvsgn_65wIL3m68/s1600/CI.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="228" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgkzChFmWEcZ3lD0yoalgzuzGKB9hi4wFQRw549TCtlYTfaM7dWFgedtdeXZMWapQlkgOECcyZyq-TWHhjvIksuu5h2QqL14ZaA5aY3BmqUPYLUl6Ed5Q0_TS6G41p5otvsgn_65wIL3m68/s400/CI.jpg" width="400" /></a></b></div>
<br />
<br />
<b>CL - communication language, the ability to communicate status or values.</b><br />
With this topic we get into the conversation of why - why use the product or what problem does it solve and how does that come across to the user? Also, is there any intrinsic value to the use of a brand to increase demand or value? If so, how are these factors communicated - in hard-goods the Louis Vuitton brand will imply a certain value and exclusivity - does that really translate into quality? If so, how does this translate into software? It's my opinion that brands don't equate to better software so the comparison to hard-goods fails a bit. Instead I think the topic of Communication Language has more to do with delivery and the way a product solves a problem. I also think that in good software design this often falls to the idea of simplicity and explicit use. Let me explain.<br />
<br />
One of the reasons that mobile apps are so successful is due not to the advanced features offered or to the breadth of features, but rather to the simplicity of what problem is being fixed or addressed. Very simple apps that do one or two things get adopted quickly and are used frequently. The best apps are recreated by the smart-phone manufacturers and incorporated into the basic phone functions. A good example is how a smart phone developed from the consolidation of many devices into one - carry a digital camera, a palm device and a phone? How about one device for all three? Oh and make it very simple and reliable to use and you have that first generation smart phone. Add in SMI as defined above and you have the iPhone. It's the simplicity of use that ultimately wins and not the sophistication of features through complexity. Getting back to Communication Language - the simpler the feature, the easier it is to communicate its value.<br />
<br />
So how to put these ideas all together and why? First an observation - most of the successful product management professionals I know marry two different disciplines - the analytical side of tactical and strategic execution and the visionary side of choosing good approaches to problem solving. The former is much more a left-brain function of determining the best, formulaic way to solve a problem - your basic logical thinking. The latter is more of a right-brain function of coming up with new patterns to invent different ways to approach a problem or seeing that a problem is an opportunity to be creative in problem solving. I think that most product managers tend to be right in the middle of these two disciplines at a fairly good balance while most analyst types are towards the left-brain side.<br />
<br />
I'm sure all of us have worked with really good product, requirements or business analysts who were quite competent in their jobs, but for some reason really fail when they attempt the leap to product management. I think that those that can't quite make it into the larger context of product management (strategy, roadmaps, big picture thinking, inventiveness, out-of-the-box thinking, just more context) are a bit overly focused on execution and tactics - when they are asked to be more inventive they have a hard time transitioning. Note that it's not to say that they are inferior in any way - it's just an observation and why I think using this method offered up by Alessi can be useful, by narrowing down the elements until they are more manageable and quantifiable, those of us who are more left-brain can transition into a more balanced role - or at minimum reduce the risk while we get used to a role with more context.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj7R6RFhipD2jU0ytHq7NhFO-QLTn_P4zOtMnN8TqWcGdU620iRV2PX-AaJWfRRj5W3eUfszoEXYkV3yNuLvhj2zcohOYyF2WSG2KB8S1x642GGO-6GQLU5ubUFlAa1MAV39dBFUPbEkHxV/s1600/FP.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="247" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj7R6RFhipD2jU0ytHq7NhFO-QLTn_P4zOtMnN8TqWcGdU620iRV2PX-AaJWfRRj5W3eUfszoEXYkV3yNuLvhj2zcohOYyF2WSG2KB8S1x642GGO-6GQLU5ubUFlAa1MAV39dBFUPbEkHxV/s400/FP.jpg" width="400" /></a></div>
<br />
<br />
<b>Finally, on Function and Price</b><br />
There's quite a bit already written about Function and Price so forgive me if I gloss over this a bit. To really understand this well I'd recommend the Pragmatic Marketing courses on Foundation, Focus, Build and Price. I think the most important thing to recognize is that they are only fifty percent of the entire equation.<br />
<br />
So what to do with all this information? I think that a good starting point is first recognizing that there is more to product design than solving a problem. Second, if you place this chart on a wall when considering your product's attributes you can use it as a bit of a check. Most of us will already have "Function" and maybe "Price" determined, but how about SMI and CL? If we're lucky enough to have a designer onboard he may have contributed to Sensation and Memory, but how about Imagination? Is there something there that is compelling? Can you apply "cool" or even "nifty" to the product description? If "Cool" is there, do you also have a grade for Sensation and Memory or is that where it falls flat? Each of the SMI score components should be weighted equally and combined make up 25% of the overall score. The same exercise should be applied to all four quadrants and from the discussion you will see potential pitfalls, risks or where you should be focusing your attention.<br />
<br />
Its not to say that this method is the best - I'd welcome comments about how you each address the idea of achieving success. I just wanted to start the discussion and frankly I like this approach. Comments?<br />
<br />
-- John<br />
<br />
<br />
<br />
<br /></div>
John Eatonhttp://www.blogger.com/profile/00040215463441470962noreply@blogger.com0Atlanta, GA, USA33.7489954 -84.387982433.3266004 -85.0334294 34.1713904 -83.7425354tag:blogger.com,1999:blog-5747686405891759983.post-85564788507665368252015-07-27T06:19:00.000-07:002015-07-27T06:20:01.013-07:00<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEije6TKD_ri4aT3Q4wcl0Fii8gyleHADNQuWfdn1DXxwj86PYrjOOkNWJlfyoPw6LHP_qfXoVZGn7gqnfq8GDi5mLLJ-HRdfjl8zaSRoZuPw1aRC1ndtlIDWJ_e0Lm6G49qBjH8fxCYNoGO/s1600/ProductCamp.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="221" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEije6TKD_ri4aT3Q4wcl0Fii8gyleHADNQuWfdn1DXxwj86PYrjOOkNWJlfyoPw6LHP_qfXoVZGn7gqnfq8GDi5mLLJ-HRdfjl8zaSRoZuPw1aRC1ndtlIDWJ_e0Lm6G49qBjH8fxCYNoGO/s400/ProductCamp.png" width="400" /></a></div>
<br />
<br />
Just a quick note. As many of you know, I'm involved in ProductCamp Atlanta this year as a volunteer. I've been working to push existing ProductCamp videos into a YouTube Channel and thought that you might be interested. You can find the Channel here:<br />
<br />
<a data-mce-href="https://www.youtube.com/channel/UCE5LiS_HKAgLl4nS2qrRKpA" href="https://www.youtube.com/channel/UCE5LiS_HKAgLl4nS2qrRKpA">https://www.youtube.com/channel/UCE5LiS_HKAgLl4nS2qrRKpA</a><br />
<br />
(also published to LinkedIn)<br />
<br />
-- John</div>
John Eatonhttp://www.blogger.com/profile/00040215463441470962noreply@blogger.com1Georgia Institute of Technology, North Ave NW, Atlanta, GA 30332, USA33.7756178 -84.39628499999997833.7492213 -84.436625499999977 33.802014299999996 -84.355944499999978tag:blogger.com,1999:blog-5747686405891759983.post-52189680499926031772015-05-12T20:25:00.000-07:002015-05-12T20:25:41.519-07:00Adapting to Change<div dir="ltr" style="text-align: left;" trbidi="on">
<h2 class="center">
Adaptation is Essential</h2>
<h2 class="center">
<img alt="" class="center" data-mce-src="https://media.licdn.com/mpr/mpr/p/4/005/0b4/2a2/15947b0.jpg" height="708" src="https://media.licdn.com/mpr/mpr/p/4/005/0b4/2a2/15947b0.jpg" width="588" /></h2>
<h3>
Stating the Obvious</h3>
“The measure of intelligence is the ability to change.”<br />― Albert Einstein<br />
<br />
It
may sound obvious, but in healthy systems things change often and
frequently. The fact that change exists is less important than how we
respond to change. I've worked for several companies that have a poor
response to change - it's both treated negatively and the unfortunate
requesting the change is treated as a pariah. I've worked for other
companies that embrace change as opportunity, treating change as a
normal consequence of doing business in an ever changing world.<br />
<br />
So
what am I writing about here? I'd like to explore how you can help
change the attitude of your team regarding change (so it's more
positive) and review a few methods to embrace change for a better
outcome. I'm using the larger context of "company" in what follows as I
believe for this stuff to work it needs to spread across the enterprise.
However, what I'm going to write about can apply at the team or macro
level too.<br />
<br />
<strong>First we should establish a list of assumptions:</strong><br />
<ol>
<li>Businesses
that are successful, with very few exceptions, are constantly dealing
with change, whether in the market, through competition or ideally due
to company innovation.</li>
<li>How a business responds to the changes listed above, can often have a critical impact to company success.</li>
<li>Many times changes are external, a response is required and the speed of that response becomes critical to success.</li>
<li>With
software development and new technologies changing the market landscape
so quickly, multiply everything above by several factors.</li>
</ol>
<h3>
Don't be Oblivious</h3>
"I put a dollar in one of those change machines. Nothing changed."<br />- George Carlin<br />
<br />
Before
talking about change I think we first need to have a frank discussion
about why companies have such a hard time recognizing that they need to
change. I've found that there's a very bad trait that becomes inherent
in some companies that are very successful - it's the fallacy of
success. What happens is that for whatever reason, a company is
extremely successful (often through timing and luck and NOT through
skill) regardless of questionable practices, to the point that the
executive management doesn't take criticism well if at all. This is
exhibited when employees recognize inherent flaws or risks in the
business, the information is disseminated and consequently ignored. It
becomes a "we can do no wrong" attitude that can actually be quite
self-fulfilling as long as the market doesn't change, or there are
little to no external forces exerted on the company's success. Because
of the success management argues that their initial plan is doing well
so why change? These are companies that are often blindsided - when
change happens they're left in the proverbial creek without a paddle.<br />
<br />
It
was this mindset that propelled many a start-up during the dot-com era -
pretty much unlimited funding, a good idea and huge growth in numbers
led many companies to expand quickly with little idea of revenue
acquisition. It was all about registrations and not real users. Think
about how many of those companies have survived, or better yet, how many
of those companies you remember that were hugely successful, only to
wither on the vine or become acquisition targets with little benefit to
the founders on exit. I have three boxes of swag in my basement - they
are full of stuff like frisbees, squeeze toys, pens, mouse pads - you
name it and I have it. I acquired this stuff at any number of gigantic
conferences (remember Internet World?) and not one of those companies is
still around. Someday I hope someone will be interested in that stuff
as a research project - or I may just take it to recycling...<br />
<br />
Before exploring change factors, we should consider company culture.<br />
<h3>
Habits</h3>
“We first make our habits, then our habits make us.”<br />― John Dryden<br />
<br />
Just
as the example above provides some insight about how a company can
fail, there are some very good habits that can lead a company from
moderate to great success. In most cases, these companies are very good
at dealing with change. For it to work, the company's corporate culture
has to drive the ideal of change and responsiveness from the top down
through example. This needs to be reinforced via company core values,
communication and message delivery style; and every level of the company
needs to buy into the idea. It also needs to be an automatic response -
more good habit than reflex, to proactively look for the opportunity to
any change rather than finding reasons not to change. Not that you
should jump every time someone says frog, but you have good processes to
evaluate change with a managerial support structure to effectively deal
with it.<br />
<br />
Too often business have complex change control
procedures that act as a barrier to change rather than determining if
change is first necessary and second worthwhile. Instead its become the
norm to only take on change after some upper level management type has
"signed off" - more as a CYA technique than as a considered opinion.
This often results in someone holding the bag, so to speak, if things
"Go South." You'll often see old-school management types keep some
unqualified sycophant around so any big problem can be pinned on that
unfortunate soul so he/she can be sacrificed if needed.<br />
<br />
“It's too late to be studying Hebrew; it's more important to understand even the slang of today.”<br />― Henry David Thoreau, Walking<br />
<h3>
Adaptation</h3>
“You
must be shapeless, formless, like water. When you pour water in a cup,
it becomes the cup. When you pour water in a bottle, it becomes the
bottle. When you pour water in a teapot, it becomes the teapot. Water
can drip and it can crash. Become like water my friend.”<br />― Bruce Lee<br />
<br />
So
how to be successful or at least survive change? It's called adaptation
- just as some cultures found that survival could be found in
assimilation, it's often necessary to consume a change rather than
spitting it out. This is most important when confronted by an external
pressure, like a change in the market or the presence of a new,
disruptive technology. I've always liked that term "Go with the flow"
but not in the original context (which as I recall was more of a
concession to events), but rather as the idea of adding your voice to
the chorus to make beautiful music! Take the positive aspects as
opportunity and you can survive devastation - you may get bruised a bit
along the way but even those bruises can be turned into learning
experiences. If the task looks insurmountable, try breaking it up into
smaller, more manageable pieces. Remember, a journey of a 1000 miles
begins with one step!<br />
<br />
A good recent example of adaptation is the
current incarnation of used-to-be internet giant AOL. The platform has
lost most of its user-base and has become little more than a landing
page - however due to brand recognition and fairly-decent news feeds,
the portal still gets a worthwhile number of visitors, which equate to
eyeballs and advertizing revenue. The company adapted and parlayed that
adaptation into a $4B+ acquisition by Verizon - not bad!<br />
<h3>
Being Nimble</h3>
“It is not the strongest or the most intelligent who will survive but those who can best manage change.”<br />― Charles Darwin<br />
<br />
Being
nimble is a bit different from being adaptable - in my mind being
nimble is defined by your ability to respond to change quickly. If your
company has a host of processes you have to go through to make even
small changes, then you're probably always going to be behind in
execution. Somehow, you have got to spearhead an effort to get things
into production environments quicker, remembering the resource triangle
(cost, time and quality) and determining what a release can take
advantage of to increase speed (hopefully it's cost and not quality, but
at times quality can be relaxed - it's all about what you're trying to
get out quickly).<br />
<br />
To illustrate this idea, how many of you have
heard about garage-style start-ups who have pushed what amounts to beta
software into the public for the sake of speed. If they are lucky,
they'll gain a ton of market share and not lose it due to crappy
quality. These start-ups are much more nimble than most large corporate
entities - while those are still writing requirements and making
marketing plans, the smaller companies are scooping up all the
customers, effectively diminishing the pool of fish .<br />
<br />
"When you're finished changing, you're finished."<br />- Ben Franklin<br />
<h3>
Change Can Be Painful</h3>
“We are kept keen on the grindstone of pain and necessity.”<br />― H.G. Wells, The Time Machine<br />
<br />
So
what's the plan, man? How, with all this opportunity hanging around
there can we best use what's happening to be successful, and make great
software? This is fairly old-school, but I recommend as a first step to
perform the SWOT exercise. I won't go into too much detail about how to
do that - it can be a topic on its own and there's plenty of information
available online. You're basically coming up with an analysis of the
company's current state and how it stands in its current environment.
Please look it up and it will give you some ideas. I do have a
recommendation - use the largest pool that you can to come up with your
SWOT - that includes executives, middle-management, your core employee
pool and anyone else that half-way knows your business, even vendors.
Make sure you are clear with everyone that there are no wrong answers
and that there will be no repercussions to those who express honest
opinions. This needs to be a frank look in the mirror.<br />
<br />
I remember
the first SWOT I attended. I had never heard of the technique, which was
brought to one of my first companies by the COO who was a GE alumni. We
got the entire company (about 50 employees) all together in an
auditorium, explained what we were about to do and then proceeded to
come up with an honest assessment. From that analysis, we had a
foundation that we integrated into our company plans, software and sales
roadmap, and initiatives and thinking of our leadership - shake well
and you have something worthwhile. We ended up being extremely
successful and became profitable within 3 years, surviving the dot-bomb.
I won't attribute our success to the on-paper results of the SWOT,
rather to the interaction that helped to shape our habits, creating a
consistent message across all levels of the business, and aligning a
program that considered all aspects: strengths, weaknesses,
opportunities and threats. We were also very adaptable and nimble (it's
also how I got my first taste of agile software processes and
frameworks). Not to say it was all gravy - there were certainly mistakes
made, however we were fairly good at learning from those mistakes,
improving our business and processes; and having some fun along the way.
Thanks for reading.<br />
<br />
-- John<br />
<br />
"Adaptability is not imitation. It means power of resistance and assimilation."<br />- Mahatma Gandhi<br />
<br />
(also posted to LinkedIn)</div>
John Eatonhttp://www.blogger.com/profile/00040215463441470962noreply@blogger.com3Atlanta, GA, USA33.7489954 -84.387982433.3266004 -85.0334294 34.1713904 -83.7425354tag:blogger.com,1999:blog-5747686405891759983.post-67840512348188991082015-05-04T07:14:00.000-07:002015-05-04T07:15:22.335-07:00Writing a White Paper<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjKx5aQ-iTPrGgVkOJQxS_L9diOaqMSuYXCt0cMdM9xYFNEcm0XNhVyy8WO6a2a_V_pSWYwuomjgeAoqPPOGk9Sui7r1viYu8kLoLg83H0dPOGjDXUmQ-jLGprht6xCYP9uTknWr2vB6msS/s1600/WhitePapers.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjKx5aQ-iTPrGgVkOJQxS_L9diOaqMSuYXCt0cMdM9xYFNEcm0XNhVyy8WO6a2a_V_pSWYwuomjgeAoqPPOGk9Sui7r1viYu8kLoLg83H0dPOGjDXUmQ-jLGprht6xCYP9uTknWr2vB6msS/s1600/WhitePapers.jpg" /></a></div>
<h2 class="center" style="background-color: white; border: 0px; box-sizing: border-box; color: #333333; font-family: Helvetica, Arial, sans-serif; font-size: 28px; font-stretch: inherit; font-weight: normal; line-height: 34px; margin: 0px 0px 30px; padding: 0px; text-align: center; vertical-align: baseline;">
</h2>
<h2 class="center" style="background-color: white; border: 0px; box-sizing: border-box; color: #333333; font-family: Helvetica, Arial, sans-serif; font-size: 28px; font-stretch: inherit; font-weight: normal; line-height: 34px; margin: 0px 0px 30px; padding: 0px; text-align: center; vertical-align: baseline;">
Writing a White Paper</h2>
<div style="background-color: white; border: 0px; box-sizing: border-box; color: #4d4f51; font-family: Helvetica, Arial, sans-serif; font-size: 16px; font-stretch: inherit; line-height: 24px; margin-bottom: 30px; padding: 0px; vertical-align: baseline;">
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.</div>
<div style="background-color: white; border: 0px; box-sizing: border-box; color: #4d4f51; font-family: Helvetica, Arial, sans-serif; font-size: 16px; font-stretch: inherit; line-height: 24px; margin-bottom: 30px; padding: 0px; vertical-align: baseline;">
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.</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh7mLZUvMYteeN29Q1e05TQBzU2BM07BAe41yAjttDerZXA-otdJFp4KiKBzRSOq-kLbFn9sBu2tHUvZdCpVQ9t0fX8VIzKjXxlC24p4ue7fD90Q8mUlMKG0DLTV0tfMylO3UW28gBIDn5F/s1600/WhitePaperFanned.gif" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="425" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh7mLZUvMYteeN29Q1e05TQBzU2BM07BAe41yAjttDerZXA-otdJFp4KiKBzRSOq-kLbFn9sBu2tHUvZdCpVQ9t0fX8VIzKjXxlC24p4ue7fD90Q8mUlMKG0DLTV0tfMylO3UW28gBIDn5F/s640/WhitePaperFanned.gif" width="640" /></a></div>
<div style="background-color: white; border: 0px; box-sizing: border-box; color: #4d4f51; font-family: Helvetica, Arial, sans-serif; font-size: 16px; font-stretch: inherit; line-height: 24px; margin-bottom: 30px; padding: 0px; vertical-align: baseline;">
<br /></div>
<div style="background-color: white; border: 0px; box-sizing: border-box; color: #4d4f51; font-family: Helvetica, Arial, sans-serif; font-size: 16px; font-stretch: inherit; line-height: 24px; margin-bottom: 30px; padding: 0px; vertical-align: baseline;">
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:</div>
<ol style="background-color: white; border: 0px; box-sizing: border-box; color: #4d4f51; font-family: Helvetica, Arial, sans-serif; font-size: 16px; font-stretch: inherit; line-height: 24px; margin: 0px 0px 30px 40px; padding: 0px; vertical-align: baseline;">
<li style="border: 0px; box-sizing: border-box; font-family: inherit; font-stretch: inherit; font-style: inherit; font-variant: inherit; font-weight: inherit; line-height: inherit; margin: 0px 0px 5px; padding: 0px; vertical-align: baseline;">White papers as independent data analysis, correlation and theory using deductive reasoning and making sense of it all.</li>
<li style="border: 0px; box-sizing: border-box; font-family: inherit; font-stretch: inherit; font-style: inherit; font-variant: inherit; font-weight: inherit; line-height: inherit; margin: 0px 0px 5px; padding: 0px; vertical-align: baseline;">White papers as proof using inductive reasoning to defend a hypothesis</li>
<li style="border: 0px; box-sizing: border-box; font-family: inherit; font-stretch: inherit; font-style: inherit; font-variant: inherit; font-weight: inherit; line-height: inherit; margin: 0px 0px 5px; padding: 0px; vertical-align: baseline;">The latest trend, doing internal research to find information defending projects.</li>
</ol>
<div style="background-color: white; border: 0px; box-sizing: border-box; color: #4d4f51; font-family: Helvetica, Arial, sans-serif; font-size: 16px; font-stretch: inherit; line-height: 24px; margin-bottom: 30px; padding: 0px; vertical-align: baseline;">
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?</div>
<div style="background-color: white; border: 0px; box-sizing: border-box; color: #4d4f51; font-family: Helvetica, Arial, sans-serif; font-size: 16px; font-stretch: inherit; line-height: 24px; margin-bottom: 30px; padding: 0px; vertical-align: baseline;">
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...</div>
<div style="background-color: white; border: 0px; box-sizing: border-box; color: #4d4f51; font-family: Helvetica, Arial, sans-serif; font-size: 16px; font-stretch: inherit; line-height: 24px; margin-bottom: 30px; padding: 0px; vertical-align: baseline;">
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).</div>
<div style="background-color: white; border: 0px; box-sizing: border-box; color: #4d4f51; font-family: Helvetica, Arial, sans-serif; font-size: 16px; font-stretch: inherit; line-height: 24px; margin-bottom: 30px; padding: 0px; vertical-align: baseline;">
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.</div>
<div style="background-color: white; border: 0px; box-sizing: border-box; color: #4d4f51; font-family: Helvetica, Arial, sans-serif; font-size: 16px; font-stretch: inherit; line-height: 24px; margin-bottom: 30px; padding: 0px; vertical-align: baseline;">
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.</div>
<div style="background-color: white; border: 0px; box-sizing: border-box; color: #4d4f51; font-family: Helvetica, Arial, sans-serif; font-size: 16px; font-stretch: inherit; line-height: 24px; margin-bottom: 30px; padding: 0px; vertical-align: baseline;">
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.</div>
<div style="background-color: white; border: 0px; box-sizing: border-box; color: #4d4f51; font-family: Helvetica, Arial, sans-serif; font-size: 16px; font-stretch: inherit; line-height: 24px; margin-bottom: 30px; padding: 0px; vertical-align: baseline;">
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.</div>
<div style="background-color: white; border: 0px; box-sizing: border-box; color: #4d4f51; font-family: Helvetica, Arial, sans-serif; font-size: 16px; font-stretch: inherit; line-height: 24px; margin-bottom: 30px; padding: 0px; vertical-align: baseline;">
-- John<br />
<br />
(also published to LinkedIn)</div>
</div>
John Eatonhttp://www.blogger.com/profile/00040215463441470962noreply@blogger.com5Atlanta, GA, USA33.7489954 -84.387982433.3266004 -85.0334294 34.1713904 -83.7425354tag:blogger.com,1999:blog-5747686405891759983.post-52466137125181996142015-03-27T06:03:00.002-07:002015-03-27T06:03:19.145-07:00The Fallacy of Converting Requirements into User Stories<div dir="ltr" style="text-align: left;" trbidi="on">
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhaQgUURwauJIN5cLqRqVP2JdfqiCsoxN0gdKgy0urloQgXId2It89cWADyMjItlx2fNUwPiL9oCQ3eNdfG7SZRW4pSfyg1wn3wR7fp-pSZbpXPdCCQUq1KoQdYhgvJf_aJN0OKOAWO26g0/s1600/scrum-cartoon-600x450-100517984-primary-idge.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhaQgUURwauJIN5cLqRqVP2JdfqiCsoxN0gdKgy0urloQgXId2It89cWADyMjItlx2fNUwPiL9oCQ3eNdfG7SZRW4pSfyg1wn3wR7fp-pSZbpXPdCCQUq1KoQdYhgvJf_aJN0OKOAWO26g0/s1600/scrum-cartoon-600x450-100517984-primary-idge.jpg" height="240" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Borrowed from <a href="http://www.itworld.com/">www.itworld.com</a></td></tr>
</tbody></table>
<h2 style="margin-bottom: 30px; text-align: left;">
<span style="color: #4d4f51; font-family: Helvetica, Arial, sans-serif;"><span style="line-height: 24px;">The Fallacy of Converting Requirements into User Stories</span></span></h2>
<div style="color: #4d4f51; font-family: Helvetica, Arial, sans-serif; font-size: 16px; line-height: 24px; margin-bottom: 30px;">
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.</div>
<h3 style="color: #333333; font-family: Helvetica, Arial, sans-serif; font-size: 20px; font-weight: normal; line-height: 26px; margin-bottom: 30px;">
The story of Excess</h3>
<div style="color: #4d4f51; font-family: Helvetica, Arial, sans-serif; font-size: 16px; line-height: 24px; margin-bottom: 30px;">
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).</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhqSjkjUn8jxz2OAl5tYBwxnzw_EQ15mgm0c982C5B6jfdOscHkn8g6Avi4MulK2NODUuHUiqMFIa1uedooAOPQhyphenhyphenbS324J02UkYLVlte15wzLnSv0Eq_93iSe8OMjJMLrt8rOqzjEbc7zH/s1600/Requirements.gif" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhqSjkjUn8jxz2OAl5tYBwxnzw_EQ15mgm0c982C5B6jfdOscHkn8g6Avi4MulK2NODUuHUiqMFIa1uedooAOPQhyphenhyphenbS324J02UkYLVlte15wzLnSv0Eq_93iSe8OMjJMLrt8rOqzjEbc7zH/s1600/Requirements.gif" height="320" width="315" /></a></div>
<div style="color: #4d4f51; font-family: Helvetica, Arial, sans-serif; font-size: 16px; line-height: 24px; margin-bottom: 30px;">
<br data-mce-bogus="1" /></div>
<div style="color: #4d4f51; font-family: Helvetica, Arial, sans-serif; font-size: 16px; line-height: 24px; margin-bottom: 30px;">
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.</div>
<h3 style="color: #333333; font-family: Helvetica, Arial, sans-serif; font-size: 20px; font-weight: normal; line-height: 26px; margin-bottom: 30px;">
So what went wrong, exactly? </h3>
<ol style="color: #4d4f51; font-family: Helvetica, Arial, sans-serif; font-size: 16px; line-height: 24px; margin-bottom: 30px; margin-left: 40px;">
<li style="margin-bottom: 5px;">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.</li>
<li style="margin-bottom: 5px;">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).</li>
<li style="margin-bottom: 5px;">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.</li>
</ol>
<h3 style="color: #333333; font-family: Helvetica, Arial, sans-serif; font-size: 20px; font-weight: normal; line-height: 26px; margin-bottom: 30px;">
So what is a better way?</h3>
<div style="color: #4d4f51; font-family: Helvetica, Arial, sans-serif; font-size: 16px; line-height: 24px; margin-bottom: 30px;">
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?</div>
<ol style="color: #4d4f51; font-family: Helvetica, Arial, sans-serif; font-size: 16px; line-height: 24px; margin-bottom: 30px; margin-left: 40px;">
<li style="margin-bottom: 5px;">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.</li>
<li style="margin-bottom: 5px;">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.</li>
<li style="margin-bottom: 5px;">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).</li>
<li style="margin-bottom: 5px;">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.</li>
<li style="margin-bottom: 5px;">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.</li>
</ol>
<div style="color: #4d4f51; font-family: Helvetica, Arial, sans-serif; font-size: 16px; line-height: 24px; margin-bottom: 30px;">
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.</div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEicOg5RVzXRm3cYW3MZedPE97CpBxDREq6G-08xffo_2500IdA-TRaMaYDUR6DVYoQyUZH-6ejwtL3H12NfvpNcvvS588ZS9op858RCQx29vs_d2pKJ7_SzKEMfPr4AIu1A17osWOh5DT3Y/s1600/user+stories+vs+doc.PNG" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEicOg5RVzXRm3cYW3MZedPE97CpBxDREq6G-08xffo_2500IdA-TRaMaYDUR6DVYoQyUZH-6ejwtL3H12NfvpNcvvS588ZS9op858RCQx29vs_d2pKJ7_SzKEMfPr4AIu1A17osWOh5DT3Y/s1600/user+stories+vs+doc.PNG" height="162" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Borrowed from <a href="http://agile4freshmen.blogspot.com/">http://agile4freshmen.blogspot.com/</a><br /></td></tr>
</tbody></table>
<div style="color: #4d4f51; font-family: Helvetica, Arial, sans-serif; font-size: 16px; line-height: 24px; margin-bottom: 30px;">
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.</div>
<div style="color: #4d4f51; font-family: Helvetica, Arial, sans-serif; font-size: 16px; line-height: 24px; margin-bottom: 30px;">
-- John</div>
<div style="color: #4d4f51; font-family: Helvetica, Arial, sans-serif; line-height: 24px; margin-bottom: 30px;">
<span style="font-size: xx-small;">(also published on LinkedIn)</span></div>
</div>
John Eatonhttp://www.blogger.com/profile/00040215463441470962noreply@blogger.com0Atlanta, GA, USA33.7489954 -84.387982433.3266004 -85.0334294 34.1713904 -83.7425354tag:blogger.com,1999:blog-5747686405891759983.post-77328834053244604332015-02-12T05:03:00.001-08:002015-02-12T05:06:30.219-08:00Using Inductive Thinking to Communicate Strategically<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjoj2Ze56ajRmCFr1XiRNOJ9GzjRdqIxq2X4Y4q1Kf3qmKHMjK4vB7oqQ1zUIDdjoGMYZcBkLAzn17Wvgc_MhFkZYRbQYwq_56NVQ6ur1l_LufsJ0CnDkoeZOZW3tpvpZ8NyATaI498bxBa/s1600/DataStreams.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjoj2Ze56ajRmCFr1XiRNOJ9GzjRdqIxq2X4Y4q1Kf3qmKHMjK4vB7oqQ1zUIDdjoGMYZcBkLAzn17Wvgc_MhFkZYRbQYwq_56NVQ6ur1l_LufsJ0CnDkoeZOZW3tpvpZ8NyATaI498bxBa/s1600/DataStreams.jpg" height="174" width="320" /></a></div>
<h2 style="color: #333333; font-family: Helvetica, Arial, sans-serif; font-size: 28px; font-weight: normal; line-height: 34px; margin-bottom: 30px;">
The Problem Statement</h2>
<div style="color: #4d4f51; font-family: Helvetica, Arial, sans-serif; font-size: 16px; line-height: 24px; margin-bottom: 30px;">
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.</div>
<h3 style="color: #333333; font-family: Helvetica, Arial, sans-serif; font-size: 20px; font-weight: normal; line-height: 26px; margin-bottom: 30px;">
The Pyramid Principle</h3>
<div style="color: #4d4f51; font-family: Helvetica, Arial, sans-serif; font-size: 16px; line-height: 24px; margin-bottom: 30px;">
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.</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiZ-w7HIyr8MQe4bcVyeXuHdZniesQE3zo7quWs745mpe76CxAS35-KGobpIi_Il5MOp_87wCPDtSASheFNxuqZ2iQP5WzXYJuczYu_YJK-lGTwjNh3eFAjwNsMBeMsazPuEnZV9iUwMCkZ/s1600/Pyramid.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiZ-w7HIyr8MQe4bcVyeXuHdZniesQE3zo7quWs745mpe76CxAS35-KGobpIi_Il5MOp_87wCPDtSASheFNxuqZ2iQP5WzXYJuczYu_YJK-lGTwjNh3eFAjwNsMBeMsazPuEnZV9iUwMCkZ/s1600/Pyramid.jpg" height="201" width="320" /></a></div>
<div style="color: #4d4f51; font-family: Helvetica, Arial, sans-serif; font-size: 16px; line-height: 24px; margin-bottom: 30px;">
<br /></div>
<h3 style="color: #333333; font-family: Helvetica, Arial, sans-serif; font-size: 20px; font-weight: normal; line-height: 26px; margin-bottom: 30px;">
The Difference Between Deductive and Inductive Thinking</h3>
<div style="color: #4d4f51; font-family: Helvetica, Arial, sans-serif; font-size: 16px; line-height: 24px; margin-bottom: 30px;">
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 <em>The Sign of the Four</em>, Homes says "...when you have eliminated the impossible, whatever remains, <em>however improbable</em>, 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).</div>
<h3 style="color: #333333; font-family: Helvetica, Arial, sans-serif; font-size: 20px; font-weight: normal; line-height: 26px; margin-bottom: 30px;">
Applying What You've Read</h3>
<div style="color: #4d4f51; font-family: Helvetica, Arial, sans-serif; font-size: 16px; line-height: 24px; margin-bottom: 30px;">
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. <em>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.</em> 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.</div>
<div style="color: #4d4f51; font-family: Helvetica, Arial, sans-serif; font-size: 16px; line-height: 24px; margin-bottom: 30px;">
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:</div>
<ol style="color: #4d4f51; font-family: Helvetica, Arial, sans-serif; font-size: 16px; line-height: 24px; margin-bottom: 30px; margin-left: 40px;">
<li style="margin-bottom: 5px;">Arranges ideas into distinct, logical groups so it's easier for the reader/viewer to absorb and remember the information</li>
<li style="margin-bottom: 5px;">Putts emphasis on the supporting logic so the reader/viewer arrives at the conclusion you intend.</li>
<li style="margin-bottom: 5px;">Serves as a roadmap for analysis to help you drive toward a finished product</li>
<li style="margin-bottom: 5px;">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.</li>
</ol>
<div style="color: #4d4f51; font-family: Helvetica, Arial, sans-serif; font-size: 16px; line-height: 24px; margin-bottom: 30px;">
You'll notice that you can apply this structure to everything you do, from analysis, to presentations, to business cases to messaging.</div>
<h3 style="color: #333333; font-family: Helvetica, Arial, sans-serif; font-size: 20px; font-weight: normal; line-height: 26px; margin-bottom: 30px;">
So what are the pitfalls of this approach?</h3>
<ol style="color: #4d4f51; font-family: Helvetica, Arial, sans-serif; font-size: 16px; line-height: 24px; margin-bottom: 30px; margin-left: 40px;">
<li style="margin-bottom: 5px;">It's still very possible for the problem and solution to be confused and/or challenged if it's over-simplified.</li>
<li style="margin-bottom: 5px;">Sometimes it's better to develop a more deductive approach rather than an inductive one, depending on the audience.</li>
<li style="margin-bottom: 5px;">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.</li>
<li style="margin-bottom: 5px;">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.</li>
<li style="margin-bottom: 5px;">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).</li>
</ol>
<div style="color: #4d4f51; font-family: Helvetica, Arial, sans-serif; font-size: 16px; line-height: 24px; margin-bottom: 30px;">
In any case, I hope that I've provided something for you to think about.</div>
<div style="color: #4d4f51; font-family: Helvetica, Arial, sans-serif; font-size: 16px; line-height: 24px; margin-bottom: 30px;">
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.</div>
</div>
John Eatonhttp://www.blogger.com/profile/00040215463441470962noreply@blogger.com0tag:blogger.com,1999:blog-5747686405891759983.post-38831112357047068832015-01-28T08:16:00.000-08:002015-01-28T08:16:27.131-08:00Product Management Soft Skills<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="color: #4d4f51; font-family: Helvetica, Arial, sans-serif; font-size: 16px; line-height: 24px; margin-bottom: 30px;">
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiTdykIMtI3w2ispxPRCp1liQeSmmxUYrisl6sXg4cEJ0LFOBIqbjqvkz_0M6mJH3_Z-4D_cFPSDTU8ZR8ryfH_Ei2pFiXUymMYZDyQn24qaTr6GhoLQbGATBzeeKXCie4HJ-uNAG8NiCzD/s1600/mallows3.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiTdykIMtI3w2ispxPRCp1liQeSmmxUYrisl6sXg4cEJ0LFOBIqbjqvkz_0M6mJH3_Z-4D_cFPSDTU8ZR8ryfH_Ei2pFiXUymMYZDyQn24qaTr6GhoLQbGATBzeeKXCie4HJ-uNAG8NiCzD/s1600/mallows3.jpg" height="274" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">You old softy...</td></tr>
</tbody></table>
<div style="margin-bottom: 30px;">
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.</div>
<div style="margin-bottom: 30px;">
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.</div>
<div style="margin-bottom: 30px;">
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.</div>
<div style="margin-bottom: 30px;">
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.</div>
<div style="margin-bottom: 30px;">
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.</div>
<div style="margin-bottom: 30px;">
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...</div>
<div style="margin-bottom: 30px;">
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).</div>
<div style="margin-bottom: 30px;">
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.</div>
<div style="margin-bottom: 30px;">
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.</div>
<div style="margin-bottom: 30px;">
-- John</div>
</div>
</div>
John Eatonhttp://www.blogger.com/profile/00040215463441470962noreply@blogger.com2Atlanta, GA, USA33.7489954 -84.387982433.3266004 -85.0334294 34.1713904 -83.7425354tag:blogger.com,1999:blog-5747686405891759983.post-79988111673773821902014-12-06T09:54:00.000-08:002014-12-06T09:54:09.472-08:00Revolution vs Evolution<div dir="ltr" style="text-align: left;" trbidi="on">
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi_qkMgUMqMV2nwl91_uP9ryaScI_a6A29rJPG1yEPvZelw8KH7ARP4uqpZcoWTqspIZ6tEV3PaNAtYiSefQgXt_MEfr8VNgjvhUJ2ZAr1EVTIMYIRU91OwCe2Qg20QFf44zshrxGxIHfKh/s1600/Evolution.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi_qkMgUMqMV2nwl91_uP9ryaScI_a6A29rJPG1yEPvZelw8KH7ARP4uqpZcoWTqspIZ6tEV3PaNAtYiSefQgXt_MEfr8VNgjvhUJ2ZAr1EVTIMYIRU91OwCe2Qg20QFf44zshrxGxIHfKh/s1600/Evolution.jpg" height="240" width="320" /></a></div>
<br />
<br />
<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.</div>
John Eatonhttp://www.blogger.com/profile/00040215463441470962noreply@blogger.com0tag:blogger.com,1999:blog-5747686405891759983.post-85834975359786520862014-11-20T03:59:00.003-08:002014-11-20T04:00:27.460-08:00Quantified and Qualifed Data<div dir="ltr" style="text-align: left;" trbidi="on">
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhpRjuy3-JqADR2-B7malfxTMk1LxqecHk3VKFpWc1prkbZjdykCc9MCgp-csbvKUNzIXyl-gHBQJ_Z0xqfw4qjp726WcRwfu1gc1IEI3vsK_Nt7Gom7pEaABqQBReI2QlzQ67coALw0bQK/s1600/data.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhpRjuy3-JqADR2-B7malfxTMk1LxqecHk3VKFpWc1prkbZjdykCc9MCgp-csbvKUNzIXyl-gHBQJ_Z0xqfw4qjp726WcRwfu1gc1IEI3vsK_Nt7Gom7pEaABqQBReI2QlzQ67coALw0bQK/s1600/data.jpg" height="202" width="320" /></a></div>
<br />
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.<br />
<br />
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.<br />
<br />
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." <br />
<br />
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.<br />
<br />
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.<br />
<br data-mce-bogus="1" />
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.<br />
<br data-mce-bogus="1" />
More information regarding the Atlanta Mobile Developer's Group: <a data-mce-href="http://www.meetup.com/Atlanta-Mobile-Developers-Group/" href="http://www.meetup.com/Atlanta-Mobile-Developers-Group/" target="_blank">http://www.meetup.com/Atlanta-Mobile-Developers-Group/</a><br />
<br data-mce-bogus="1" />
Jeff Steinke's blog: <a data-mce-href="http://www.jeffsteinke.com/" href="http://www.jeffsteinke.com/" target="_blank">http://www.jeffsteinke.com/</a><br />
<br data-mce-bogus="1" />
(also published on LinkedIn)</div>
John Eatonhttp://www.blogger.com/profile/00040215463441470962noreply@blogger.com0tag:blogger.com,1999:blog-5747686405891759983.post-1426873022464093962014-11-15T12:20:00.000-08:002014-11-15T12:20:19.684-08:00Good Product Management is Based on Good Data<div dir="ltr" style="text-align: left;" trbidi="on">
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.<br />
<br />
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.<br />
<br />
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?<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh_Oig5vc-O421qZiCPtyyPdg8Vq3qX6KsI_gTI5nVk0d2K1bZxCdm0FzSstIP-DhDfIThhVEtkli9VXq8FkV1NnS0qgquKkjpW8Ybnb66Df1iFocxvM4nGiAKMMYQhrN20QxzttqXy84ar/s1600/data_mining.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh_Oig5vc-O421qZiCPtyyPdg8Vq3qX6KsI_gTI5nVk0d2K1bZxCdm0FzSstIP-DhDfIThhVEtkli9VXq8FkV1NnS0qgquKkjpW8Ybnb66Df1iFocxvM4nGiAKMMYQhrN20QxzttqXy84ar/s1600/data_mining.jpg" height="220" width="320" /></a></div>
<br />
<strong>Research: Public Searches.</strong>
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?).<br />
<br data-mce-bogus="1" />
<strong>Research: Examine Your Internal Data.</strong>
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.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhAgn9GR-_OaIR0RD0tRabBEsKSSqQuErRbGtY6zlrAR3DcT3FmX9h6VUbVtzY2fj1q_7j3t1WQDLpgktH9oFFACOsTv1q_N7uQrn8o2xq_UwBipreKn0N4Cxq6JSolIBiqsRCZn2vB7n1p/s1600/SalesDatabase.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhAgn9GR-_OaIR0RD0tRabBEsKSSqQuErRbGtY6zlrAR3DcT3FmX9h6VUbVtzY2fj1q_7j3t1WQDLpgktH9oFFACOsTv1q_N7uQrn8o2xq_UwBipreKn0N4Cxq6JSolIBiqsRCZn2vB7n1p/s1600/SalesDatabase.jpg" height="229" width="320" /></a></div>
<br />
<br />
<strong>Research: Use Your Existing Customer Pool.</strong>
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.<br />
<br data-mce-bogus="1" />
<strong>Research: Use Your Existing Sales and Support Pool.</strong>
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.<br />
<br data-mce-bogus="1" />
<strong>Big Data and DataScience.</strong>
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.<br />
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.<br />
<br />
"I get it...I get it"...<br />
<br />
-- John</div>
John Eatonhttp://www.blogger.com/profile/00040215463441470962noreply@blogger.com0tag:blogger.com,1999:blog-5747686405891759983.post-61401446491545809652014-10-28T03:35:00.003-07:002014-10-28T03:35:58.400-07:00A Look at Products vs Features<div dir="ltr" style="text-align: left;" trbidi="on">
<b>My thoughts on Products vs Features</b><br />
Or how to think about developing products rather than features.<br />
<span style="font-size: xx-small;">(Also published to LinkedIn) </span><br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><img alt="" class="center" data-mce-src="https://media.licdn.com/mpr/mpr/p/7/005/095/194/0498684.bin" src="https://media.licdn.com/mpr/mpr/p/7/005/095/194/0498684.bin" style="margin-left: auto; margin-right: auto;" /></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Borrowed from marketoonist.com</td></tr>
</tbody></table>
In
the course of "usual" product development, we product managers ideally
work from the user outward - basically what problem are we trying to
solve and what's the fastest way to get there. Since we think of
problems in regards to users, personas and entities/actors, the solution
is often one that incorporates technology and heuristics ad a fairly
granular level. Think of this as feature fulfillment. What I've learned
over the course of the last decade is that this isn't enough. Too often
we develop something that is so specific, only to "refactor" or
otherwise redesign the software underpinnings at a later time due to
unanticipated discovery over time. We've all been there and done that
I'm sure, especially anyone involved in software development over time.<br />
<br />
Instead,
we should be thinking of solutions that have broader application, or at
least open up the conversation towards reuse that could expand into a
product. In classic development, we often approach things with the
end-goal in mind. What's the MVP? How quickly can we get this into
production, delighting the user or otherwise providing a feature
solution. Subsequent development often introduces similar concepts and
provides an avenue to "reuse the code" due to similarities. At this
point, if your coding partners have some experience they may suggest a
refactor and reuse which is good. What I'm suggesting is that we should
try to lead with this idea and then do some analysis to decide whether
we spend the time upfront in design or shelve broader product concept
for quick delivery.<br />
<br />
An example - you may have worked on an
application that has a need to do some calculation such as an
amortization calculator. You basically provide a utility to calculate
interest and principle payments to determine how different loan lengths
impact your monthly payment or time-to-complete the loan. The following
year you have a different calculator needed in another area of the
application that's similar so initially you may think to just copy the
code for the second app. By the time you get to the third calculator
needed, someone in dev says "hey maybe we should combine the apps and
make a configurable solution that can be used anywhere" - which is a
great idea, however now you face the task of absorbing the technical
debt to rework everything.<br />
<br />
Instead of "going the normal route"
as described above, let's look at this from a product perspective. The
problem you're trying to solve is the need to make some calculations via
some utility available to the user. Doesn't that sound like something
that's likely to be needed in more than one instance? Is something
available that you can find that's inexpensively licensed as a plug in,
rather than writing the code? If so, how much complexity to incorporate
the component, etc. and how useful is it? Can it be applied to different
types of calculations? Really, is it any good or just a hack? If we're
doing our jobs as product managers we should be thinking along these
lines and through the process of discovery and affinity comparison,
decide if we can do a better job than what's available off-the-shelf and
if so, that should suggest that there's probably an opportunity hidden
there. We should also do some basic research and analysis on any
potential opportunities so we aren't doing things in a whimsical manner.
In my opinion, all of our product decisions should be based on data -
otherwise we're just guessing.<br />
<br />
So if you decide that there is
indeed an opportunity, how to defend the additional up-front development
cost? This is the tricky part - you can certainly over-engineer a
"widget" - ask me sometime about building a super-configurable
application that was so complex the adoption was very limited - there's a
need to balance the planned intent against what's being executed at any
given time. The start of all this should be a conversation with your
devs, and in particular your architects, about the approach. If they
know up-front that you're thinking about this new "widget" as a
potential product, they will certainly build into the design some
"hooks" so it can be flexible, and some baseline configuration that
doesn't entail too much of an engineering effort. You have to get your
team involved early and build some basic product planning before being
involved in the execution of code. You also need to rein in some of
those efforts so your guys aren't building a nuclear power plant when
your trying to supply a battery.<br />
<br />
Bottom line? Start thinking
of what you're building as something more than simple components - start
thinking of them as features of potentially stand-alone applications
(only skinnied-down to solve a specific problem). Second, talk to your
devs and discuss what you're thinking - you'll be surprised at what they
can come up with. Invention is indeed the mother of necessity, but
don't rely on only yourself as a guide to the approach.<br />
<br />
-- John</div>
John Eatonhttp://www.blogger.com/profile/00040215463441470962noreply@blogger.com0tag:blogger.com,1999:blog-5747686405891759983.post-87234704589781812892014-10-07T03:46:00.004-07:002014-10-07T03:46:56.065-07:00Get Active!<div dir="ltr" style="text-align: left;" trbidi="on">
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEioOdBERhyphenhyphenr-VZT_CCjlJpRW8Kl5Rv07So4f66uOrgKs2h-BITLbLYh3QvcZ8fvbdCRBb00QhrxuxGXwMI5gFqdVDL99APPtZcOfkZ4iqNMVejvinqi1RRPQ4I3sQ-0k6-GQIpYqd9EOeL7/s1600/GetActive.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEioOdBERhyphenhyphenr-VZT_CCjlJpRW8Kl5Rv07So4f66uOrgKs2h-BITLbLYh3QvcZ8fvbdCRBb00QhrxuxGXwMI5gFqdVDL99APPtZcOfkZ4iqNMVejvinqi1RRPQ4I3sQ-0k6-GQIpYqd9EOeL7/s1600/GetActive.jpg" height="210" width="320" /></a></div>
<br />
Having doing Product Management for many years I found myself
recently in a bit of a slump - at some point I reached a threshold where
what I was doing just wasn't very satisfying. This was due to several
factors:<br />
<ol>
<li><strong>Post-Release Blues</strong> - the "1.0" of
my most recent responsibility had gone to market which is really
exciting. All the months of creative energy expelled in a giant burst,
which ultimately ended up being anti-climactic - to achieve an MVP the
product was lacking in several key areas to really make it functional.
These were the result of a lack of understanding regarding the real
needs of the user - we had made some assumptions, and as usual when you
make decisions based on guesses rather than real data, those assumptions
led to a less-than-usable product.</li>
<li><strong>Post-Release Follow-up</strong>
- So the next several months were spent bringing the product up to what
is/was the actual MVP. This included bugs but mostly it was lack of
processing functionality (not as in calculative capacity, but rather in
business process management function). We've finally gotten the product
to a point where it was relatively safe to release to the public, and
more importantly to our internal business users.</li>
<li><strong>New Priorities</strong>
- of course things changed during the overall process to release to 1.0
and these new changes (support for an entirely new conceptual
product-line) also added complexity that mired our teams for several
months (and it didn't help that the requirements changed several times
before we got this right). Luckily the agile process allowed us to be
nimble and adjust our product roadmap to bring these new features to the
forefront. It did cause a bit of a stir company-wide as our roadmap and
commitments changed. Tough to do this in a relatively heavy top-down
managed company.</li>
<li><strong>Note Celebrating Small Successes</strong>
- nothing like feeling like your behind to keep you from enjoying
things that go right. We all need to keep things in perspective and it's
often difficult to see the trees when you're in the middle of the
Sequoia National Forest.</li>
</ol>
So in total, my overall morale had
been low. So what to do about it? In my case I became more active in
activities set to expand the mind - and no I'm not talking about
mind-expanding drugs. I started to go to local industry meets (it's
helpful if your company is part of the local tech scene - in Atlanta
there's the <a data-mce-href="http://www.tagonline.org/" href="http://www.tagonline.org/" rel="nofollow">Technology Association of Georgia</a>
(TAG) which is helpful as there are always meetings by various
associations going on - I joined the Product Management association
within TAG). But don't limit yourself there. I also joined the local <a data-mce-href="http://www.pcampatl.com/" href="http://www.pcampatl.com/" rel="nofollow">ProductCamp</a>
and started to go to the yearly unconference and at some point will
participate in presentation. But getting involved in those two groups
was like having an appetizer during a nice meal - you want more! Besides
the local, more formalized groups, look at <a data-mce-href="http://www.meetup.com/" href="http://www.meetup.com/" rel="nofollow">MeetUp </a>and what it has to offer. What to do?<br />
<br />
My
suggestion is to expand outside of your normal circles - start on the
technology side and move outward - see where it goes. I have a firm
belief that from a product management perspective, anything that we do
to further a product should be first supported by good data. If you
don't have data how do you know that what you're doing meets what the
market wants, or through extrapolation, what the market could want
(emerging or untapped markets)? Everything that we do as technologists
should be supported by data. So what's more natural than to get involved
in the local data groups? I joined both the <a data-mce-href="http://atlantabi.sqlpass.org/" href="http://atlantabi.sqlpass.org/" rel="nofollow">Microsoft BI</a> group and the <a data-mce-href="http://www.meetup.com/Data-Science-ATL/" href="http://www.meetup.com/Data-Science-ATL/" rel="nofollow">Data Scientist ATL</a>
group - the former is a bit more on the technical application side
while the latter is more about theory and the procedure/process of
collection and filtering. Both are interesting in different ways and a
byproduct is that you will meet people that may not be in your normal
circles. I really enjoy both groups and they have expanded my horizons.
The latter group is also very social - I think this is an important
aspect of what we do as technologists that becomes lost in all the work
we become saturated within - meeting people at a more casual level lets
the mind explore new possibilities.<br />
<br />
An example - during the
last Data Science ATL meetup I met several new people - one was a
consultant who really liked to connect people of similar mindsets to
each other to promote technology and innovation; the second was a php UI
developer (Not a group I normally associate with); the third was a data
scientist. All three were co-mingling, having snacks and a couple of
beers with discussions roving all over the place: work, technology,
possibility, networking - you get the idea. Somehow I got into a
discussion regarding SpaceX and what Elon Musk is doing in the private
sector and this got things rolling into what new innovations along those
lines were being explored here in Atlanta. The result was unobstructed
idea flow, laughter and an expansion of awareness. It's also how the
beginnings of an idea happen - often through casual conversation - you
just need to find the right people to involve in those conversations.<br />
<br />
Taking
some of the thinking regarding these groups and what I found there, I
started my own MeetUp group - this one around Socal Business application
(meaning the application of social networking tools to the enterprise) -
something that interests me. I've had one meetup so far with a little
over half attending. It's a start and it gets things going - if nothing
else it gets my own mind moving. Details about <a data-mce-href="http://www.meetup.com/Atlanta-Social-Business/" href="http://www.meetup.com/Atlanta-Social-Business/" rel="nofollow">Atlanta Social Business Product Management</a>. If you look at my last couple of posts you'll see reference to the MeetUp and what this topic is all about.<br />
<br />
So
where does this take you? I don't think it matters - what matters is
getting your mind into new situations and possibilities so you aren't so
buried in the day-to-day grind of achieving sprint goals. Step away
from your desk occasionally and have a conversation with those in your
office you don't normally interact with. Join your office leadership
committee or volunteer to help plan office events. Do things to break up
your normal activities so the job doesn't wear on you and you'll be
glad you did - your employer will be too (as long as you don't do
anything to get arrested!).<br />
<br />
-- John</div>
John Eatonhttp://www.blogger.com/profile/00040215463441470962noreply@blogger.com3tag:blogger.com,1999:blog-5747686405891759983.post-59529174154327989512014-08-11T03:41:00.001-07:002014-10-02T06:46:55.148-07:00The Argument for Social Business<div dir="ltr" style="text-align: left;" trbidi="on">
There's currently quite a bit of buzz around the term Social Business - especially around HCM (Human Capital Management) so I thought I would address the term. I think what makes it a bit confusing is that the term is already used as defined by Muhammad Yunis in 2009 in his books "Creating a world without poverty - Social Business and the future of capitalism" and "Building Social Business - The new kind of capitalism that serves humanity's most pressing needs." The books in general are about changing business prime-directives from maximizing profits to financial self-sustainment and re-investment. This is much different from the term Social Business used to describe a socialization trend happening in businesses that refers to the use of social tools in everyday business practices.<br />
<br />
A better term might be "Collaborative Business" and in general refers to the use of some of those abstract constructs used in social networks but applied at the business level. Most of these constructs involve the "group think" concepts of shared posts, transparent threading of messages/emails/posts, the aggregation of interactivity across multiple tools and the community aspect of collaboration as embraced by businesses, at minimum internally and ultimately with external clients and experts. Ideally Social Business incorporates the various communities involved with the business and introduces a higher degree of interaction between the communities. The stress is on engagement and the result can be measurable depending on how things are defined (aligning the goals of the business with the efforts involved in sharing information). HCM has begun adopting some of these constructs, especially for internal communication but I believe to be effective these tools should be implemented beyond the enterprise - however it's still a good first step at implementation.<br />
<br />
IBM has done a rather remarkable job introducing the concept into it's core communication - much of this came about through a corporate initiative to allow its employees to blog articles to help disseminate information which then lead to their hosting both internal and external blogs - this was followed up by the extension of the old Lotus Notes into the current Domino product. I recently attended a <a href="http://www.tagonline.org/chapters-and-societies/social/" target="_blank">TAG Social Society</a> event (and if you haven't joined TAG - the Technology Association of Georgia, then this single group may make it worth while) that had the topic What Will My Email Look Like “Tomorrow”? (it was actually a combined event of separate TAG groups but the presentations were mostly around Social Business). Louis Richardson from IBM was the keynote - he started out with the the quote "Email is where messages end up to die" and spoke about the relative waste of using email to communicate, especially between a group trying to get consensus on a decision - his example had 6 people in it who all had to copy the entire group every time a comment was made. By the time several people commented (and some copied as yet other interested parties) there were quite a few emails in total (I believe he said the average is 150 emails to make one decision). He then referenced the way Domino addresses the problem - I won't go into detail but if you're really interested you may want to look up the feature description.<br />
<br />
I'm using the IBM and the TAG Social Society reference above to illustrate my point - there are many thinking about the future of communication and collaboration and how it will be addressed by business, especially enterprise business. Why all the interest? If you look at the demographics, particularly of the Millennials and post Millennials that are making their way into business, you'll understand that this latest generation interacts differently with information than most of the "gray hairs" currently controlling business. This new group is used to multitasking using a variety of electronic devices, combining messaging, video, text-in-email, social media - you name it and they use it, often all at once. It's been observed that the group in general has become "wired" differently in the way they think - with information coming into the funnel (so to speak) in multiple work streams. The biggest change is the way information is collated by multiple participants into threads (the advantage is that information is shared to a larger group without multiple posts like in the email example provided by L. Richardson above).<br />
<br />
Think about being a Millennial and being used to this work stream way of thinking, then hitting the plodding methods traditionally (well, at least the last 20 years) used by business where email is king - I can imagine the frustration and lack of enablement - and this may explain why companies who have adopted a more collaborative way of communicating using social tools have become so successful - Google is a good example. It might also indicate why so much of the talent pool is moving towards these "hot" companies (yeah you get free lunches and you always hear about the company culture - but is that enough?). My theory is that if we don't provide a communicative atmosphere of collaborative tools we aren't just missing the boat, we're basically given a paddle and told to make the best of it.<br />
<br />
That that end, I think that the beginnings of the solution has already been adopted by technology teams (they tend to be the first to adopt good ideas) in most software development shops through the use of collaboration tools like Campfire and github. Many of the tools and ceremonies have also been adopted by the Agile and scrum shops to improve team communication - and it works! so I've pitched the idea to those I know who facilitate the agile/scrum model. To further examine how Social Business might be implemented, I've created a new MeetUp group called <a href="http://www.meetup.com/Atlanta-Social-Business/" target="_blank">Atlanta Social Business Product Management</a> (yeah it's obnoxious but I couldn't think of anything that had more zing). Please join if you're interested.</div>
John Eatonhttp://www.blogger.com/profile/00040215463441470962noreply@blogger.com0tag:blogger.com,1999:blog-5747686405891759983.post-68012215014944090452014-07-28T02:55:00.001-07:002014-07-28T02:55:46.809-07:00The Three Laws of Software Development - Conway's Law<div dir="ltr" style="text-align: left;" trbidi="on">
During a recent class, Peter Saddington referenced three laws which collectively are knows as the Three Laws of Software Development:<br />
<ol>
<li>Humphrey's Law</li>
<li>Ziv's Law</li>
<li><strong>Conway's Law</strong></li>
</ol>
I wrote about Humphrey's and Ziv's Laws in my previous posts. Conway's Law is perhaps the one that is most well known of the three.<br />
Looking up "Conway's Law" you'll find it in Jeff Sutherland's book "Exploring Scrum: The Fundamentals." Conway's Law is an adage named after Melvin Conway who first mentioned the idea in 1968. It states "Organizations which design systems...are constrained to produce designs which are copies of the communication structures of these organizations" or it's also written as "If you have four groups working on a compiler, you'll get a 4-pass compiler" (sic). That second version is a bit dated by today's standards. I believe Peter stated it a bit more colloquially as "Software always mirrors the group that built and designed it - if the company is dysfunctional due to poor communication then the software will have the same dysfunction" or simply "everyone needs to communicate better."<br />
This law is as proverbial as the previous two and like them, is more of a valid sociological observation. I found this diagram by Manu Cornet on <a data-mce-href="http://www.bonkersworld.net" href="http://www.bonkersworld.net/" rel="nofollow">Bonkers World</a> that I thought was pretty funny and actually a fair representation of Conway's Law...<br />
<img alt="" class="left" data-mce-src="https://media.licdn.com/mpr/mpr/p/3/005/077/314/06c54e5.jpg" src="https://media.licdn.com/mpr/mpr/p/3/005/077/314/06c54e5.jpg" /><br /><br />
Manu's diagram isn't specific to Conway but you can infer what you like. The Microsoft and Oracle diagrams are especially telling. Peter tied this law into the need for excellent communication and collaboration as a necessity in producing great software. I've personally seen this law represented myself in the many start-up companies that I've had the honor of working with and the opposite end of the spectrum, large corporate software endeavors (at some point I'll relate a project that had over 100 sign-offs).<br />
Early stage Start-ups are typically small and have a tiny organizational chart - the software produced is usually fairly simple structurally and the communication is more one-to-one due to the tight org structure. This ability to be nimble due to size produces many advantages, especially the ability to go to market quickly. Larger organizations begin struggling to produce software with any speed - there are so many check-points and stakeholders involved in the production that there are often small changes that impact both the software in complexity and the company's ability to market quickly. Large corporate entities are often bound to many revisions, checks-and-balances, approvals - you get the idea. Not only does the software fill with complexity but releases become a nightmare.<br />
Tying back to the class, the emphasis is to make small incremental changes and expose those changes for approval back to the stakeholders early and often so the team can adjust and do a better job meeting expectations. Not only do you produce better and more efficient software, but the release becomes less problematic - there are fewer surprises. I don't know how many times I've worked on a project where the smaller changes truly delight the customer while the larger changes produce confusion and revolt - this is usually ascribed to poor training but even taken that as a viable excuse, doesn't it amount to a lack of communication?</div>
John Eatonhttp://www.blogger.com/profile/00040215463441470962noreply@blogger.com0tag:blogger.com,1999:blog-5747686405891759983.post-48504519434146380822014-07-21T13:11:00.000-07:002014-07-21T13:11:45.154-07:00The Three Laws of Software Development - Ziv's Law<div dir="ltr" style="text-align: left;" trbidi="on">
<span style="font-size: xx-small;">(previously published on LinkedIn)</span><br />
During a recent class, Peter Saddington referenced three laws which collectively are knows as the Three Laws of Software Development:<br />
<ol>
<li>Humphrey's Law</li>
<li><strong>Ziv's Law</strong></li>
<li>Conway's Law</li>
</ol>
I wrote about Humphrey's Law in my previous post.<br />
<br /><br />
Looking up "Ziv's Law" you'll find it in Jeff Sutherland's book "Exploring Scrum: The Fundamentals." Ziv's Law states that software development is unpredictable and that the documented artifacts such as specifications and requirements will never be fully understood. First we need to all agree that new product design is the fundamental nature of software development - and that basically whenever we're creating something new, no matter how close it is to something we've done before, it's impossible to be confident of all the constraints and needs of this new development. Sure we can do some affinity comparisons to something we've done previously, but there's always some variability (if there wasn't then why didn't we just use what was built the first time?), and it's virtually impossible to predict the outcome with much accuracy due to this variability. And further, the more the new development diverges from the previous, the more unlikely the accurate prediction of the outcome.<br />
<br /><br />
This law, much like Humphrey's Law, is about uncertainty. It's all about the precision of functional and non-functional requirements in regards to software development projects - no matter how well they are understood and written during the time of scoping and initial refinement, things tend to change while the actual development is going on (whether the business need changes or there are changes inherent to the development process itself that impact the complexity). This law is important because it's fundamental to understanding how the agile process, and scrum in particular, addresses this particular issue.<br />
<br /><br />
With scrum, because the intervals are fixed and the stages of development divided into bite-sized chunks that can fit into the interval, there's more room to make adjustments in the subsequent intervals (sprints) to allow for what is discovered. This also brings into play the experiences of those working on the user story (i.e. your technical team) so you're already getting additional input into the outcome. All this leads to a much more satisfying final product, both for those involved in the process and for those who are supporting or needing the results of those efforts - and after all, that's what we are trying to do, delight the customer (general term for whom we're doing the effort).<br />
<br /><br />
So why is this law important? It has to do with failure and what we do as a result of failure. If we accept that what we are building in any one sprint isn't perfect, then we'll understand that the feedback we receive from the customer for what's been done can be incorporated into the next sprint, allowing us to make adjustments to a final, satisfying outcome. Small failures are OK and should be expected - it's the ultimate result adjusting to those small failures that will make us successful.<br />
<br /><br />
-- John<br />
<br /></div>
John Eatonhttp://www.blogger.com/profile/00040215463441470962noreply@blogger.com4tag:blogger.com,1999:blog-5747686405891759983.post-34864439254001633822014-07-21T13:08:00.002-07:002014-07-21T13:12:52.672-07:00The Three Laws of Software Development - Humphrey's Law<div dir="ltr" style="text-align: left;" trbidi="on">
<span style="font-size: xx-small;">(previously published on LinkedIn)</span><br />
During a recent class, Peter Saddington referenced three laws which collectively are knows as the Three Laws of Software Development:<br />
<ol>
<li>Humphrey's Law</li>
<li>Ziv's Law</li>
<li>Conway's Law</li>
</ol>
I had never heard of these observations referenced as "laws" and wanted to explore them further with my own research. Apparently Conway's Law is used in some scholastic software development classes but the other two are a bit obscure to me. We'll start with Humphrey's Law.<br />
<br />
<br />
<br />
<br />
Looking up "Humphrey's Law" you first encounter a Wikipedia entry regarding something called "The Centipede's Dilemma" - which is something psychologists call the centipede effect or the centipede syndrome. The reference has to do with what happens when a normal action is interrupted by the person's own awareness of the action. An example might be a baseball player who normally uses his training, muscle memory and a bit of instinct to swing and hit a home run, but because he's consciously aware of what he's doing, he basically over-thinks the action, causing him to strike. The effect is also called hyper-reaction or Humphrey's Law, named for English psychologist George Humphrey, who wrote about the effect in 1923 using a poem by Katherine Craster, usually titled "The Centipede's Dilemma." - yeah I know I'm getting fairly esoteric in this but I think it's good to understand where this stuff comes from.<br />
<br />
<br />
<strong>The Centipede's Dilemma</strong><br />
A centipede was happy – quite!<br />
Until a toad in fun<br />
Said, "Pray, which leg moves after which?"<br />
This raised her doubts to such a pitch,<br />
She fell exhausted in the ditch<br />
Not knowing how to run.<br />
<br />
<br />
While the poem is interesting it does illustrate the main point, which is "Thus, the eponymous "Humphrey's law" states that once performance of a task has become automatized, conscious thought about the task, while performing it, impairs performance. Whereas habit diminishes and then eliminates the attention required for routine tasks, this automaticity is disrupted by attention to a normally unconscious competence." - rather obscure, right? So the question remains, how does this fit into the Humphrey's Law as referenced by Jeff Sutherland, co-creator of Scrum and where the Three Laws of Software Development idea was presented?<br />
<br />
<br />
Jeff Sutherland's version of Humphrey's Law states that "users don't know what they want until they see working software" or to paraphrase Peter Saddington, "People don't know what thy want until they see what they don't want." This seems to be the opposite of what "Humphrey's Law" as referenced by psychologists means, although they do share some common threads:<br />
<ol>
<li>Both ideas are about human response to exterior stimuli</li>
<li>Both ideas are observations which seem true.</li>
<li>Both contain an element of subconscious objectivity</li>
<li>Both share the same name</li>
</ol>
I had original concluded that they are the same law, only cross-referenced from the perspective of the observer for the Software Development reference, and from the subject (actor(s) aka centipede) in the psychologists' version. Of course this was purely conjecture - and someone commented on my thread on LinkedIn to say that it's actually a different Humphrey - a software developer.<br />
<br />
<br />
So what about application? These types of laws represent an observable problem, so using the adage that one must first recognize the problem before it can be addressed, the next step is to identify how Humphrey's Law is impacting the development of good software and using various methods to resolve the issue. Peter did a great job illustrating the problem using a "I want a car" technique that I hope to demonstrate to the product guys and my teams at Altisource Labs. I'm working through this now in the form of an interactive class and demonstration which I'll share with you in a subsequent post. In the meanwhile, I'll continue exploring the other two Laws in my next posts.<br />
<br />
<br />
-- John<br />
<br /></div>
John Eatonhttp://www.blogger.com/profile/00040215463441470962noreply@blogger.com0tag:blogger.com,1999:blog-5747686405891759983.post-57865598063310456132014-07-21T13:05:00.004-07:002014-07-21T13:09:27.273-07:00Building Personas<div dir="ltr" style="text-align: left;" trbidi="on">
<span style="font-size: xx-small;">(also published on LinkedIn)</span><br />
From my last post you may have garnered my desire to begin using some of the Pragmatic Marketing training and incorporating the best ideas into my current projects. Specifically, I began creating personas to use within the user stories and to support each development effort by providing additional context for the team members. When I broached the idea with the development team I initially was met with silence. On further discussion with some of the team members I received a rather interesting response "Well, yeah those are fine for UI but they really aren't useful to a developer." I met this with a bit of dismay - I really thought they would buy into the idea of providing additional context, as the current development groups (we went from a highly efficient team to several inexperienced teams) need all the context they can get. The counter-argument I received had to do with security settings and how typical UI-type personas did not provide enough information to determine access controls. It's interesting how some of those same members who desire efficient agile teams argue against using tools to make it so.<br />
<br />
<br />
<br />
<br />
To reinforce the idea, a recent CSPO class emphasized the same thing - provide personas that can be used to help get the team into the mind of the user. At this point I could use some hard data to support the idea (mostly to get buy-in from the team) so anyone out there reading, if you have some fact-based analysis I that I can use it would be helpful in supporting my ideas. In the meanwhile, I'm continuing to build my personas to support epics/stories going forward, hopefully this will nudge the team into being more accepting. As to the question of security settings and access controls, it seems that if the personal has a well defined description and these are of importance, the information can be added into the personal description, no?<br />
<br />
<br />
<br />
<br />
In any case, I'm currently defining personas for about a dozen different user-interacting roles into the current application. More updates to follow.<br />
<br />
<br />
<br />
<br />
-- John<br />
<br /></div>
John Eatonhttp://www.blogger.com/profile/00040215463441470962noreply@blogger.com0tag:blogger.com,1999:blog-5747686405891759983.post-84068751003631364512014-07-19T10:56:00.002-07:002014-07-19T10:56:21.887-07:00Pragmatic Marketing and Scrum<div dir="ltr" style="text-align: left;" trbidi="on">
<span style="font-size: xx-small;">(a slightly different post published on LinkedIn)</span><br />
For the past 13 or so years I've been working in a variety of software development shops practicing Agile, and generally some modification of scrum. My focus has always been to take the ideal scrum implementation and continue to make it better - I can say that I've only found a very few shops that practice the "ideal" version of scrum as conceived by the founders of that term. At some point I'll get into that a bit more but the purpose of this article and a few to follow are to take what I've learned most recently from the Pragmatic Marketing training, and apply bits-and-pieces to my current job situation.<br />
<br />
<strong>First a bit about Pragmatic Marketing</strong>. <br />
I believe I first found Pragmatic Marketing in the early 2000's - at the time I was a Director of Technology (my role was more of a Product Manager one, I just didn't realize it yet) for a small start-up that had begun making some headway - in fact we were just turning a profit and had begun to expand the various departments of the company, including Product Management. We hired a very good upper management PdM person who, when presenting his ideas, etc. suggested that we might want to take a look at the materials provided by Pragmatic Marketing (I'll use PM going forward) to guide our expansion plans - at the time you could sign-up for a free PM print magazine that was published, I think either quarterly or bi-monthly and by signing up you had access to the other materials and past issues as PDFs (I may still have those stored in my files somewhere). After reviewing most of what was there we started to employ many of the ideas and also the terms associated with the course - it basically gave us a basis of terminology that was previously missing. Of course, being a start-up it was hard to justify taking the paid-course, but I had always been curios about it.<br />
<br />
<strong>Next, about the current implementation of scum in my current position</strong>. <br />
I function as a Product Manager for two different development groups. The first is a legacy platform that is primarily in maintenance mode, so it's a rather small team practicing kanban and mostly doing user stories relating to reporting needs to compliance and regulatory changes. At some point this team will be absorbed into other efforts, but at present there's enough work to keep them busy. The legacy platform has been running for over 10 years and frankly many of the efficiencies from 10 years ago have been exceeded by company demand which leads to the second group. Group two is a complete redesign using a different technology stack and a common services platform. The second group has gone from one team to five, then shrunk back to a single, consolidated team and now is expanding again into three teams. I share the product owner role with another product manager and we're lead by a Director who acts more as a principal product owner (his focus is more on the strategic direction and he has responsibilities tied to the P&L). From my scale, these newly defined teams are about 70% where I think it should be from a classic scrum perspective (it continues to get better but there's still a bunch of work to do). The group two team started with scrum and was relatively successful up to the initial release of the new product. Recently the expansion of the team into two groups (and building to three) has lead to inefficiencies and our velocity is shot.<br />
<br />
<strong>A few weeks ago I attended three Pragmatic Marketing courses: Foundation, Focus and Build.</strong> <br />
The main thing that I took away from the classes was that I already knew much of the information (you would expect that after 13 or so years doing product, right?) - the classes actually provided a framework of using what I already knew that was a bit more organized. It also provided some insights and approaches that I hadn't tried. Now we get into what I've learned and what I intend to implement to improve our teams.<br />
<br />
There was an interesting graph as part of the Build class that I want to share, that has relevancy to what I've so far described. This has to do with context, and how it impacts the effectiveness of teams.<br />
<br />
<strong>Basically, the first tenant is that the more context a team has the more efficient they become in executing what the market needs.</strong> <br />
The better the context, the less that needs to be expressed as any type of requirements for a team - that's not to say that there doesn't have to be documentation, but due to the past shared experiences of the core team, the high trust levels between all participants, and the familiar processes, the teams reacted well, quickly and accurately to requests coming from the market. This is really the ideal state of a good scrum team, where from a PdM perspective, just enough detail is included in a user story. This is well illustrated by the previous velocity of the teams while executing the initial release of the product.<br />
<br />
<strong>The second tenant is that the less context the team has, the more content and requirements product needs to produce for the team.</strong> <br />
The analogy is to take some software feature to a contract shop - because they have very little context, they need much more information in order to be successful - this ends up being lots of artifacts, requirements and specifications. You can see that by expanding our previous team with many new, novice team members we should have adjusted as product managers by providing much more context, to help them ramp up and be successful. By having the unlikely expectations that these newly formed teams would magically become as quick and efficient as the original teams (the idea is to spread the experienced members across the new teams as leadership, so they can impart the technical information needed to get the teams up to speed) within a couple of sprints, we didn't consider that the amount of context provided to the team by product needed to correspondingly increase. So one simple graph and about 5 minutes of discussion in my PM class provided a world of context for me, in first identifying the problem and then taking some steps to improve the situation.<br />
<br />
<strong>So what to do?</strong> <br />
There were several recommendations that I drew from the classwork - remember that the main thing I'm trying to fix is a problem of context - how to get all the business information that product has packed into our brains and disseminate it to the new team members. When I describe a new feature idea I usually use flow diagrams to show how the process could be defined and wasn't spending much time describing the why - I'm now scheduling more time to go over the market need so that the teams are all on the same page. That's a start and seems obvious, but until I recognized that there's a problem how does one improve?<br />
<br />
One thing that was emphasized by the instructor, Steve Gaynor (who was fantastic, by the way) was that there was a lot of information addressed in the class, and <strong>instead of trying to apply everything, just pick out 2 or 3 things and focus on making them work.</strong> So the other classroom idea I found interesting in regards to the problem was the concept of personas.<br />
<br />
As with most of my Product Management friends, I usually include the "actor" (a representation of who is interacting with the feature) in my user stories. <strong>The concept of persona</strong> is a bit different - it's to create a fictitious "who" that's more defined. Using real data (surveys from the market was one suggestion for garnering the information), the product group creates a persona or personas who would represent the most likely candidate(s) for the use of the product. Because there's a lot more information provided as background of the persona, the user becomes more than an actor and the background suggests the needs of the user to the team doing the user story. So instead of "As an admin user" you might say "As Greg Jones" as the beginning of your story statement. There's an entire persona called "Greg Jones" that's been created that represents the characteristics of a typical admin user, including experience with the software and business, background and expertise, the amount of time spent on tasks, etc - whatever is relevant. By expressing personas that can be identified as a real entity, the team has a better experience when developing the feature and thus satisfying or delighting the persona, thereby receiving context from the very beginning of the story. Sounds good, right?<br />
<br />
So I started stubbing in the personas for a particular business unit late last week and will continue this coming week. I'll report on this and some of the other ideas that fell out of the PM training in my next post.<br />
<br />
-- John Eaton</div>
John Eatonhttp://www.blogger.com/profile/00040215463441470962noreply@blogger.com0tag:blogger.com,1999:blog-5747686405891759983.post-88024981793442043792014-07-01T17:04:00.001-07:002014-07-01T17:04:47.187-07:00The Accidental Product Manager<div dir="ltr" style="text-align: left;" trbidi="on">
I've been doing Product Management for over 13 years. When I reflect back upon my entry into that field, I find that there isn't any single event that led me there. Even my entry into software development was roundabout - having come from a graphics background. I've also found that this is a common trait among other product managers I've met or worked with - it seems we all started elsewhere then gravitated towards what we like best about software development, the actual design and creation of something new. Continuing on this thread, I haven't seen any specific courses for product management (sure there are certification courses by companies such as Pragmatic Marketing, but I've never seen any specific course work offered in universities to prepare a student for software product management). I have encountered some common characteristics of the best PdMs that I've met worth sharing:<br />
<ol style="text-align: left;">
<li>Most of the professional product people I've met enjoy a high degree of creativity. The best excel at designing new products that not only provide a great deal of interactivity with the user, but also exceeds the perceived need - it takes genuine creativity to accomplish both goals.</li>
<li>Most product managers are super-detail oriented, with the ability to talk high-level, but then dive deep into the minutiae. There's no room for sloppiness or a lack of details and you'll rarely find a PdM that exhibit those traits.</li>
<li>The best product managers make the user the primary driver of the application and strive to enhance the user-experience. If you haven't heard of heuristics you probably shouldn't be a product manager.</li>
<li>Contrary to the belief of many, a good PdM also talks frequently with his/her technology teams to make sure what's being asked for doesn't have an extreme cost (not just money, but also time, resources and a consideration of the overall technical design). If you're not talking to your teams you should consider doing something else.</li>
<li>Product managers should strive to stay abreast of the latest technology - at minimum to keep things fresh and ideally to take advantage of new opportunities. This also includes training in disciplines outside of his/her comfort zone. If you haven't done Agile you should look into it and learn about being a product owner in a scrum team.</li>
<li>I don't think I could ever take myself seriously, or call myself successful without having actually taken a product from design all the way to market. I both count my wins and learn from my mistakes.</li>
</ol>
Just a few thoughts - thanks for reading!<br />
<br />
-- John Eaton </div>
John Eatonhttp://www.blogger.com/profile/00040215463441470962noreply@blogger.com0tag:blogger.com,1999:blog-5747686405891759983.post-47369104391386241012013-08-30T05:44:00.002-07:002013-08-30T05:44:39.614-07:00An Introduction to Product Management and Agile Product OwnershipI've been writing about the various topics that interest me for many years - I was an early adopter of Blogger and continue to use the platform - I like the flexibility and ease-of-use. Also, at Blogger I'm able to have as many blogs that I could ever want, and explore the many things I may want to highlight through writing and opinion. I started thinking about Product Management more-and-more recently as I'll explain shortly and decided it was time to start opining about it and how it integrates into Agile Product Ownership as part of an agile scrum team.<br />
<br />
But first, I'd also like to define a few terms so those of you unfamiliar with them can follow along.<br />
<br />
<strong>Product Management</strong> - actually this should be Software Product Management. Wikipedia defines it as: "...an organizational lifecycle function within a company dealing with the planning, forecasting, or marketing of a product or products at all stages of the <a class="mw-redirect" href="http://en.wikipedia.org/wiki/Product_lifecycle_(marketing)" title="Product lifecycle (marketing)">product lifecycle</a>." <br />
<br />
<strong>Product Manager</strong> - kind of obvious based on the definition above - this is someone who manages products. In my case since I do software development, the role has more to do with taking the various inputs from the business, users and others, and distilling them into information that can be used by software developers to make changes or create new software products.<br />
<br />
<strong>Agile Software Development</strong> - this is a software development methodology. Once again, Wikipedia defines it as "<strong>...</strong>a group of <a class="mw-redirect" href="http://en.wikipedia.org/wiki/Software_development_methodologies" title="Software development methodologies">software development methods</a> based on <a href="http://en.wikipedia.org/wiki/Iterative_and_incremental_development" title="Iterative and incremental development">iterative and incremental development</a>, where requirements and solutions evolve through collaboration between <a href="http://en.wikipedia.org/wiki/Self-organization#Self-organization_in_agile_software_development" title="Self-organization">self-organizing</a>, <a href="http://en.wikipedia.org/wiki/Cross-functional_team" title="Cross-functional team">cross-functional teams</a>. It promotes adaptive planning, evolutionary development and delivery, a <a href="http://en.wikipedia.org/wiki/Timeboxing" title="Timeboxing">time-boxed</a> iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle. The <i>Agile Manifesto</i><sup class="reference" id="cite_ref-Agile_Manifesto_1-0"><a href="http://en.wikipedia.org/wiki/Agile_software_development#cite_note-Agile_Manifesto-1"><span>[</span>1<span>]</span></a></sup> introduced the term in 2001.<br />
<br />
<strong>scrum</strong> - (just assume that all of these definitions are from Wikipedia going forward, with some notes from me) - "...is an iterative and incremental <a href="http://en.wikipedia.org/wiki/Agile_software_development" title="Agile software development">agile software development</a> framework for managing software projects and product or application development. Its focus is on "a flexible, <a href="http://en.wikipedia.org/wiki/Holism" title="Holism">holistic</a> product development strategy where a development team works as a unit to reach a common goal" as opposed to a "traditional, sequential approach". Scrum enables the creation of self-organizing teams by encouraging co-location of all team members, and verbal communication between all team members and disciplines in the project.<br />
A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called requirements churn), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner. As such, Scrum adopts an <a class="mw-redirect" href="http://en.wikipedia.org/wiki/Empirical" title="Empirical">empirical</a> approach—accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team's ability to deliver quickly and respond to emerging requirements."<br />
<br />
<strong>kanban</strong> - "...is a method for managing knowledge work with an emphasis on just-in-time delivery while not overloading the team members. In this approach, the process, from definition of a task to its delivery to the customer, is displayed for participants to see and developers pull work from a queue."<br />
<br />
<strong>scrum master</strong> - "Scrum is facilitated by a Scrum Master, who is accountable for removing impediments to the ability of the team to deliver the sprint goal/deliverables. The Scrum Master is not the team leader, but acts as a buffer between the team and any distracting influences. The Scrum Master ensures that the Scrum process is used as intended. The Scrum Master is the enforcer of the rules of Scrum, often chairs key meetings, and challenges the team to improve. The role has also been referred to as a <i><a href="http://en.wikipedia.org/wiki/Servant_leadership" title="Servant leadership">servant-leader</a></i> to reinforce these dual perspectives. The Scrum Master differs from a Project Manager in that the latter may have <a href="http://en.wikipedia.org/wiki/Management" title="Management">people management</a> responsibilities unrelated to the role of Scrum Master. The Scrum Master role excludes any such additional people responsibilities."<br />
<br />
<strong>Product Owner</strong> - "...represents the stakeholders and is the <a href="http://en.wikipedia.org/wiki/Voice_of_the_customer" title="Voice of the customer">voice of the customer</a>. He or she is accountable for ensuring that the team delivers value to the business. The Product Owner writes (or has the team write) customer-centric items (typically <a href="http://en.wikipedia.org/wiki/User_story" title="User story">user stories</a>), ranks and prioritizes them, and adds them to the <a href="http://en.wikipedia.org/wiki/Scrum_master#Product_Backlog">product backlog</a>. Scrum teams should have one Product Owner, and while they may also be a member of the development team, this role should not be combined with that of the Scrum Master. In an enterprise environment, though, the Product Owner is often combined with the role of Project Manager as they have the best visibility regarding the scope of work (products)."<br />
<br />
I think that covers most of what I'll write about and I apologize if all of the above is already familiar to you. More in the next post...<br />
<br />
-- JohnJohn Eatonhttp://www.blogger.com/profile/00040215463441470962noreply@blogger.com0