They Took our Jerbs

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.

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):

1. 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.
   
2. 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.
   
3. You then ask ChatGPT to look for exploits in the code, which are applied to the revised code
4. The code is put into a test environment for you to view and use.
   
5. 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.
6. Once you like the results and you've made tweaks, you've launched something new, with relatively little human interaction.

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.

So does that mean we're all out of a job and what can we do? That's the $1M question.

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).

The next thing I thought about is Evolution. 

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?

To answer this I asked ChatGPT a a few pretty basic questions: 

I. "How can the information generated by AI like ChatGPT negatively influence future queries?"

While AI-generated information like ChatGPT can have many benefits, there are also potential negative impacts on future queries. Here are a few examples:

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

II.  Can the information generated by AI like ChatGPT negatively influence any IP holders of information due to the sharing and learning aspects?

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.

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.

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.

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?

So now, my opinions (in somewhat logical order):

1. 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? 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.
   
2. Can AI replace all the people involved in software delivery? 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).
3. I don't understand AI at all - it seems like a toy? 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 chat.OpenAi.com 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.
   
4. Should you fear AI, especially when it comes to your job? 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.
   
5. So who will be impacted the most? 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.
   

Next Steps

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? 

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:

1. 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.
2. 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.
3. 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?
4. 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.
   
5. 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.
   
6. 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.

 

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.

 

-- John Eaton

What's Important to a Career Product Manager

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.

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.

I think that most of us, and for me at least, can segment a Product Management career into three general phases:

1. Learning Product Management as a Craft
2. Excelling to Maximize Salary
3. Relevancy as a goal

Let's break this down a bit so you can understand where I'm coming from.  

1. Learning Product Management as a Craft

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.

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.

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.

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.

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.

1. 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.
   
2. 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.
3. 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.
   
4. 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).
5. 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).

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.

2. Excelling to Maximize Salary

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.

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:

The Peter principle 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.

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.

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.

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.

3. Relevancy as a Goal

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.

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. 

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.

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.

Last point, "A journey of a thousand miles begins with a single step" 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.

-- John Eaton 2023.04.28

Quantifying Beauty in Your Product

I presented at last years ProductCamp Atlanta in an ad hoc manner, using a recent, really fantastic article I had read regarding the Minimum Lovable Product (MLP). 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.

From Lawrence McCahill "How to Build a Minimum Lovable Product"

First a short summary - the basic idea around MLP 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!"

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.

From DesignCuriel interview 2014

Alberto Alessi 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 Wall Street Journal 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!

From the  WSJ article (May 19, 2016):
"I know a product will be a best seller when: 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."


Taking this statement at face value and converting it to "Knowing a Product will be Successful", 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.

Knowing a Product will be Successful

SMI - sensation, memory, imagination or the notion of beauty
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.

• Sensation - 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.
• Memory - 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.
• Imagination - 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.

CL -  communication language, the ability to communicate status or values.
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.

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.

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.

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.

Finally, on Function and Price
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.

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.

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?

-- John

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:

https://www.youtube.com/channel/UCE5LiS_HKAgLl4nS2qrRKpA

(also published to LinkedIn)

-- John

Adapting to Change

Adaptation is Essential

Stating the Obvious

“The measure of intelligence is the ability to change.”
― Albert Einstein

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.

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.

First we should establish a list of assumptions:

1. 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.
2. How a business responds to the changes listed above, can often have a critical impact to company success.
3. Many times changes are external, a response is required and the speed of that response becomes critical to success.
4. With software development and new technologies changing the market landscape so quickly, multiply everything above by several factors.

Don't be Oblivious

"I put a dollar in one of those change machines. Nothing changed."
- George Carlin

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.

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...

Before exploring change factors, we should consider company culture.

Habits

“We first make our habits, then our habits make us.”
― John Dryden

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.

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.

“It's too late to be studying Hebrew; it's more important to understand even the slang of today.”
― Henry David Thoreau, Walking

Adaptation

“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.”
― Bruce Lee

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!
 
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!

Being Nimble

“It is not the strongest or the most intelligent who will survive but those who can best manage change.”
― Charles Darwin

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).

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 .

"When you're finished changing, you're finished."
- Ben Franklin

Change Can Be Painful

“We are kept keen on the grindstone of pain and necessity.”
― H.G. Wells, The Time Machine

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.

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.

-- John

"Adaptability is not imitation. It means power of resistance and assimilation."
- Mahatma Gandhi

(also posted to LinkedIn)

Writing a White Paper

Writing a White Paper

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

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

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

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

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

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

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

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

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

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

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

-- John

(also published to LinkedIn)

The Fallacy of Converting Requirements into User Stories

Borrowed from www.itworld.com

The Fallacy of Converting Requirements into User Stories

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

The story of Excess

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

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

So what went wrong, exactly? 

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

So what is a better way?

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

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

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

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

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

-- John

(also published on LinkedIn)